Discussion to avoid node version incompatibility with LTSs #19050
Comments
cvializ
changed the title
|
A few notes to help start the conversation: We agreed to use the latest LTS version of Node to avoid supporting multiple Node.js releases with features that may or may not be compatible with transpilation. Some of the initial motivation regarded the use of Simultaneous LTS branches will be the new normal. This issue will continue to impact projects like AMP while there are several active LTS branches of Node. There are three active LTS branches with Dubnium entering active LTS support today. If we choose to support multiple LTS branches we will need to ensure all build system code complies with the lowest supported LTS version.
According to the schedule, there will be three active LTS branches from now until at least April 2022. New LTS Releases can cause instability in the Project
|
|
I'm ok with abandoning v6. It's no longer getting updates. But abandoning v8 just because v10 became the active LTS doesn't make good sense. We're just cutting off potential users. |
|
There is definitely a tradeoff. Supporting multiple versions means we need to ensure (via travis) that each commit works against the supported versions. When debugging an issue it will be important to know which versions are impacted. Developers working on the AMP codebase will likely need to use As code is changing, we should have a strong preference around the usage of Node features if we support multiple versions of Node. Should all build code be transpiled to ensure it runs against the oldest supported version? Because of these factors, I'd ask we support a single Node version going forward, and only one at a time. "lts/*" meets this criteria.
Let's see if any of the AMP design principles might assist in an answer. User Experience > Developer Experience > Ease of Implementation. This issue only impacts the ease of implementation, since developers of author pages shouldn't need to run the repository to test their documents. As a result, its by far the lowest priority for informing a design decision. Don’t design for a hypothetical faster future browser. No impact. Don’t break the web. Potentially supporting only a single node version reduces the time for a Travis build to complete, but they are run mostly in parallel (so the impact isn't that significant). If the version of AMP that is deployed is broken, pushing a fix could be slower. However, we also would likely rollback before pushing a fix – likely no impact. Solve problems on the right layer. No impact. Only do things if they can be made fast. No significant impact, newer versions of Node incorporate later versions of V8 which should improve overall build performance. However, the delta is likely low enough to be immaterial (metrics would help inform). Prioritise things that improve the user experience – but compromise when needed. No impact. No "nicelists" or "allowed lists". No impact since this relates to allowlists for special treatment of domains. |
|
Thank you @kristoferbaxter for the detailed writeup! 👍 I like a lot of the points made, and agree it may be a good idea to only support one node version. Supporting multiple keeps coming up with these problems that we are facing, and have a hard time dealing with. However, this leads to a few issues:
However, I have another idea. Can we soft-support the latest stable? As in, we claim to only support LTS, but to avoid the headache of having to scramble to fix things for the newest node versions when the LTS changes, add the stable to our current Travis build pipeline, and throw warnings whenever something is breaking on Stable. That way our team can start to think about and open issues on things that will break. And anyone jumping into the project with whatever node version should be able to start developing without any issues 9/10 times 😄 . Any issues of them using features in the newest node version will be caught by travis, and they can do the usually small amount of refactoring to get their code working. 👍 Let me know what you think! |
|
Since LTS branches change once a year is it really that much of a burden to require the highest LTS version that's available? It's not hard to install a new version with |
|
Yes, I agree LTS changes don't happen to often, and changing them once a year isn't too bad 😄 But I guess I am speaking more for the developer who may be new to development, or, a developer who doesn't work on AMP regularly. In both cases, it can be an extra step that can be annoying quickly if you are jumping around projects, or trying to understand why things aren't working. Though, I may just be nitpicking on their behalf. Let me know what you think 😄 |
|
It sounds like what we need to do is change the requirement from LTS to a major version number. The version we select should always be in the LTS window and when a new LTS is available we should test it in the CI/CD chain and make a change to the tooling requirement on our schedule (but always before the current version EOL). This still means devs have to update their toolchain so @torch2424's point about dev workload is still valid (although only once a year). That's unavoidable as we'll always need to deprecate node versions as they fall out of their maintenance window. |
|
The issue with pinning to an exact version is delayed upgrades via manual enforcement. Although infrequent (~ once a year), the delay in upgrading can be removed entirely by using Downsides:
Upsides:
|
|
I was suggesting pinning to a major version. eg Another approach would be to let greenkeeper do it on the basis that if it tries to update no in a way that breaks the test will catch it and it won't get merged. |
|
driving by 🚗 I would argue that "we support LTS" is a much clearer message than "we support X and Y". It's also easier to develop against, since the only contextual information needed is that support for LTS is available and so are its features. The hurdle of switching Node versions should be just as frequent regardless of the versions we choose to support, assuming we're trying to keep a modern codebase. Automating version switch (e.g. testing) is a problem regardless of the decision taken here as mentioned by @kristoferbaxter. However, by only supporting LTS we can fully automate the process, including the trigger (i.e. LTS version switch). |
This is what Travis is for.
I think this is minor issue. As far as I'm aware, we've only had one issue with using a v8 feature when we were still supporting v6.
The infrastructure team, only. Everyone else will be fine with whatever they have installed during their setup.
I think you're overstating the speed at which normal devs adopt new features, and the speed at which features are added to node. This is the build side of the project, not the actual code we're trying to ship to users. Note that Babel itself doesn't try to use the latest features, it complies down to whatever is appropriate.
@rsimha might be able to respond with issues that are raised every time we node releases a new version. Every time, one of the native build dependencies breaks because it wasn't updated to the new native APIs. Using a rolling, non-pinned major target is a terrible decision, regardless of our v8 vs v10 debate.
Devs don't always control the version. For instance, I had a discussion with the GCP devs about how they were still locked to v6 earlier this year. But for normal devs on their own machines, I think We don't gain any features by forcing v10 as the minimum version. The release summary for v9 and v10 doesn't have any necessary features node features. Even looking at node.green, the only language changes I can see are Shared arrays, |
|
Thanks for starting this discussion. To recap, The 10.0 LTS release broke us because we pinned our project's To fix this, the plan (after discussing with others) is to enable node version updates from Renovate using Edit: We'd also need to revert the version specified in |
Would this mean that Travis would not test against older (but still active) LTS releases? |
Correct. As configured today, Travis will only test against the latest active LTS. In order to run all tests on Travis against the latest LTS, we'd need to double our VM usage. The argument could be made for merely making sure the runtime builds correctly on older active LTS version(s), but I'm not sure if that's a large enough benefit, given that we expect a subset of development to be done using those versions. |
|
Update: According to https://github.com/nodejs/Release, node 8 has entered Maintenance LTS status. The current active LTS is node 10. I'll send out a PR. |
|
One year later, we've run into similar problems once again, due to node's latest active LTS going from 10 to 12. The latest discussion on this topic can be found at #25209. (Bumping this old issue to link the two.) |
We want to avoid needing to transpile features changing between LTS versions. But we also want to support the lowest common denominator until we decide to migrate off of
^8.0.0.@jridgewell @kristoferbaxter
The text was updated successfully, but these errors were encountered: