Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will this include current versions of Node that have dropped support? For example v7.x is being cut later this month. Support for it drops in April. Will yarn continue to support v7.x for an extra 8 months? The usage statistics that we saw had a pretty major drop off of v5.x when v6.x was cut
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Made concrete, if
v7.X
ceases receiving support on April 1, 2017 then this proposal states that all versions of Yarn released before April 1, 2018 should work in v7.X. On April 2, 2018 any new release (be it major, minor, or patch) may drop support for v7.X.Usage statistics are almost an aside here, we have to decide how much we want to help the long tail move after their version of Node.js has ceased receiving support. It's possible that many packages in the ecosystem will require certain modern Yarn behavior which would instead make the upgrade process require multiple steps:
From our experience in the Ember community it's incredibly difficult to install a working set of dependencies for an out-of-date version of Ember if we need to make a security patch. We've written tooling to help us get insight into how things have changed between dates. Adding more variables into that process will make it a miserable experience.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why should we support Node.js versions that Node themselves don't support? How much value is there in continuing to support EOL builds of Node?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't that depend on what users choose to do? node's dropping 0.10 support this month, but if actual usage doesn't drop, then everyone else should still probably be supporting it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Daniel15 Foundational tools in an ecosystem need forward and backward compatibility guarantees which are stronger than most projects. The package manager is the gateway to the ecosystem in a way that even Node.js isn't and in my estimation should help provide a bridge for late upgraders. @ljharb also makes a salient point: just because it is unsupported doesn't mean it is unused or was used to bundle an old package which needs a security update.
This exists as the current state of
npm
which dropped testing of 0.8 in only June of this year.The costs to this (since Yarn already transpiles) are much smaller and generally limited to API surface area added to Node.js. Any of these changes which are truly required (by rule they won't be since it will have worked in those versions before they were deprecated) can have a module written for it to polyfill the functionality. Delaying adoption and writing node packages is even good Node.js community stewardship as it provides tools for community members to incrementally migrate to the future.
Ember's policy (disclosure: author) guarantees that the HEAD of the master branch works without transpilation until the day Node.js ceases support. This makes it easy for us to maintain support for already-released versions. These tradeoffs are not fun but are required to build trust within the community.
Note that I find it completely legitimate that Yarn never supports 0.10 or 0.12 as those were already closing in on EOL at launch.