CS2 Discussion: Project: CoffeeScript 2.0.0

[coffeescriptbot]

From @GeoffreyBooth on 2016-09-16 04:40

Branching off from coffeescript6/discuss#34, this is a place to discuss a potential 2.0.0 release of CoffeeScript. The proposed 2.0.0 release will include breaking changes, and have two major features:

• Classes output with the class keyword. See CS2 Discussion: Output: Classes coffeescript6/discuss#22.
• ESNext output whenever possible, with all ES5 or ES3 shims removed.

I think we should release 2.0.0-alpha1 as soon as classes are ready. We would also add a note on coffeescript.org that 2.0.0 is in alpha and subject to further breaking changes, which would be released as 2.0.0-alpha2 and so on until we’re pretty sure we have no further breaking changes for the 2.x major version.

The other features on our list that aren’t breaking changes (tagged template literals, await) can be released either on the 1.x branch or the 2.0.0-alpha branch. They should be implemented only as ESNext output, regardless of branch.

We should try to define exactly which features will have their output changed to ESNext. Here and here are comparisons of CoffeeScript features to new ES2015 features. Here is a pretty concise list of features introduced by ES2015. I’ve started a GitHub project where we can put cards into columns to define what features we want to update.

The other big issue is what to do about const/let and block scoping. Let’s please hash out an approach to that one over in coffeescript6/discuss#35, to not overwhelm this thread. Also if we can, let’s please keep discussion of whether we want to refactor or replace the compiler over in coffeescript6/discuss#25.

EDIT 2016-09-19: Changed “beta” to “alpha”.

[coffeescriptbot]

From @GeoffreyBooth on 2016-09-16 05:02

Also in 2.0.0 would we get rid of the top-level function safety wrapper? It’s already disabled for any file with an import and export statement, should we just get rid of it altogether?

EDIT: branched off as coffeescript6/discuss#38

[coffeescriptbot]

From @mrmowgli on 2016-09-16 07:23

The top level safety wrapper is actually useful in certain situations, although I admit I personally haven't used it in quite a while. Perhaps as another issue and a poll? Also Github just added the Projects tab, any interest in using that for this project?

[coffeescriptbot]

From @GeoffreyBooth on 2016-09-17 02:23

@mrmowgli Sure: https://github.com/coffeescript6/discuss/projects/1

[coffeescriptbot]

From @lydell on 2016-09-19 06:00

I like the proposed release scheme of 2.0.0-beta1, 2.0.0-beta2, etc. I also like the idea of adding non-breaking changes to 1.x. 👍 from me.

[coffeescriptbot]

From @jashkenas on 2016-09-19 17:54

Sounds fine to me, but speaking generally "beta" implies feature-completion that still needs bugfixing. Instead, call it "alpha".

2.0.0-alpha1, 2.0.0-alpha2 etc. When the major ES6 breaking changes have been made, then you can go beta.

[coffeescriptbot]

From @GeoffreyBooth on 2016-09-19 18:12

Sounds good to me. Okay, I’ll treat this as our plan for moving forward.

[coffeescriptbot]

From @GeoffreyBooth on 2016-09-19 18:29

Should we start this work in a 2.0.0 branch or start accepting breaking-change pull requests into master? If we do master, then there’s no possibility of more 1.x releases. I’m thinking we probably want to retain the ability for 1.x releases, at least to address any bugs people find in the modules code.

As part of 2.0.0 I think we should also prioritize clearing out the backlog of open pull requests on coffeescript.org; especially the ones that only affect downstream tools, like fixing location data. I suspect that those have been ignored because they have no effect on the CoffeeScript compiler and could introduce bugs or breaking changes . . . but 2.0.0 might be the place to deal with that. These fixes will probably end up helping us farther down the road if we implement a new compiler.

[coffeescriptbot]

From @jashkenas on 2016-09-19 18:48

To avoid breaking people unnecessarily, let's leave master as the branch for the "next stable release" — meaning that it stays 1.X for now. Work on and release from a 2 or 2.0.0 branch, and it can become "master" once it stabilizes.

