rfcs
rfcs copied to clipboard
yarnpkg
Node.js LTS Policy
thanks for pinging me @nathanhammond perhaps we can discuss on a future @nodejs/lts wg meeting
I'll comment in line with thoughts
Just heads up that we probably want to solve a lot of things in order around governance, release processes, etc. There's a lot going on right now having just released and being flooded with issues, so don't expect a ton of immediate movement on this for those reasons.
@thejameskyle Yep yep, just opening this as Ember's resident LTS policy wonk (note the byline on Ember's announcement). Hopefully helpfully informing the release plans and strategy is all. 😄 Excited to participate in conversations around this topic and provide perspective and eventual documentation in this RFC.
Note that npm appears to have elected to follow the Node.js LTS guarantee and dropped 0.10. However, it has additionally dropped 0.12 from testing: https://github.com/npm/npm/pull/14503
npm's LTS strategy lacks a tremendous amount of concrete detail:
-
npmhas no stated explicit degree of support for their versions as tied to the Node.js LTS versions. - Secondarily (and not explicitly related to this RFC)
npmhas no stated explicit support timeline guarantees attached to their own version releases.
The lack of clarity and current churn makes the guarantee proposed by this RFC stronger than any existing ecosystem behavior which I find commendable. Whether that is reasonable is of course up for debate, thus the RFC.
As a caveat, this urgency to get off of 0.10 and 0.12 may be a special case due to their age. We may not see this when we eventually drop 4.X support.
/cc @othiym23 @seldo
Also worth noting: maintaining support for older nodes, even EOL'd ones, ensures that those stuck on those node versions have a smooth upgrade path. If both npm and yarn stop working on node 4, then that may mean many people are stuck on node 4 forever, because they'd have to coordinate both a node and npm/yarn upgrade simultaneously.
I really hope yarn is very very cautious in dropping support for platforms it currently supports, unrelated to LTS schedules.
@ljharb
Also worth noting: maintaining support for older nodes, even EOL'd ones, ensures that those stuck on those node versions have a smooth upgrade path.
I thought part of the reason for publishing and forecasting the LTS, maintenance, and EOL dates was to give folks stuck on older versions a heads up and plenty of time for a smooth upgrade path. For example, the EOL of Node 0.10 was public ~1.5 years before it hit, similarly for v4, v6, etc.
@jdalton yes, that's part of the plan. but just because that's the goal doesn't mean users universally do that. 0.10 is EOL now but plenty of people still use it in production - when their companies are ready to upgrade to 4, yarn (and hopefully all of their dependencies) won't add friction to that process, even if they're slower than the LTS plan desires.
@ljharb
but just because that's the goal doesn't mean users universally do that. 0.10 is EOL
There's got to be a cut off at some time and I think the LTS and maintenance dates are good ones considering how much lead time they afford.
Folks don't have to always use the latest and greatest packages and if they're truly stuck on an unmaintained Node version then they're likely resorting to dep pinning strategies anyway.
Obviously a line must be drawn somewhere. I'm arguing that it's most beneficial to the users to support as far back as possible, even beyond official support dates.
In other words, support for a platform shouldn't be dropped unless there's a very very good reason, and "i don't want to transpile" or "i want to use a shiny new feature but it's possible to implement without it" are not good reasons.
@ljharb
I'm arguing that it's most beneficial to the users to support as far back as possible,
Naw, that's impractical and unrealistic.
In other words, support for a platform shouldn't be dropped unless there's a very very good reason, and "i don't want to transpile" or "i want to use a shiny new feature but it's possible to implement without it" are not good reasons.
Teams don't have infinite bandwidth. Older enviros are a tax on testing, triage, and features.
Following the LTS schedule is a good place to draw the support line. Currently that means testing 0.12, 4, 6, & 7 which is a pretty good amount.
CI runs the tests on 0.10 just as easily as 0.12. There certainly may come a time when there's a cost - and that is the time to evaluate dropping support. But there's no value in dropping support as a matter of course.
@ljharb
CI runs the tests on 0.10 just as easily as 0.12. There certainly may come a time when there's a cost - and that is the time to evaluate dropping support.
It's not free. Additional CI runs add to the cumulative test cost and support overhead.
@ljharb
It runs in parallel and adds to travis-ci's costs, not the maintainers'.
It's not that simple. Test fails can hold up PRs, complicating contributions, and they do incur a maintainer cost. Someone's got to track down those test fails after all. It's easy to suggest supporting as many versions as possible but it's a bit different when you're on the hook for that support.
With the current LTS schedule that's a 1.5 year lead time for dropping older Node versions and supporting like four major versions of Node at a time. That seems totally reasonable.
I'm arguing that it's most beneficial to the users to support as far back as possible,
For every new Yarn release, or just for some legacy series of releases? What if we were to do something like dropping Node.js 0.10 support in Yarn 1.2.x, and Node.js 0.10 users could continue using Yarn 1.1.x and it'd only get major bug fixes (no new features)? If they're on a legacy Node.js version that no longer gets updates, it seems reasonable to do the same thing here too.
support for a platform shouldn't be dropped unless there's a very very good reason, and "i don't want to transpile" or "i want to use a shiny new feature but it's possible to implement without it" are not good reasons.
Do your sites support IE6? You don't need shiny features like SVG, flexbox, or border-box sizing, right? 😉
It's not free. Additional CI runs add to the cumulative test cost and support overhead.
Older versions could have a lower level of support and just run nightly tests rather than having them run as part of every commit / pull request. I've already got a Jenkins instance running end-to-end tests for Yarn (spin up Ubuntu Docker container, install Yarn, run yarn add react, ensure it works), we could have "super legacy Node.js testing" run nightly too.
@Daniel15
Older versions could have a lower level of support and just run nightly tests rather than having them run as part of every commit / pull request.
Sounds like you're volunteering to maintain them :grinning:, and that's cool. But as Yarn's open issues creep towards the 400's I think it's going to be a drag.
As mentioned the current LTS schedule seems totally reasonable on its own.
I don't think I'd have enough time to maintain older versions, unfortunately. It was just a suggestion of one possible approach - I certainly don't think that legacy Node.js versions would have the same level of support as current ones 😄
@Daniel15 if you retain support by default, then let me know when you run into a problem maintaining support for an "old" version and I'll be happy to contribute the 20 minutes required to overcome the hurdle.
@ljharb
if you retain support by default, then let me know when you run into a problem maintaining support for an "old" version and I'll be happy to contribute the 20 minutes required to overcome the hurdle.
If you'd like to run an unofficial fork to support unmaintained Node versions that could be rad. It shifts responsibility to someone like you, that's super energized for Node 0.10, 0.8, & so on while letting Yarn follow the LTS schedule.
Lets focus on the contents of this RFC and discuss the more impactful details.
I think it's a worthwhile goal to fully support versions of Node that are currently maintained, but I also don't see any need to intentionally break or refuse contributions to maintain support for older versions of Node.
Should deprecated versions of Node be tested against in CI? I'm not sure I see a need for that. The community is upgrading to new versions of Node faster than ever before. Also, Yarn didn't exist in the days of 0.10 or 0.12, so I don't expect people who are unwilling or unable to upgrade to be amongst the early adopters of Yarn.
That being said, it's a detail that doesn't really matter for the purposed of this RFC. If you want to talk about CI, open an issue in the main repo. It looks like we're only testing against 4 and 6 right now and we should probably expand that anyways.
Note that with the hurdle of having a Node.js LTS policy for Yarn cleared Ember intends make official its support–which will bring an influx of users and maintainers (Hi!). We care deeply about the experience of our users and want for their experience to be the best possible. This carries over into the community projects we adopt–we're far from passive consumers.
@jdalton I tend toward the opinion of @ljharb on this. npm didn't drop support for 0.8 until June of this year. The drop of 0.10 already as well as the (seemingly) early drop of 0.12 came as a surprise to me (ping me out of band if you want to hear unfiltered thoughts on the matter). One place where I want to be careful: I firmly believe that untested == unsupported. It's far too simple to use an unsupported language feature and find yourself with a non-working build.
Yarn should only ever support 4+ (given its release timing) and this RFC proposes supporting this for one additional year beyond the last day specified by the Node.js LTS date. This is of course negotiable and should be discussed at length amongst the Yarn core team as well as here. As long as Yarn meets or exceeds the Node.js LTS policy then anything beyond is a decision on how much to invest in increased effort for feature development versus returns in goodwill from the community.
Anyway, just the resident policy wonk's opinions.
@nathanhammond
npm didn't drop support for 0.8 until June of this year.
I don't think yarn should necessarily follow npm's path.
this RFC proposes supporting this for one additional year beyond the last day specified by the Node.js LTS date.
There's already a 1.5 year heads up in place by the LTS policy, which is pretty generous. Adding another year, making that a 2.5 year heads up, seems a bit drawn out.
As long as Yarn meets or exceeds the Node.js LTS policy then anything beyond is a decision on how much to invest in increased effort for feature development versus returns in goodwill from the community.
I dig it.
It seems to me that no one from the core contributors is willing to spend time on providing these guarantees. Unless someone is willing to contribute by keeping track of issues, setting up and maintaining CI and promoting wider Node.js compatibility I think we should close this RFC.
@bestander Realistically this isn't actually asking Yarn to make any changes, just to set a policy. That policy could be "YOLO, we could decide to stop supporting anything less than Node.js 7 tomorrow." It could be "We will support any version of Node.js which is still officially supported per the Node.js LTS Working Group." It could be the one I drafted here which is intentionally beyond the support of the Node.js LTS Working Group.
Regardless of what the text of the policy says Yarn should present some policy to make it possible to communicate to the community the expectations they should have. That much is table stakes for a foundational infrastructure project.
@nathanhammond you are right this would be desirable but right now putting a policy in place wouldn't affect anything. We simply don't have the resources to follow any one policy other than "fix and stabilize Yarn as much as possible". We should re-evaluate after that.
Alternatively, if there are people that are willing to formally commit to uphold whatever policy we'd put in place, that would make it easier to merge this RFC. For example if there is a volunteer to support all Node LTS releases, we'd be supportive of this policy.
@cpojer To my mind, an explicit policy could only help with the problem of limited resources. "Fix and stabilize Yarn as much as possible" is an inherently unbounded statement so it seems like it would make sense to constrain it to "fix and stabilize Yarn for Node version x+". That doesn't preclude expanding the range of supported versions at a later date, it just allows you to focus on a subset of the existing issues.
@xtian: Just to be clear here; our plans for Yarn at Facebook have measurable goals internally at Facebook and one of them is to stabilize Yarn over the next couple of months. To that extent, we will focus on making Yarn work well for the version of Node we use at Facebook (currently Node 6 but may change any day). Yarn is an integral part of our internal JavaScript infrastructure and we need to make significant improvements still.
Yarn is not a Facebook project, we merely have a seat at the table here rather than owning the table. From our perspective, we are willing to contribute as much to Yarn as we can but @bestander alone (the only person currently working full-time on solving third party JavaScript dependency management at Facebook) cannot uphold such a policy without help. Again, just to repeat, we are supportive of deciding on a real policy but we will need support from the rest of the community project.
"Focus on making Yarn work well for the version of Node we use at Facebook (which may change any day)" is the implicit policy I had assumed for Yarn, but I think there is value in making it explicit as it can help the community make informed decisions and direct its effort to the areas where it is most needed.