CS2 Discussion: Project: A clear narrative for CoffeeScript: are we muddying the water with now CS1 and CS2?

[greghuc]

I've been wondering how maintaining the CS2 and CS1 branches is going to pan out, and if/when CS1 can be deprecated. Specifically, can Coffeescript return to a world where there's "one true version" (CS2) with a single set of features + documentation?

My concern is that whilst CS2 is awesome, and moves Coffeescript forward, we're at risk of muddying the waters with having two separate versions of Coffeescript medium term.

Seems to me that there's two separate developer audiences that need considering:

• Devs with existing CS1 codebases
  • Some want to maintain the CS1 codebase, maybe with some bug-fixes
  • Some want to transition to CS2. There's an issue about making devs aware that CS2 exists. Think there was a discussion elsewhere about the value of placing CS2 in the age-old 'coffee-script' npm package, so devs became aware of CS2 through semantic versioning.
• Devs starting new projects
  • Most likely to go with latest and greatest CS2
  • I'm not sure why they'd go with CS1, unless for ES5 compatiblity. But could this be done with CS2 and a babel transpile?

I'm sure @GeoffreyBooth has thought about this, but I thought raising an issue was worthwhile.

It would be good to get some clarity so there's a clear narrative the CS/JS dev community can easily understand. Plus I imagine maintaining two parallel code branches longterm sucks.

[GeoffreyBooth]

Hey, there has been some discussion of this in #71

My view is that CoffeeScript 2, when it is released out of beta, will be the one true version of CoffeeScript. CoffeeScript 1 is hopefully already frozen; ideally, 1.12.4 will be the last 1.x release. We certainly won’t be releasing any more features on the 1.x branch, and I doubt there will be much interest in backporting bugfixes to 1.x either. I wouldn’t be opposed to approving pull requests if others want to submit backported bugfixes, but that would be a low priority.

The upgrade effort, in my opinion, is minor. There are very few breaking changes in 2, and attaching Babel to the build chain is probably something people started doing back in 1.11 with the introduction of modules. I don’t feel guilty about asking people to make the effort in order to get the latest and greatest bugfixes and features.

I’m nervous about putting 2.0.0 on coffee-script until we can confirm that that wouldn’t wreak havoc with downstream tools, especially non-Node ones like Ruby gems. If someone can confirm that it’s safe I’m fine with coffee-script and coffeescript being mirrors of each other. Until then, 2 will live only on coffeescript. When it gets out of beta it will be coffeescript@latest, instead of coffeescript@next. Since projects or downstream tools will need to update their dependencies anyway to use 2, I don’t think it’s a big deal for them to change the repo to the hyphenless one.

And yes, developers needing to output ES5 or ES3 can use CoffeeScript 2 with Babel. That’s what I would expect most developers to be doing.

[greghuc]

@GeoffreyBooth that all seems sane.

Re putting 2.0.0 on coffee-script, how about putting it on as 2.0.0-beta? This is valid semantic versioning, and indicates that there is a breaking change Coffeescript in the works, and it's in beta. When 2.0.0 is officially released, it will become the latest version, and sort after 2.0.0-beta. I reckon this would significantly increase awareness of CS2.

I understand that using the coffeescript package has allowed 2.0.0 'beta' to be released, but not in the normal coffee-script package. However, having both packages has complicated matters, and I wouldn't expect many developers to proactively switch to using coffeescript from coffee-script. I know from my own behaviour that I periodically check for new npm package versions with npm-check-updates, and update accordingly. So I'd update coffee-script to 2.0.0-beta or 2.0.0 if I saw it, but I wouldn't proactively switch to coffeescript@latest: the different package name wouldn't appear on my radar.

[GeoffreyBooth]

@greghuc I’m open to publishing 2.0.0 on coffee-script as soon as someone can verify that that’s safe. This involves finding the most popular downstream tools that use CoffeeScript, and verifying that they’re version-bound (and so won’t automatically pull in 2). In particular I’m concerned with non-Node tools that might pull it in via something like npm install coffee-script or git clone.

[GeoffreyBooth]

Just to throw one example out there, the Rails coffee-script gem simply pulls the latest master from the jashkenas/coffeescript repo: https://github.com/rails/ruby-coffee-script/blob/master/script/build-source-gem. So this will break horribly if we ever merge 2 into master. (Not that that gem wouldn’t deserve it, but still.)

Anyone care to check any other major downstream users of CoffeeScript, to see how those tools pull the compiler in?

[coffeescriptbot]

Migrated to jashkenas/coffeescript#4968