CS2 Discussion: Features: Flag for ESNext output from current compiler #4930
Comments
|
From @rattrayalex on 2016-09-11 17:31 In terms of implementation, couldn't it simply wrap |
|
From @GeoffreyBooth on 2016-09-11 17:47
No. |
|
From @GeoffreyBooth on 2016-09-12 04:56 Update: I just found this comment where @jashkenas proposes a flag for ES6 output. So I guess a flag for this purpose would actually be blessed after all. |
|
From @GeoffreyBooth on 2016-09-12 05:29 There are some questions we would need to hammer out (@lydell?):
This also ties into the discussion of a new compiler. Basically, with this flag I’m assuming a new compiler is a ways off. Both |
|
From @GeoffreyBooth on 2016-09-12 05:41 @rattrayalex Decaffeinate might not be an option, but Decaf might be . . . |
|
From @greghuc on 2016-09-12 07:12 If there's an From a documentation perspective, the flag is also useful. We put a section at the end of the Readme listing the ESnext-only features which need the flag. And this sets the narrative for what's happening: if/when the compiler switches to just ESnext output, it can be explained in terms of the flag ("flag is now on by default"). |
|
From @jashkenas on 2016-09-12 20:31 I think that a more appealing path than a |
|
From @mrmowgli on 2016-09-13 01:06 Coffeescript 2 should still end up being coffeescript. I think the problem a lot of these projects run into is that they don't become the defacto compiler. At some point the base coffeescript branch should merge the new changes from ES6, and you just use coffeescript. You've already integrated yield, which is an ES5+ feature. The real question is the best way to ease that transition, or have some procedure for transitioning, much like io.js -> node.js development. io.js is the unstable new feature set, node.js is the production ready version. @jashkenas, is there a reason you have been avoiding the use of flags? |
|
From @GeoffreyBooth on 2016-09-13 02:04 I think CoffeeScript 2.0 is what would be produced by the The branch approach has been taken by Gulp in their long march toward version 4.0; for the last two years I’ve been putting Where it gets tricky, though, is if we want to add a new feature like We could certainly call the |
|
From @jashkenas on 2016-09-13 14:37
I don't care terribly much per se, but my strong advice would be that having two code generation paths in an already complex codebase will make things that much more difficult to work with and continue to develop. For development, maintainability, for marketing, and for user friendliness — I think it would be smart to work and release from a |
|
From @JimPanic on 2016-09-13 15:00 I like that idea. Although as long as we don't introduce anything breaking backwards compatibility, semver kind of dictates to follow along the path of 1.x. (Has CS even been using semver so far?) But given classes are a top priority, together with getters and setters, this is not too far away either. |
|
From @GeoffreyBooth on 2016-09-13 17:10 @jashkenas I’m not opposed to a new branch, but I think any “new” compiler is likely to include falling back to the “old” one, so we’re going to have a complicated codebase regardless. Like for example maybe This assumes that the new compiler takes a different approach than the old one, for example what we’ve been discussing about ASTs in coffeescript6/discuss#25. If CoffeeScript 2.0 outputs ESNext syntax using same string-generation compiler that we have now, then sure, it should be in a new branch and there aren’t two code generation paths. |
|
From @jashkenas on 2016-09-13 17:25 Maybe I'm not being clear — there isn't any "new" compiler yet in existence. I'm talking about the ESNext-targeting features y'all are adding to the current compiler happening in a "2.x" branch, and being released as |
|
From @GeoffreyBooth on 2016-09-14 03:56 The thing about 2.0.0 is that we’re not likely to know what all of our breaking changes will be. We know that transpiling CS We also can’t just hold off on releasing 2.0.0 until “all” of the ES-related breaking changes are done. Not only is that not fair to the people eager for I think we need to release support for classes ASAP, regardless if some or all of the rest of these features are ready. So that leaves us with a few options:
I honestly don’t have a preference; my only strong opinion is that we don’t commit to a plan that causes some features to get delayed releases because we’re waiting for a bigger breaking-change release. Modules should be released as soon as they’re ready, as should classes and tagged template literals and The other decision that should be made in concert with this is whether we release ES5-shim versions of any new features we build. This might only apply to @jashkenas, @lydell, other maintainers? |
|
From @JimPanic on 2016-09-14 04:56
That's the basic idea, yes. But other feature releases (like In any case: we will require some form of release management process and proper regression coverage for this to work. (But we'll need that anyway :) ) |
|
From @JimPanic on 2016-09-14 06:13 Actually most of the features are just additional syntax afaict. Classes are the only thing breaking source compatibility completely. import/export, async/await, let/const, template literals, fat arrows - they all do not break compatibility as they are planned right now. We might discover something during implementation, of course. But then again this might be a bigger change than originally anticipated thus we might also want to bump the major version. I see this as a good path forward that also communicates progress to the community. (And I don't mean the major bump, just that there are actual bumps in any kind of version publicly released.) |
|
From @jashkenas on 2016-09-14 14:29
We need to figure that out. I'd put classes, arrow functions, spread operator, default parameters, destructuring assignment, and for..of loops on the breaking changes list. Perhaps there are more. We can ship a What else?
|
|
From @GeoffreyBooth on 2016-09-14 15:18 I like the idea of Where does this leave |
|
From @jashkenas on 2016-09-14 15:26
Yes. And anyone who wants to try it out, can.
No. See: http://kangax.github.io/compat-table/es2016plus/#test-async_functions. We should wait until runtimes begin to implement it, and then compile it straight through. |
|
From @GeoffreyBooth on 2016-09-14 16:11 My point with asking about So for tagged template literals or a feature like them, are we skipping the ES3 version and going straight to outputting ESNext only? Or do we want to output ES3 for the 1.x branch? |
|
From @rattrayalex on 2016-09-14 16:30 @jashkenas it sounds like you'd be opposed to CS2.0 including features that require further transpilation (eg; Do you predict the population of folks who are both willing to upgrade to possibly-backwards-incompatible 2.0, but unwilling to use a second transpiler (or simply avoid using features like
|
|
From @rattrayalex on 2016-09-14 16:31 Separately, I personally quite like the plan @jashkenas outlined above – @GeoffreyBooth , if you agree, would you like to incorporate it into the README (presumably paraphrased)? |
|
From @GeoffreyBooth on 2016-09-14 19:10 @rattrayalex Yes, once we settle the ES3/ESNext question I’ll happily write this up. Another option is that 2.0.0 includes Babel, perhaps behind a flag like |
|
From @jashkenas on 2016-09-14 19:47
Let's skip the ES3 version, and ship them outputting to ESNext on the
Not at all. I just think that it's generally foolish to begin chasing JS features that haven't started shipping yet — as soon as they start shipping, great. But before, you have things like this: https://gist.github.com/Rich-Harris/0b6f317657f5167663b493c722647221
Totally. |
|
From @GeoffreyBooth on 2016-09-14 20:42
Sorry to keep beating a dead horse, but is there a reason not to output ESNext in the 1.x branch if the feature is opt-in by usage? Like what we’re doing already for modules and generators. When tagged template literals are implemented, it will use a syntax that throws an error today; so it’s not a breaking change. Anyone who uses the new syntax would be opting in to the new feature, which would output ESNext. |
|
From @jashkenas on 2016-09-14 21:15
We caaaaaan ... but it muddles the message. Honestly, modules and generators would be better shipped on the 2.x line than the 1.x line to keep things nice and simple. But that ship has already sailed (generators wise). |
|
From @GeoffreyBooth on 2016-09-14 21:43 I think the message is pretty simple: ESNext output that is a breaking change comes in 2. ESNext that’s opt-in and therefore doesn’t break anything comes in 1. |
|
From @GeoffreyBooth on 2016-09-16 04:55 It seems like the desire for a new flag is low. Closing this issue unless someone wants to argue why a flag is better than a new branch/version. |
From @GeoffreyBooth on 2016-09-11 17:22
This is a proposal for generating ES2015+ syntax from the current compiler. It’s rather simple. We add a flag:
To implement this, in the compiler itself we can either have
ifblocks within node classes that generate different output based on whether this flag is set; or we can have a second set of node classes that override the first set if this flag is set.This flag would only apply to features like
await, where we have a PR that implements an ES5 polyfill but others might prefer theawaitkeyword output as is; and features like=>that are supported in ECMAScript now and people might prefer to output them as is rather than polyfilling them. Eventually this flag could allow us to automatically outputletorconstas appropriate, without worrying about breaking backward compatibility. Modules support would be unaffected by this flag, as using theimportorexportkeywords would be opting in to ECMAScript for those lines; there’s no point in making such lines throw an error if--ecmascriptis unset. Likewise for generators. With regard to classes, I’m assuming based on coffeescript6/discuss#22 that we will likely implement a new keyword that produces ECMAScript classes, leaving the currentclasskeyword alone and allowing projects to contain both types; so those keywords would also be unaffected by this flag.This flag isn’t meant to foreclose the effort at creating a new compiler; on the contrary, it might pave the way for it. We can implement this flag now, with maybe just one or two features compiled differently, with the list growing over time; but when the new compiler is ready and can handle all the same features that the legacy compiler plus
--ecmascriptcan handle, the--ecmascriptflag could trigger opting into the new compiler.The text was updated successfully, but these errors were encountered: