src: enable --harmony by default #6999
Conversation
Conditional globals like 'gc' should only be recognized when --expose_gc is set. The global.gc feature check works only when done eagerly, else it lets through a leaked variable called 'gc'.
Harmony support is probably the most anticipated feature in v0.12. Enable it by default so module authors can safely assume that Harmony features like generators and proxies are available. It's possible to disable Harmony features again with the --no-harmony flag. Update src/node_contextify.cc to make it stop copying properties from the parent context indiscriminately. It copies over the Proxy object from the parent context but the new context has one of its own. Update test/simple/test-repl.js; it had a test that checks for something that's prohibited in ES5 strict mode but allowed in ES6, namely block functions.
|
Thank you for contributing this pull request! Here are a few pointers to make sure your submission will be considered for inclusion. The following commiters were not found in the CLA:
You can fix all these things without opening another issue. Please see CONTRIBUTING.md for more information |
|
It is not yet enabled by default in v8, I don't see any reason except user expectations. |
|
I don't think it's appropriate to turn on ES6 in Node by default until V8 has had a chance to get their implementation in line with the standard, which is still a few months away from being complete. Just off the top of my head, I know a bunch of stuff is in flight for module linking and loading, and there are some non-compliant aspects to V8's promise implementation. @domenic, what do you think? The other updates are valuable, and should probably be landed in a separate PR. |
|
I agree that V8's ES6 implementation is generally pretty bad and non standards-complaint; we should not turn it on. Maybe individual low-risk features, like octal literals, but e.g. their promises and proxy implementations are both spectacularly out-of-line with the spec. I don't understand the contextify change or what it accomplishes. |
|
Ok, considering your comments, I'm now sure that we should not do it just yet. Let's wait for v8 team to enable it by default. I think that as soon as their implementation will be stable and compatible with spec - they will do it. |
|
I'm going to reopen this for now, for further discussion. The official Node opinion thus far has been to not enable these features before v8 enables them by default. There are arguments for why the v8 team itself hasn't enabled them and by and large they probably apply to Node as well. That being said, we could probably perform an audit query over the current npm packages to get a frame of reference of the impact of at the least keyword conflicts (it won't be a perfect query but it could give us at least some insight). That being said, I think there's a few options we could consider as a compromise. My gut reaction was to do this as a Arguments against this include it being a fairly obtuse mechanism and an anti-pattern, as well as if it were Node actively installing this link it's one more thing to maintain in perpetuity because someone would be writing scripts as Another potential compromise, is the concept of a more surgical approach. Enabling only those flags which we deem to be appropriate for every day use. It's easier to describe the scenarios where we wouldn't enable a harmony feature by default.
The list of potential v8 harmony options, along with @domenic's disposition on if they should or should not be enabled:
Other considerations are that the unstable branch currently has v8 3.22, 3.23 is the current stable and I'm open to updating to that before the 0.12 release, but 3.24 is the current development branch I am not sure I would be comfortable in releasing 0.12 with it, without giving it more time to bake. |
|
I'm uncomfortable with rolling ES6 support out piecemeal. As a tooling engineer, this creates a feature matrix for support that just seems nightmarishly complex. Each additional language feature adds in more conditional logic to the various bits of my codebases that need to accomodate specific features. Also, because there's no rigid correlation between the (implicit) version of JavaScript implemented by a given version of V8, the version of V8 in the runtime, and the version of Node, this means that new features are going to be trickling out over time, which implies the possibility that there will be more tests necessary for specific point releases of Node to deal with changes in the underlying language. If the versioning were a little more lockstep, I'd probably be more comfortable with this. In general, I'd be more comfortable waiting until V8 is confident enough in their implementation of the standard to drop the flag than opting the community in gradually. |
|
I can see @othiym23's point of view. Counterarguments:
|
|
I'm pretty certain we are going to see both lots of production code with these flags & lots of projects / libs requiring these flags, even if not enabled by default. 👍 to @domenic's counterarguments. |
I'm fine with this, as that allows vendors to choose what they do and don't / can and can't support. New Relic is all about a seamless deployment process and high-quality support, and to do a good job of this, we need to be able to focus where we spend our resources. We have to support everything that's enabled out of the box in Node core -- everything else needs a justification. I'm sure we're not alone in this respect. People building platforms on top of Node are strongly affected by this decision.
I don't find this argument very compelling. V8 gives you more fine-grained control over which features you enable via the various
My hope is that implementors are enough on top of things this time around that adoption will be significantly faster for ES6 than for ES5, but you're right that the complexity of ES6 makes this seem like wishful thinking on my part. Either way, the way Node just drops whatever the latest stable build of V8 is into point release of Node also makes me nervous, it just hasn't been much of an issue until very recently because it's very rare that there are breaking semantic changes to the language V8 implements itself. I would welcome Node being more deliberate / conservative about adopting new versions of V8. |
|
from a module maintainer's perspective (https://github.com/koajs/koa), i would very much like also, i'm assuming node doesn't change |
|
While I personally dislike much of ES6, I'll try to put that aside. First, if we are going to enable ES6 features before they're officially Second, I want users to understand that - apart from simple things like |
|
I should specify better about the tests. I'm sure v8 already supplies |
|
One good reason why not to enable harmony collections. If other features have the same "quality" then better not. Run the following with |
|
Yes, the Set constructor is not implemented. That's one of the things that's left out of the implemented subset of the collections stuff. |
|
A friend of mine started doing some things in Node.JS and he said he really really wants to write his code "semantically correctly" as in "using correct container for the job". After trying out |
|
Adding the features piecemeal causes a compatibility nightmare similar to the Python 2.x releases. As different features stabilize you enable them which means that all modules using those features only work with that release forward. These changes are higher impact than any of the changes we've seen in core since 0.8 and make compatibility between releases a much more complicated story. IMO it would be much better to say "this is the ES6 release" and enable everything when it's ready. That would mean only one forward compatibility break for the module ecosystem to deal with and only one node version people who are using these features have to worry about hitting when they see ES6 features being used in a module. |
|
@domenic I have the exact opposite perspective on people running with Only crazy people are running that in production. Which is good, we need crazy people, and we need people who are living on the edge and experimenting, that's why the features are available at all behind a flag. For the people who are experimenting it is actually beneficial for the community for them to be opting in to more unstable features because that's the only avenue we have for testing, early usage, and feedback. Core's primary concern should be maintaining stability for the majority of the module ecosystem and production users and not stabilizing the people who are living on the edge and helping us everyday by testing unstable features :) |
|
Note that unlike Python 2/3, ES5/6 is backward compatible in every way. (No ES5 code will break by turning on ES6 features.) In general, I would encourage moving away from a version-number based way of thinking. Much like every other web spec, ES is evolving toward a model that does not consist of rigidly-defined versions, but instead modular features being added periodically, with interplay between the spec and engines informing evolution. The version number is not very meaningful. For example V8 will likely ship Object.observe (ES7) before direct proxies (ES6). Now. If you want to abdicate responsibility for deciding when something is "ready" to V8, i.e. wait until they turn on the flag by default, that's a fine and consistent approach. But we shouldn't pretend they're going to do an "ES6" version suddenly. It's going to be just as piecemeal as what we are contemplating here. |
|
New ECMAScript versions tend to get implemented over a very long stretch of time - if we decide to wait until v8 implements the entire spec, we may be waiting for years for some of its benefits. I also don't think, however, that providing a whole bunch of piecemeal harmony flags is a good idea either. The node team should make the decision on what harmony features can be considered "stable" as of v8 v 3.23, and implement those into node core. Other non-stable features can continue to be accessed by the --harmony flag. Additional harmony features can be added as they become more stabilized, but only in the next major version (i.e. freeze the harmony features that are added in 0.12, and then no new harmony features can be added until 1.0, then 1.2, etc...) |
This is, in theory, true. However, if we enable (say) generators and block functions, but not collections and modules, etc, then you have a state where your module half-works in some versions of Node, but not others. If we enable If I'm just out of the loop, and we can rely on the harmony stuff today, then I agree with @bnoordhuis and @mikeal that it'd be better to just say "Harmony starts at 0.12", and be done with it. Maybe the "broken in Adding an additional symlink, and a check on We should either bite this bullet now, and just turn on Aside: if Proxies are available, I believe we can move most of |
|
@trevnorris Work is underway to get test262 up to speed with ES6. Seeing where V8 I think a lot of people share your reservations about ES6 (me included!), but it is coming, and a lot of people want the features it offers. I also know that it's not just generators or collections that people want -- there's a lively discussion going on elsewhere on how to make Node's module system interoperable with ES6 modules. Some of the more prominent people in that discussion seem to think Node might make the switch! |
|
It may be notable that Firefox is already allowing using "let" to declare variables and allows using Set/Map and other ES6 features and it did not cause the end of the world for them. |
|
@isaacs @domenic When the V8 team feels that something is ready enough that it no longer needs to behind the flag, it's appropriate for it to be merged in. I also think the fragmentation problem can be addressed by linking stable major versions of node (which in current terms means 0.10, 0.12, 1.0 and up) to stable minor versions of V8 (3.22, 3.23, 3.24). If V8 starts dribbling out bits of ES6 in, say, patch releases of 3.24, there's not a lot we can do about that if we want to avoid the pain of maintaining a floating patch to keep up to date with security and stability changes. But that hasn't been the pattern they've been following to this point. In general, the closer we get to 1.0, the less sense it makes to me to just keep dropping the latest stable versions of V8 into the deps folder, especially as the language implemented by it starts to change. |
Yes, definitely, this is the key issue. That was the motivation behind the conversation with @tjfontaine in IRC that resulted in the list about "@domenic's disposition on if they should or should not be enabled" above. That is, that list contains features that, given what I have seen, are up to spec (or in the case of collections, the implemented subset is up to spec) and should not change in future releases in a way that would cause the pain you're talking about. For example we should not turn on --harmony_proxies because it gives a very old out of date implementation. Whereas --harmony_numeric_literals is pretty darn baked. Now, whether that evaluation is entirely rigorous is another story, and feeds in to the questions about test-262 that @trevnorris alludes to and @othiym23 discusses. |
I specifically meant 2.x releases and the forward compatibility breaks between them. All were backwards compatible. |
|
@RushPL Firefox and spidermonkey have been shipping features that aren't spec complete for years in order to test out these features. The fact that they shipped them should not be an indication of their readiness or spec completeness (while in some cases features may be). |
|
Quick question: If we did turn on Even if we can live with what is broken there now it would be nice to have some assurances that it won't actually get worse in the future. |
I would severely doubt that. I guess maybe the fact that we turned it on might force their hand into creating a new flag, I would strongly oppose turning on |
|
Thanks everyone for contributing to the issue, we won't be making this change right now. We can revisit this issue post 0.12, but for now it's too late in the release cycle to introduce such a controversial change. In the meantime Node will continue to let v8 make the decisions for when features are ready to be enabled. |
| } | ||
| // Harmony features. | ||
| if (global.Proxy) { | ||
| knownGlobals.push(Proxy); |
There was a problem hiding this comment.
Just to be clear, this Proxy is an implementation based on the obsolete design. Literally no one should use this for any reason, ever.
Probably better to lead with WeakMap, which is implemented correctly. This reads like an accidental endorsement of use.
Harmony support is probably the most anticipated feature in v0.12.
Enable it by default so module authors can safely assume that Harmony
features like generators and proxies are available. It's possible to
disable Harmony features again with the --no-harmony flag.
Update src/node_contextify.cc to make it stop copying properties from
the parent context indiscriminately. It copies over the Proxy object
from the parent context but the new context has one of its own.
Update test/simple/test-repl.js; it had a test that checks for something
that's prohibited in ES5 strict mode but allowed in ES6, namely block
functions.
Suggested reviewers: I don't know, @indutny, @tjfontaine and @trevnorris? I'm nothing if not inclusive.