Swapping Node.js version should be as easy as `npm i node`

core
1

Meteor should use the locally installed node. Its easy to install any version locally in a project like this:

npm install node@<version>

f.e.

npm install node@^20

or

npm install node@latest

Perhaps this should be the simple override that Meteor can honor as an override for its bundled Node.

Perhaps similar consideration for local npm i npm.

1 Like
2

Just to confirm, do you mean for the app you are building or for all of Meteor?

3

Also let us not forget this article:

3 Likes
4

Just for the particular app, a local install of Node.js in a Meteor project would override the version Meteor would otherwise be using for that specific project.

The Node included with Meteor is a good default, but I think an escape hatch is still valuable. There can be a multitude of reasons someone wants/needs to upgrade/downgrade.

It’s better than being stuck with no recourse.

As one example, I simply like to have the latest npm features, without waiting on Meteor.

5

I think the whole Meteor 3 work is an example why it is not that easy or desired. Meteor has many parts some very closely integrated into Node and some not so much. Some packages that Meteor uses change and evolve including their names and APIs.

3 Likes
6

What is the current alternative if we want to bump node version patch number without upgrading Meteor?

7

You can’t:

If you want to bump Node in Meteor on your own, you will have to do it yourself.

See this PR on how to get started:

8

I guess @trusktr’s point is that given this is a +2 -2 diff, it would make a lot of sense to make this configurable instead of having to release a patched version of the code every time there is a security patch for Node. Meteor could implement some warning when the version is different from the default one. The severity of the warning could depend on how distant the configured version is from the default one (major, minor, patch).

9

The PR I moved as an example is just the first step. You then need to do quiet a few more things before you have something workable. One of them is to check that the whole thing actually runs and make any changes as necessary.

10

Any problem on using a global npm install vs meteor npm?

11

We have a different approach: I think it is a bad idea in general to somehow rely on a “random” version of node. So, instead of using any kind of global node, we always use the node version that is shipped with meteor. What we do:

  • We have a bin directory…
  • in this bin directory, I symlink to meteor node
  • then in an activate-meteor (similar to python venv activate) I set the PATH to point to the correct version of node

Note this will not work on Windows (we gave up supporting windows for complex apps because scripting is very different on Windows, and it does not support symlinks (to files))

12

Meteor 2 is using Node.js 14. I did figure out where is Node.js fork by Meteor, binaries for those, and compiled from source for remaining platforms:

I build bundles for:

  • Windows amd64
  • Linux amd64, arm64, s390x

Running Meteor at Windows is possible, if you don’t use git submodules and symlinks.

Installing at Windows:

Installing at Mac:

Info how to run these bundles is at Raspberry Pi · wekan/wekan Wiki · GitHub

First I build Linux amd64 bundle. Then at each OS/CPU, I make some changes, like install fibers, that is required to be built for each OS, with build-bundle scripts here:

Although currently Node.js 14 does segmentation fault at s390x, so I’m trying to upgrade to Meteor 3:

Previously I did also build for ppc64le, but then OpenPower Minicloud was closed:

I did previously get building with Meteor working also at Linux arm64 with that In Progress PR, but after that when I tried it did not work anymore, I’ll try again later, that PR is not yet merged to Meteor:

2 Likes
13

Additionally, there is Snap Candidate package snapcraft.yaml, and Dockerfile for amd64 and arm64. For using Docker, there is docker-compose.yml . Those at GitHub - wekan/wekan: The Open Source kanban (built with Meteor). Keep variable/table/field names camelCase. For translations, only add Pull Request changes to wekan/i18n/en.i18n.json , other translations are done at https://app.transifex.com/wekan/ only.

1 Like
14

Yeah, you might use global npm with new Node, everything seems to work fine, but then in CI or deployment the non/node version is not the same and it doesn’t work.