Include `engines` and `devEngines` fields in `package.json`?

[mao-sz]

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]

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

[mao-sz]

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

[JustWaveThings]

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.

[mao-sz]

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

[JustWaveThings]

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

[mao-sz]

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]

@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?

[mao-sz]

@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]

@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.