[coffeescriptbot]

From @kirly-af on 2016-09-27 19:11

@GeoffreyBooth Just had a look on the Features page. IMHO, not being able to output for...of loops is quite critical and should at least be a mid-priority. Without those, we won't be able to make proper use of iterables which are quite common from ES6. Not even mentionning user defined generator functions.

I know this is defo not the right place to talk about it, but I think this SHOULD be part of CS2 (and actually why not CS1) as soon as possible.

[coffeescriptbot]

From @lydell on 2016-09-27 19:15

@kirly-af #4306

[coffeescriptbot]

From @kirly-af on 2016-09-27 19:36

@lydell: Sad to see we're going for a third for, but at least the feature is supported :)

[coffeescriptbot]

From @GeoffreyBooth on 2016-09-27 19:41

I thought of that as more of a 1.x feature and that’s what it wasn’t on the Features page, but it’s definitely a priority.

I haven’t looked too deeply into it, but I gathered from the discussion that there’s no way to avoid a third for syntax, and for...from seemed like the best option. Maybe in CS2 we might be able to improve on this, compiling one or more of the current for options into ES for...of, but that’s probably best treated as a separate effort to fixing the issue presented by not being able to do for...of a generator.

[coffeescriptbot]

From @kirly-af on 2016-09-27 20:45

Agreed.

[coffeescriptbot]

From @atg on 2016-09-30 22:34

Yes for-from is intended to be a 1.x feature, that simply completes the triangle of yield/yield from/for from.

In my mind, there's two clear categories of changes:

1. New features that compile to ES6 code because they add support for some ES6 new feature (yield, import/export, for-from, async/await). These features can be easily added to 1.x, because the entire feature is gated by the new syntax. No backwards compatibility issues for the compiler.
2. Existing CoffeeScript features being modified to generate ES6 code (e.g. class, for-in are candidates to be compiled to ES6 class and ES6 for-of respectively). This is more likely to cause backwards compatibility issues if the behaviour changes slightly.

If the second group of changes are implemented under a flag, then there's potentially no backwards compatibility issues at all, and so no need for a 2.x (in semver terms).

I would prefer a situation where we can do coffee <file> as normal to generate 1.x style code (ES3 where possible) and coffee -6 <file> to generate ES6 code where possible.

[coffeescriptbot]

From @GeoffreyBooth on 2016-09-30 23:28

@atg As discussed here and in coffeescript6/discuss#34, a flag adds a lot of complexity that we don’t want to deal with. We’re going with the 2.x branch and version number.

[coffeescriptbot]

From @atg on 2016-10-01 01:03

@GeoffreyBooth Presumably most changes would be confined to nodes.coffee so just maintain a nodes3.coffee and nodes6.coffee (the latter can import from the former if there is no difference). It doesn't seem impractical.

[coffeescriptbot]

From @GeoffreyBooth on 2016-10-01 01:09

There are also changes to the grammar. I'm sorry, but it's not worth the complexity.

[coffeescriptbot]

From @atg on 2016-10-01 01:18

Should I reply in the #34 or here?

I want to be able to use ES6 features with node.js. But also I have to write code that runs in web browsers (that do not have ES6 support). I have no intention of using a transpiler because that would break coffee -cw . for me. So I would be forced to install both 1.x and 2.x...

[coffeescriptbot]

From @GeoffreyBooth on 2016-10-01 02:42

It’s not that hard. When 2.x is out, you could install it globally:

npm install -g coffee-script

And within your project folder, install an older CoffeeScript:

npm install [email protected]

And then run 2 via coffee and 1 via ./node_modules/coffee-script/bin/coffee.

Or clone the CoffeeScript repo and create a symlink to it:

cd ~/Sites
git clone https://github.com/jashkenas/coffeescript.git
git checkout tags/1.11.0
ln -s /usr/local/bin/coffee1 ~/Sites/coffeescript/bin/coffee

