Skip to content

Include engines and devEngines fields in package.json? #680

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
MaoShizhong opened this issue Mar 9, 2025 · 11 comments
Open

Include engines and devEngines fields in package.json? #680

MaoShizhong opened this issue Mar 9, 2025 · 11 comments
Assignees
Labels
Status: In Progress This issue/PR has ongoing work being done Type: Chore Involves changes with no user-facing value, to the build process/internal tooling, refactors, etc.

Comments

@MaoShizhong
Copy link
Contributor

MaoShizhong commented Mar 9, 2025

The repo currently does not specify which version of Node the bot is deployed on, so there is a chance that code runs locally but breaks in prod if it's running on a version that doesn't have a newer feature.

Recently, I had a PR that Fred reviewed that broke with one commit because I unknowingly used a Node v22+ feature and he was still on v20. Finding out what version the bot is deployed on (if available, able to bump it to the latest host version?) then setting that as the max in package.json would help prevent any such bugs.


Edit: Accidentally created a blank issue. Happy to add this in if we can found out the exact version the bot is deployed on.

@JustWaveThings JustWaveThings added Status: Investigating Something in this issue/PR is being investigated Type: Chore Involves changes with no user-facing value, to the build process/internal tooling, refactors, etc. labels Mar 9, 2025
@JustWaveThings JustWaveThings self-assigned this Mar 9, 2025
@JustWaveThings JustWaveThings added the Status: In Progress This issue/PR has ongoing work being done label Mar 9, 2025
@JustWaveThings
Copy link
Contributor

I'll take this one Mao, if you don't mind. Good call out! I forgot all about that.

@MaoShizhong
Copy link
Contributor Author

No problem at all, it'll likely be quicker that way.

@JustWaveThings
Copy link
Contributor

This is helpful - Heroku Node.js docs:

If a Node version isn’t specified in the engines section, Node.js 22.x is used automatically. You can also specify a minor range such as 22.11 or an exact version, like 22.11.0.

Going to wait to get access to the app before I PR the change, but it should be as simple as adding what the docs say. Emphasis on should.

@MaoShizhong
Copy link
Contributor Author

Awesome. Going by that then I'd assume Heroku updates their v22 minor automatically on/near release?

@JustWaveThings
Copy link
Contributor

Yep! As long as we don't peg it to an exact version.

@MaoShizhong
Copy link
Contributor Author

Wouldn't it be more appropriate to set a specific minor? Some features get added in minors so if it was set to 22.x then people can still run it with 22.0.0 yet run into errors if a later-minor feature is used. Niche situation but possible.

@JustWaveThings JustWaveThings removed the Status: Investigating Something in this issue/PR is being investigated label Mar 21, 2025
@JustWaveThings
Copy link
Contributor

@MaoShizhong the version pegging is more for Heroku, If I understand it correctly. If we aren't explicit, Heroku will update Node minor versions as they are released. I think I'd rather have bit more explicit control over what version Node the production bot is running.

Does that make sense, or am I missing something?

@MaoShizhong
Copy link
Contributor Author

@JustWaveThings Hang on, are you saying you do want to set a specific minor version or do not want to do so (e.g. 22.X)? Your latest message implies the former while your original message implies the latter to me.

I feel like we should set a specific minor so that it forces it to be developed in the same runtime version as in prod, else someone could run into errors if they run a lower minor version that's missing features from a later minor that the code is using. Example, path.matchesGlob is available only from v22.5 onwards, so if the codebase used it but was set to allow v22.x, someone could be running v22.4 and get a not a function error instead of being told they need to install and run v22.5.

Then again, the examples I could find of method additions like this are generally experimental and niche things, so depends how strict you want it to be.

@JustWaveThings
Copy link
Contributor

@MaoShizhong , I apologize for the confusion. I am with you. I think the best course of action is to set an explicit minor version of Node to avoid the issue you illustrated, as well as have more control over the production instance.

@MaoShizhong
Copy link
Contributor Author

Yep! As long as we don't peg it to an exact version.

Ah, I get what you meant by this now. I misread it as you suggesting we don't peg it to a specific minor

@MaoShizhong
Copy link
Contributor Author

Was looking more into this and came across (nvm-sh/nvm#651) where I learnt that engines.node does nothing for the dev as I originally thought, and is only for package consumers to notify if engine compatibilities clash.

npm can now read a devEngines field though, where something like

  "devEngines": {
    "runtime": {
      "name": "node",
      "onFail": "error",
      "version": "22.14"
    }
  },

will error if any npm command is run and it's not using Node 22.14.X, which is what I was originally requesting.

engines.node will still be read by Heroku though so it can set the deployment env. That would mean pegging the version in both engines.node and devEngines.runtime in package.json, so no single source of truth.

@MaoShizhong MaoShizhong changed the title Include engines field in package.json? Include engines and devEngines fields in package.json? May 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: In Progress This issue/PR has ongoing work being done Type: Chore Involves changes with no user-facing value, to the build process/internal tooling, refactors, etc.
Projects
None yet
Development

No branches or pull requests

2 participants