CS2 Discussion: Question: Opt-in ESNext features in 1.x

[carlmathisen]

First off, congratulations to everyone working on import/export making it into master of CoffeeScript 1.x. That is really great news! Have a look here (among a couple of other PRs) for the feature: https://github.com/jashkenas/coffeescript/pull/4300

Obviously class is one of the most important ESNext features we have, and it is a breaking change. It needs to be in 2.0. I would like to make a case for other opt-in features however, such as import/export above, await and template literals, to be put into 1.x as well. It won't make a difference to existing 1.x codebases, because the features won't touch existing syntax. Like with import/export, they should be passed directly through - which means that the developer will need to add extra tooling to make it work in the browser.

The situation we have at work is that we have a large codebase with CS classes that is less than trivial to port to ESNext classes in CS2. It would be nice to use other opt-in ESNext features without having to do a full upgrade right away. I think we share this boat with many others.

I know @jashkenas is opposed to adding features to 1.x that won't work out of the (compiler) box and thus requires extra tooling, but we already went up against this principle when adding import/export support. By the way, writing ESNext with CoffeeScript in Node does not require extra tooling.

Note: Sorry if this topic is covered in another thread, but the discussion seemed to be scattered so I decided to start a new thread about this specifically. Please close if this topic has been decided on already.

[GeoffreyBooth]

Well, modules will go into 1.x. Tagged template literals could be part of 1.x (though simple template literals, a.k.a. CoffeeScript interpolated strings output in ESNext syntax, can’t because that would be a breaking change). We left off in #28 that if it made sense to build tagged template literals independently of template literals, the former could go into 1.x in addition to both going into 2. That pretty much depends on @greghuc’s motivation to build both versions, though if he builds only the 2 version perhaps someone on your team could adapt that code for a 1.x version and submit that as another PR. I see no reason not to accept it.

As for await, I’m still not sure what we’re doing with that feature. I think we have consensus that we’re not accepting the PR as it’s currently written, with the ES5 shim; so it needs to be rewritten to output ESNext, and there’s no reason it couldn’t join 1.x as it’s just as opt-in as generators. But there’s debate over whether await is stable enough to implement at all. If it doesn’t make the cut as being widely-supported enough, I proposed in #37 an “experimental” flag or branch to hold features like await, so it will get out there in one way or another.

So basically any of these features aside from classes (assuming we’re abandoning the esclass proposal) could join 1.x, if there are people willing to do the work and submit pull requests for them. Are there any other “2-only” features you’re concerned about not having access to in 1.x?

[greghuc]

@carlmathisen could you please fill out the survey for devs/teams with maintained Coffescript codebases? It's a short 4 question markdown template, so should not take long.

It would be great to get the views of a dev/company with a CS codebase.

[GeoffreyBooth]

@carlmathisen We were discussing this in https://github.com/jashkenas/coffeescript/pull/3757. I had originally thought that await could be added to 1.x, but it was pointed out that await is not currently a reserved word in CoffeeScript and therefore adding it would be a breaking change. (It’s not unreasonable to think that some people might have functions named await.) So it looks like that will need to go into 2.

Modules are the big news of 1.11.0, so cross that one off the list. That leaves tagged template literals as the next big feature that could join the 1.x branch. Assuming they get implemented independently from regular template literals, or can be split out without too much trouble, I see no reason they couldn’t join the 1.x branch. What else would you be eager to see in 1.x?

And are you so sure it would be difficult to port your classes to a 2-compatible class syntax? Based on my cursory test with Decaf, all classes that contain only methods—i.e., no class properties or code in class bodies—should parse as is into ES classes. The properties or body code would need to get moved into the constructor. If I’m wrong about this, I would love to see some examples of more complicated classes that would be difficult to refactor (maybe in #22).

[coffeescriptbot]

Migrated to jashkenas/coffeescript#4936