Can we specify newer Node.js and NPM versions for Meteor to use? šŸ¤”

core
1

Is there a non-internal (f.e. cli option or package) way to force Meteor to (at least try to) use newer versions of Node.js and NPM?

The current versions are a bit old.

2

I think we will need to wait until Meteor release version 3.0 (no fiber)

2 Likes
3

Simple answer is no. That has been an intentional design decision from the very beginning to tie a specific NodeJS version to a specific Meteor version.
See this old article for more info:

That said, you can always checkout the Meteor GitHub repository and change it yourself. As for updating to newer Node, well if you look a bit around you will find that work towards that has been the main focus for a about a year. Getting close:

2 Likes
4

Hi, curious to know which features of newer Node.js are you eager to useā€¦

Since Node.js 14 is still under LTS Iā€™m assuming you are trying to take advantage of a new feature that is not available at 14, right?

BTW, as Jan said Meteor chose in the past to pin versions of specific technologies such as Node.js, NPM and MongoDB. It is a good choice in terms of easy of installation and stability but of course it limits the ability for users to customize their environments.

Itā€™s not that hard to upgrade these versions yourself but right now with Fibers incompatibility with Node.js 16 this is not possible at the moment.

2 Likes
5

I had problems with using newer packages: some depend on newer node (package.json engines field), so meteor npm install fails with an engine incompatible error.

6

Hello,

Is it possible now? If yes, please let us know how

7

Got it.

With Meteor 3 going forward with Node.js 20, I believe these problems are gone.

And without Fibers, we should be able to move much faster in Node.js releases :crossed_fingers:t2:

Do you think itā€™s better to have more freedom or a better test suite against the exact same version of Node?

I know itā€™s a tradeoff but IMO Meteor made the right choice.

2 Likes
8

Itā€™s not possible right now for many reasons, but it should be straightforward in the future (Meteor 3 forward).

One idea: we could have different releases of Meteor with different embedded Node versions if users start to come up with valid reasons to adopt a particular version of Node.js that is also compatible with Meteor.

Meteorā€™s versioning system has built on the concept of tracks. We donā€™t use it nowadays, but that would be an option, different tracks for different Node.js versions.

I would do that if we have multiple versions of Node.js under LTS with significant differences in features. I donā€™t think this is the case now.

Another option would be to have a track called next with the next version of Node.js (usually the current one in development) for people feeling brave :grin:.

The latter would benefit everybody as brave developers using the latest tech could find bugs in advance :wink:

Anyway, I think this is an interesting discussion, but only after the Meteor 3 final release.

2 Likes
9

Indeed, getting rid of Fibers, and any packages that require binaries, will help a lot. If all the packages Meteor depends on are plain JavaScript, thatā€™ll be the best way to move forwartd very very quickly.

I forsee this will solve a lot of issues, but it might still be possible someone who is installing custom packages with binaries may need to stick to certain versions until they have workarounds or packages are updated.

1 Like