Use package.json fields?

[joshgav]

Some installers and tools attempt or would like to use the package.json engines field to select a Node version, see here, here and here.

Should a version manager use fields from package.json, and if so which ones and in what ways?

---

NB: Originally I suggested that this group document all of package.json, but thought better of it per the first few comments below.

[ljharb]

Reading from package.json is not easy in POSIX environments, and I don't think a node version manager should be reading from package.json at all - thus I don't think we should be concerned with package.json fields.

[coreybutler]

I agree with @ljharb in regards to not reading the local package.json from a version manager, primarily because package.json is a product of npm, not node itself. It is entirely possible to execute scripts without a package.json file (or even npm) present... even if that is a minority of users.

@joshgav - Has the VM neutrality group proposed any kind of standard for identifying which underlying engine should be used? Is package.json a contender for that?

[joshgav]

Okay fair points :). In addition to engines I was also thinking about base paths that package.json assumes like "node_modules", but after thinking a bit more it seems package.json is in fact downstream from those decisions rather than a part of them.

So let's rephrase this issue as:

1. should version managers and installers rely on fields in package.json for anything, and if so
2. which ones (e.g. engines) and in what way?

@coreybutler

Has the VM neutrality group proposed any kind of standard for identifying which underlying engine should be used? Is package.json a contender for that?

AFAIK that group hasn't considered the question, and in fact it might be something for this group to consider. /cc @nodejs/api

[ljharb]

I don't think version managers and installers should concern themselves with package.json - ie, with per-project anything. .nvmrc and similar per-directory configs are a gray area but I think having a separate file to configure the version, and being able to set it per-directory, is an OK thing to support.

As far as "underlying engine" - I assume you mean v8 vs chakra vs spidermonkey, etc. I think this is something we should try to think about, so we aren't designed into a corner - but not something we should try to tackle for awhile.

[marcelklehr]

not reading the local package.json from a version manager, primarily because package.json is a product of npm, not node itself

One could argue, however, (1) that at least since npm is distributed side by side with node, they're somewhat entangled. And, (2) since any serious node project already has a package.json it would not be totally unrealistic to read its engines field, rather than introduce a new file. I also don't think that implementation simplicity should be a priority over user experience, even more as reading JSON, is usually not too hard.

[coreybutler]

No doubt npm & node are somewhat entangled, but it's still not safe to assume npm is always present. For example, the original Alpine Docker images came in two flavors, one of which has npm and another without. The point is people do think about NOT using npm (to the tune of several million downloads of those images).

I actually know of alot of apps that don't use a package.json file, mostly for embedding in network appliances (routers, A/V equipment, etc). They leverage version managers to take advantage of things like security patches in node itself, but their scripts don't change. These are mostly proprietary and aren't as visible... won't be on Github anytime soon. This is a harder market to get any insights into. As I mentioned before, this is probably a pretty distinct minority, but still something to consider.

@ljharb - yeah, "underlying engine" was referring to Chakra/Spidermonkey/etc. The VM working group seems to be actively moving towards an agnostic API to make engine selection easier. I sensed some level of urgency from the VM group, but I haven't kept up to know if it's something we need to worry about now or if it was just enthusiasm from everyone being in the same room at the same time :-)

[Qard]

The API WG will be shipping the agnostic C API behind a build flag in Node 8.

I've seen various Ruby version managers use a .ruby-version file in the app directory, containing only the semver string, with a global default stored somewhere else. This way individual apps can define a target version to run on. Maybe we could standardize a similar .nodejs-version file?

[ljharb]

@Qard see #13

[Qard]

Ah, thanks. Missed that. Mostly just came here to mention the C API stuff. 😸

[felixfbecker]

ps-nvm does exactly this :)

[marcelklehr]

So, I'm closing this as a "no".

[jasonkarns]

Sharing for future reference: nodenv supports package.json#engines.node as a fallback (preferring $NODENV_VERSION env var and .node-version file, respectively) via a plugin. To maintain POSIX support, the JSON parsing is accomplished via https://github.com/dominictarr/JSON.sh and the semver logic applied via https://github.com/qzb/sh-semver. The plugin activates the highest installed node which conforms to the engines.node version spec.

Personally, I do not use the plugin. I have found that most projects which do specify engines.node do so to explicitly state a minimum version, and typically the minimum version is at least one or two LTS releases behind current. As such, nodenv's final fallback of respecting the nodenv-global version (specified via a file in $(nodenv root)) would activate the same or similar node, without the performance penalty of JSON.sh and sh-semver.