Conversation
alexvuong
added
the
skip changelog
.github/workflows/test.yml
Outdated
| - node: 16 | ||
| npm: 10 | ||
| node: [20, 22] | ||
| npm: [10, 10] |
There was a problem hiding this comment.
Node 18 is still in LTS for 5 more months. What is the timeline for this upgrade?
There was a problem hiding this comment.
Good call. I believe we have to wait til MRT officially supports Node 22. I think at least one more RP to start this upgrade. I think it is safe to remove 16 for this upgrade since it is already out of support timeline. I'll leave 18 and will remove if it is out of support timeline by time we officially do the upgrade
| # The "default" npm is the one that ships with a given version of node. | ||
| # For more: https://nodejs.org/en/download/releases/ | ||
| # (We also use this env var for making sure a step runs once for the current node version) | ||
| # Note: For node 18, the default was npm 9 until v18.19.0, when it became npm 10 |
There was a problem hiding this comment.
If we end up moving forward. Don't forget to remove comments about unsupported versions.
| }, | ||
| "engines": { | ||
| "node": "^16.11.0 || ^18.0.0 || ^20.0.0", | ||
| "node": "^16.11.0 || ^18.0.0 || ^20.0.0 || ^22.0.0", |
There was a problem hiding this comment.
As an aside, I wonder if we should simply adopt nodes support model or a modified version of it, e.g. we only support active node LTS. Then at most we'll probably have 3 versions here.
There was a problem hiding this comment.
Although some Node version may be in maintenance but they are still within Life-of-support timeline. IMO, when we do upgrade, we can simply drop the node versions that has no longer support officially. That would also leave us with around 2-3 version here
2 participants
Description
Types of Changes
Changes
How to Test-Drive This PR
Checklists
General
Accessibility Compliance
You must check off all items in one of the follow two lists:
or...
Localization