Then use coffee to reference the latest CoffeeScript, and coffee1 to reference whatever version is checked out in ~/Sites/coffeescript (or wherever you want to put it).

Or use Gulp or Webpack or Grunt or any of their competitors. Or fork CoffeeScript, rename the binary in your version, and install that globally alongside the regular CoffeeScript also installed globally. Or go nuts and install Docker and use separate Docker images for compiling with various versions of CoffeeScript. There are many ways to solve this problem without needing to complicate the CoffeeScript codebase.

[coffeescriptbot]

From @atg on 2016-10-01 03:36

I understand that. It is not too hard for me and I will probably just install both versions. But it is more awkward than things currently stand. Surely I am not the only user who will be affected by this.

The philosophy of 2.x seems to be "damn ES5 compatibility in the core language, let's convert the entire codegen to ES6!". I am questioning whether this is a good idea.

If we take each feature in turn, most features are syntactically opt-in and so can be implemented without 2.x or a flag. Of the non-opt-in features, ES6 classes are the most useful and implementing them under a flag would not create great complexity in the CoffeeScript codebase.

So what remains? let/const? rest parameters? Does the gain of these invisible codegen changes outweigh the pain to the workflow of using CoffeeScript? I really don't get it but maybe I'm just old.

[coffeescriptbot]

From @GeoffreyBooth on 2016-10-01 03:58

Classes are in a class (sorry) by themselves, and absolutely need to be implemented ASAP. It’s a breaking change, unfortunately, and that’s really what’s triggering this whole effort.

The only other “major” features getting worked on at the moment are await and tagged template literals. await is unfortunately a breaking change, because await was not previously a reserved word, so that will need to be part of 2; but lacking await doesn’t hinder you in any way. Tagged template literals can be implemented in 1.x, and will be if someone takes the time to implement them separately from ES2015 template literals. There aren’t any other new features as part of the 2 effort; everything else is revising the output.

And there are several good reasons to modernize the output:

• Everything on the list, except for await and modules, is already supported natively by Node. If you’re working on a project that doesn’t use either of those features, you won’t need to transpile at all if Node is your only runtime. Presumably that will make your code run faster. Also, I expect Node to support both await (already in Node 7 nightly) and modules before too long.
• It’s easier to debug generated JavaScript that more closely resembles the original CoffeeScript.
• With Babel on the scene, it’s not worth our time to implement our own shims for ESNext features to ES5. If you need modules and you want to use CoffeeScript, you just need to learn how to use Gulp or Webpack or similar to create a build chain. We have enough on our plate to worry about a problem that someone else has solved.

[coffeescriptbot]

From @jonnor on 2017-02-08 15:48

Should the binary be available with a different name, since it is incompatible with the old one? For instance coffee2 or coffee6.
This for instance allows hashbang entries in scripts to then indicate the right version. There will likely be a transition period people have both 1.x and 2.x installed on their system.

[coffeescriptbot]

From @GeoffreyBooth on 2017-02-09 01:26

I’m not sure what you mean by “incompatible with the old one.” There are a small handful of breaking changes in CoffeeScript 2, but most code should run as is without requiring significant changes. Node 7+ will run CoffeeScript 2’s output without further transpilation, aside from modules (the same as today with 1.x). I don’t anticipate people keeping both versions installed globally on their machines.

[coffeescriptbot]

From @GeoffreyBooth on 2017-05-15 07:07

Update: in 1.12.6 and soon to come in 2.0.0-beta2, you can have separate versions of CoffeeScript installed globally and locally in a project, and the coffee command will automatically choose the appropriate one. So for example:

cd path/to/your/project
npm install --global coffeescript@next # Install 2.x globally
npm install --save coffeescript # Install 1.x locally in this project
coffee -v # 1.x
cd /
coffee -v # 2.x

[coffeescriptbot]

From @GeoffreyBooth on 2017-09-03 08:14

Closing per coffeescript6/discuss#88.