Support engines field when .nvmrc / .node-version are not present#839
Support engines field when .nvmrc / .node-version are not present#839Schniz merged 25 commits intoSchniz:masterfrom
engines field when .nvmrc / .node-version are not present#839Conversation
🦋 Changeset detectedLatest commit: 88bc36a The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
The engines field is a range, not a single version, and affects consumers - it’s not meant to be used for the developer’s node version. If the feature only worked when the app is private: true, then at least that would avoid the risk of breaking consumers, but it’s still a conceptual mismatch to use a ranged field for a single version. |
Schniz
left a comment
There was a problem hiding this comment.
lgtm overall. What do you think of my comments?
|
That's really great. Is there any way to auto-detect this? My shell already starts |
|
fnm env --use-on-cd works with this feature for auto detection |
|
If not, let us know |
|
Yep, just add (I'm using Zsh) eval "$(fnm env --use-on-cd --resolve-engines)" |
|
Oh wow, indeed, simple! Thank you guys! |
|
yeah seems like it's broken on |
|
it failed when I tested on a docker container, yet worked on my machine: it's because I'm using |
|
I found it not work on Windows (PowerShell): |

Summary
Adds support for
enginesfield inpackage.jsonso having the following is supported withfnm useandfnm install:{ "name": "my-thing", "engines": { "node": ">= 13.3.7 < 14.0.0" } }(Relies on #816 and #991)Since this isn't directly equivalent to the "locked" nature of

.nvmrcor.node-version, this feature will start as experimental, and behind an opt-in--resolve-engines: