Remove dependency on babel-core@6.x

[loganfsmyth]

Filing because I want to make sure it gets seen. From https://github.com/jashkenas/coffeescript/pull/4697/files#r139525428

2.x has babel-core@6.x as an optionalDependency, but since those are auto-installed, and there's never a time where babel-core should fail to install, it's essentially been made a direct dependency.

Since the logic to load it is already behind atry/catch with a notice to install it, it seems like the optionalDependencies block should just be removed. This also opens up users to the possibility of using Babel 7.x in the future, since that will be released in the coming months. As it is now, it'll be a breaking change for coffeescript@2 to change it to babel-core@7.x which would be extremely unfortunate.

[jashkenas]

Yes, we should definitely not be installing Babel with CoffeeScript by default. Let's take it out ASAP, and push a 2.0.1 soon.

[jashkenas]

Just looking at the file sizes, it's currently adding an 80 megabyte node_modules folder to an install that would otherwise be only 500k of JS.

[GeoffreyBooth]

Sorry, I thought that optionalDependency didn’t install by default. Yeah, if things still work without Babel needing to be in there (i.e. the error message still comes up, without Node crashing on resolving the require or something like that) then sure let’s remove it.

The other issue is when CoffeeScript is installed globally, which is the use case when people really would want to use --transpile. For --transpile to work without it being a dependency, babel-core would also need to be installed globally (?) but the Babel docs discourage global installs.

[jashkenas]

I think leaving them parallel is probably the right way to go. If you install a global CoffeeScript, you can install a global Babel. And if you install a local CoffeeScript, you can install a local Babel too.

Before pushing, I just tried the tests with just a global babel, and they transpile just fine.

[loganfsmyth]

That's an interesting case. I can elaborate on the reasoning behind recommending against global installs. The main thing is that .babelrc files are generally tied to specific versions of Babel. Plugins for 7.x may not work for 6.x, and the other way around, so users need to have the right version of babel-core.

Perhaps instead of resolving babel-core relative to the coffeescript package, users could be instructed to install it relative to the files being compiled, and coffeescript could use resolve to find it there, with a fallback to checking globally?

[GeoffreyBooth]

The thing is, we also prefer CoffeeScript to be installed per project, though the docs could be clearer about this. Running the coffee command will first look to see if you have CoffeeScript installed locally, and then fallback to a globally-installed version.

So I think the way it would work is this:

• For a user with a script.coffee file in a folder, and nothing else in that folder, and you want to run coffee --transpile script.coffee using a globally-installed CoffeeScript: you need to drop a .babelrc in that folder or any parent/grandparent/etc. folder, and you need to have babel-core installed globally. So for dev ops folks using CoffeeScript like Bash shell scripts, they can have a ~/.babelrc and scripts like ~/dev/something.coffee. They would be fixed to a particular version of Babel, like they’re already fixed to a particular version of CoffeeScript, and that’s fine.
• If they want a different version of Babel (or CoffeeScript) they just need to install one or the other locally in their project. With both installed locally, everything is straightforward and will work the same way 2.0.0 works.
• If they want to use some mix, like global CoffeeScript but local Babel, I don’t know how resolution would work, or what combinations we should support. Can global CoffeeScript require local Babel? If not, I think we don’t care to make it so—just throw an error saying to install both CoffeeScript and Babel locally. (I’m assuming @loganfsmyth you wouldn’t want the error to recommend installing Babel globally?) Local CoffeeScript should be able to require global Babel, but that’s also not a recommended combination (?) so it should get the same error, or I guess it’ll just work because there’s no way CoffeeScript would know if the Babel it’s requiring is local or global.

In any event, this needs more thorough testing before we push a 2.0.1.

[loganfsmyth]

Can global CoffeeScript require local Babel?

Not unless you implemented that yourself using the resolve package I linked. It does certainly add complexity on both the implementation side and user understanding side, so it's really your call. I don't have strong feelings about supporting that.

I’m assuming @loganfsmyth you wouldn’t want the error to recommend installing Babel globally

I don't feel strongly. Maybe if that route ends up being taken, just make it clear that the version will be harder to manager?

Local CoffeeScript should be able to require global Babel, but that’s also not a recommended combination

Does that work? I'd have to go check, but I was under the impression that node didn't try to resolve packages from the global packages unless the thing doing the resolution was also global.

Thanks again for responding to all this, I'm sure it's the last thing you wanted to do after being excited to get 2.0.0 out the door.

[jashkenas]

We actually don't prefer CoffeeScript to be installed per-project, and never have. It's meant to be a system-wide, generally compatible tool that you only need to install once, and then can use where-ever you like. Like node, like ruby, like python.

The docs have always recommended --global for the install.

Of course, if you want to install it locally, and use ./bin/coffee, that's cool too.

[GeoffreyBooth]

@jashkenas See #4543 and #4049. Back in 1.12.6 we removed the preferGlobal flag, and updated the coffee and cake commands to first look for CoffeeScript installed in the current folder (and if found, run that version) before running the globally-installed version. The idea was that now that there’s 2.x out, older projects may very well need 1.x (if they can’t upgrade easily, for example) and for them you would install 1.x locally; but keep 2.x/latest installed globally.

In general though, other Node command-line tools like Babel and Gulp and Webpack all recommend installing locally. For CoffeeScript 2, which almost demands to be part of a build chain (i.e. chaining to Babel via Gulp or Webpack, or letting CoffeeScript manage the chaining via transpile) it probably makes sense to follow their lead. Otherwise we end up with exactly this “user error” issue: we tell people to install CoffeeScript globally, but then they install Babel or Gulp locally, and --transpile doesn’t work. If anything we should flip the question around: why shouldn’t we recommend installing locally?

As far as I can tell the only advantage to installing globally is that you can then run CoffeeScript via just coffee, rather than ./node_modules/coffeescript/bin/coffee. But we could just as easily advise people to install CoffeeScript both ways, and get the best of both worlds:

# Install CoffeeScript globally, to get quick access to the `coffee` command
npm install --global coffeescript

# Install CoffeeScript in your project, to integrate with build chains
npm install --save-dev --no-optional coffeescript

Having Babel installed as a dependency of the globally-installed CoffeeScript would solve the problem of getting --transpile to work with global coffee; and recommending people install locally via --save-dev --no-optional avoids the large-download issue. And if someone doesn’t read the docs and leaves out --no-optional, eh, so what, they get Babel installed as well. It’s not the end of the world. I’ve never heard of people complaining that an NPM module had too many dependencies (though maybe @loganfsmyth has, because Babel has a helluva lot of dependencies!).

So simply updating the docs with the above (and loosening the version bounds of the babel-core optional dependency) would be the easiest solution. Before I get into the other options, how does everyone feel about this?

One question that maybe someone knows the answer to: is it possible to somehow install a dependency only when installing globally? Like maybe installing coffeescript globally could trigger installing the babel-core dependency, but installing locally would not (without the user needing to know to use --no-optional)?

[GeoffreyBooth]

Does that work? I’d have to go check, but I was under the impression that node didn’t try to resolve packages from the global packages unless the thing doing the resolution was also global.

Actually, yes, it can:

# No globally-installed CoffeeScript
npm uninstall --global coffeescript coffee-script

# Install Babel globally
npm install --global babel-core babel-preset-env

cd /tmp
mkdir test
cd test

npm install --save-dev --no-optional coffeescript
# + coffeescript@2.0.0
# added 1 package in 0.966s

echo '{ "presets": ["env"] }' > .babelrc

./node_modules/.bin/coffee --transpile --eval \
  'import path from "path"; console.log path.sep'
# /