You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jan 5, 2020. It is now read-only.
Repository navigation
This repository was archived by the owner on Jan 5, 2020. It is now read-only.
Supported ES features are determined by the V8 version, not Node. Incidentally this will make it easier to support Node.js versions that gain new language features in a minor, like the Node.js 7 releases.
Not sure it's worth complicating it for such limited gain. Needlessly transpiling a few tiny features won't give any noticeable performance gain. Reusable modules always have to target the oldest major as you can't guarantee people upgrade every minor versions. I think we should prioritize UX here, it's a lot easier to define a Node.js version than having to look up the V8 version. Let say in a company they define V8 5.8, where 5.7 is the oldest for that major version, then they have to ensure that everyone is on the latest minor, not only major, which makes things very complicated.
Not sure it's worth complicating it for such limited gain.
I think it'll be easier to understand which plugins are required for which V8 version than doing it for a Node.js version.
Reusable modules always have to target the oldest major as you can't guarantee people upgrade every minor versions.
Researching what's supported in major.0.0 is trickier than comparing V8 versions, since those are cut roughly every six weeks. The supported features can be determined by marketing material.
I think we should prioritize UX here, it's a lot easier to define a Node.js version than having to look up the V8 version. Let say in a company they define V8 5.8, where 5.7 is the oldest for that major version, then they have to ensure that everyone is on the latest minor, not only major, which makes things very complicated.
This doesn't really impact anybody else though. You use this preset and stuff will just work.
Needlessly transpiling a few tiny features won't give any noticeable performance gain.
We're not transpiling features in order to gain performance. Indeed on older V8 versions transpiled code may outperform the native implementation. Instead we're trying to reduce source transformations that may have to be corrected through source maps, in AVA's case as it relates to stack traces, but for others it could impact code coverage.
Activity
sindresorhus commentedon Feb 13, 2017
Not sure it's worth complicating it for such limited gain. Needlessly transpiling a few tiny features won't give any noticeable performance gain. Reusable modules always have to target the oldest major as you can't guarantee people upgrade every minor versions. I think we should prioritize UX here, it's a lot easier to define a Node.js version than having to look up the V8 version. Let say in a company they define V8 5.8, where 5.7 is the oldest for that major version, then they have to ensure that everyone is on the latest minor, not only major, which makes things very complicated.
novemberborn commentedon Feb 13, 2017
I think it'll be easier to understand which plugins are required for which V8 version than doing it for a Node.js version.
Researching what's supported in
major.0.0is trickier than comparing V8 versions, since those are cut roughly every six weeks. The supported features can be determined by marketing material.This doesn't really impact anybody else though. You use this preset and stuff will just work.
We're not transpiling features in order to gain performance. Indeed on older V8 versions transpiled code may outperform the native implementation. Instead we're trying to reduce source transformations that may have to be corrected through source maps, in AVA's case as it relates to stack traces, but for others it could impact code coverage.
Select plugins based on v8 version
Select plugins based on v8 version