bjn

I don't have anything special in my webpack configuration, but it looks like what Jack suggests above might be a good solution. In my application code in plain old Javascript I have just var SplitText = require('../javascript/vendor/SplitText.js'); where that path is relative from that particular JS file to where I'm storing the SplitText script.

Great. I downloaded the package again and updated my Splittext version. I confirm that it works with webpack.

I think you misread. It's not working -- you still have `"TweenLite"` in the brackets, at least in the version of SplitText you're distributing (0.3.4). If you remove that it'll work. Also looking forward to the version which fixes with the other issue (blank lines) being published.

I should have tested rather than just assuming the check for require.amd would fix things. It turns out it doesn't. Webpack *does* support AMD modules, and the environment *does* have a `require.amd`. The solution you suggested earlier, of emptying those square brackets, *does* work. Presumably this is the list of dependencies for an AMD module, and so it's complaining that we don't already have TweenLite. Adding the check for `define.amd` was probably a good idea regardless. Sorry about the confusion.

No problem.

Well the way I see it, any developer who uses git and/or Github, and probably most users who want to use a package manager like NPM, already have a public/private keypair. They've probably already put the public key up on their Github profile so they can pull/push via SSH. What I'm suggesting is that users who are so inclined could log in here to this Greensock site and add their public key to their profile, in the same way we do on Github. Then some process looks through the database for all users who have a public key and should be allowed access, and collects all the public keys. It then feeds them to something to allow access to the git repo. Having had a brief look at the Github API and a few Google searches it doesn't look like there's any obvious way to post a list of public keys to grant access to. But you could self-host a git repository pretty easily. There are some notes about the bare-metal way to do it here. https://git-scm.com/book/en/v2/Git-on-the-Server-Setting-Up-the-Server In short: 1. Provision a server, give it a public DNS hostname and open port 22 2. Install SSH server on it 3. Install git 4. Make a system user called git, and lock its shell down to git-shell (tool provided by git), so that users can't actually get a proper shell on your server 5. Add your bare git repositories in the git user's home directory, under whatever paths make sense. Maybe utils/SplitText.git is the SplitText repo 6. (Not mentioned in the link above) lock down the repo to only allow reading, not writing. Can do this with plain filesystem permissions (for example, set the owner of all the files in the repo to your actual interactive user on the server so *you* can still push to it, and allow only read (and execute where appropriate) for other users including the git user), or pre-receive hooks, for example. 7. Write a script which fires via a cron job once a day or whatever which grabs the suitable public keys from your database and throws them all in ~git/.ssh/authorized_keys 8. Publish the DNS hostname and git repository name, and instructions, as an installation option for members 9. Users then add their public key to their profile, then add the dependencies to their package.json such as `"splittext": "git+ssh://git@git.greensock.com:utils/SplitText.git#stable"`, presuming that's where the server and repo are and that you have a branch called "stable" (can also lock down by tag, commit, etc if the user is so inclined) There are also software packages which are supposed to make this kind of thing easier, such as gitosis. I concede that if I'm the only person who's ever asked for git access/package manager for these utility scripts, it's probably not worth the effort. But I think it'd be nice.

Yes, much better; thanks. Will this make it into mainline?

It looks in the version you just sent me that you switch the order of CommonJS and AMD tests as well as checking for `define.amd`. If you look at the bottom of the article I linked, you'll see that the guy recommends checking for AMD first since it's possible to get false positives for CommonJS sometimes. Just wanted to point that out.

Oh, it ended up in my (Google Mail) spam box, presumably due to the zip attachment. I'll review it shortly.

I didn't get it the email; please double-check you sent to the right address. I also found just now that no-break spaces aren't preserved when splitting only by line. This is causing visual issues for me. Or are no-break spaces simply not supported? (Do you want this in a separate thread? I know I would if this were a bug tracker for something of mine...)

This looks to be a pretty good article. http://ifandelse.com/its-not-hard-making-your-library-support-amd-and-commonjs/ It looks for `define` and `define.amd` rather than just `define` to trigger the AMD export. Webpack would fail that test and so the CommonJS one, which is what we want, would apply. As for subscriber-only git repo, it may be not as tricky as you think. Those users who want git access (for NPM reasons or to suggest patches, bisect for the source of bugs, etc) could provide a public key via this Greensock website. You then decide who is still allowed access and who isn't, and provide (git-only) SSH access only to those with allowed keys. Github may or may not have something in its API for this, but I know it's certainly possible on a self-hosted git repo.

It's probably because Webpack provides a "define" function. Your code then thinks it's an an AMD environment, which it's not. As for NPM, there's this https://www.npmjs.com/private-modules but I haven't really looked in to whether this would be suitable. Or it could be available in a subscriber-only git repository, limited by public key, and you could provide the suitable string for package.json files to grab it from there.

For a block of text with three lines, I'm using SplitText to split by line and I'm getting five lines out. The first and last of those are empty, and take up no space. I only see this behaviour if the text has whitespace around it. Such as <h2> Here is the header; it takes up three lines. </h2> It's annoying, since I have to filter the blank ones out before I can animate and do things like a delay depending on the line number. It could also lead to misleading line number counts. Is this a known bug?

Oh and I've already solved it. It's a bug with how the script is packaged, and I'm assuming the reference to TweenLite is simply a copy-and-paste error. I doubt the Greensock developers actually test this as an AMD module, because I suspect that would lead to a broken reference. Anyway, the solution for me, since I'm not using AMD packaging, was just to remove AMD packaging, turning this code (which is at the end of the file): //export to AMD/RequireJS and CommonJS/Node (precursor to full modular build system coming at a later date) (function(name) { "use strict"; var getGlobal = function() { return (_gsScope.GreenSockGlobals || _gsScope)[name]; }; if (typeof(define) === "function" && define.amd) { //AMD define(["TweenLite"], getGlobal); } else if (typeof(module) !== "undefined" && module.exports) { //node module.exports = getGlobal(); } }("SplitText")); into this: //export to AMD/RequireJS and CommonJS/Node (precursor to full modular build system coming at a later date) (function(name) { "use strict"; var getGlobal = function() { return (_gsScope.GreenSockGlobals || _gsScope)[name]; }; if (typeof(module) !== "undefined" && module.exports) { //node module.exports = getGlobal(); } }("SplitText")); Or even to this: //export to CommonJS/Node module.exports = (_gsScope.GreenSockGlobals || _gsScope)["SplitText"]; Greensock folks, please fix this issue. I want to be able to use your scripts unmodified with Webpack. Speaking of, I also want to be able to download SplitText via NPM, which doesn't seem to currently be possible.

I just bought a "Shockingly Green" membership solely for SplitText. I have no interest, at least currently, in using the other Greensock features. I'm trying to require SplitText with Webpack. Compilation fails: ERROR in ./resources/assets/javascript/vendor/SplitText.js Module not found: Error: Cannot resolve module 'TweenLite' in /home/bjn/myproject/resources/assets/javascript/vendor @ ./resources/assets/javascript/vendor/SplitText.js 425:2-34 The docs at http://greensock.com/docs/#/HTML5/Text/SplitText/ say SplitText has no dependencies, so I don't know what business it has looking for TweenLite, or why TweenLite is even referenced. Is this a bug, or am I doing something wrong?