Unable to use v12 with node v15+ ("engines.node" field misuse)

[vladimiry]

Description

The engine "node" is incompatible with this module. Expected version "^12.14.1 || ^14.0.0". Got "15.14.0"

Minimal Reproduction

See the issue title.

Your Environment

node v15.14.0 (npm v7.7.6).

Angular Version:

v12 stack.

[vladimiry]

I see now that it's by design, #41822.

And https://nodejs.org/en/about/releases/ says the same:

Production applications should only use Active LTS or Maintenance LTS releases

The bad thing is that I need to use nodejs bundle that comes with npm v7 which is v15+.

[vladimiry]

Reopening since the below statement listed at https://nodejs.org/en/about/releases/ only related to use nodejs in production when in the case of Angular nodejs is used in development time/mode only (for compiling to a regular/static web resources).

Production applications should only use Active LTS or Maintenance LTS releases

[Timebutt]

I was also really confused to get this error message when upgrading my project to Angular 12. As you mention @vladimiry, Angular applications aren't actually served using Node.js, unless you'd explicitly run a ng serve --prod which then explicitly mentions you shouldn't be using that for production. Node.js is a development time thing only.

@josephperrott: are we missing something in the above reasoning? Sorry for mentioning you explicitly, but it looks like you introduced the change 17 days ago?

I feel this change unnecessarily restricts the supported Node.js versions and causes confusion for people upgrading with Node 15 or even 16 installed for no real reason?

[frct1]

Totally agree, looks strange to limit node version.
For example, m1 users are able to use only 15-16 version.
Looking forward to hear info from contributors 😳

[MickL]

All pipelines are failing using Docker's node:alpine image which uses 16.1.0.

Why cant I use Node 15.x or 16.x anymore? What is the reason? It was working with Angular 11 but not with 12?

[josephperrott]

The reason we restrict the version of node that we are able to support is because, while at runtime of applications angular is not relying on node directly, it uses node in the language service and compiler (as well as the linker). Because these pieces rely on node, we need to be certain of the APIs that are available in the node environment in which these are running. In many ways this is our "prod" environment. Following the guidance from node, we only support the Active LTS and Maintenance LTS versions.

While not officially supported, other future versions of node that in the Current lifecycle stage for node likely will work as expected.

---

@Timebutt as you noted, I introduced the change a few weeks ago, however this change was done to more codify the support our team maintains for the versions of node.

@MickL Previously, previously we were incorrectly vague in our versioning requirements. Our updated engines requirements are more specific which caused it to show as unable to be used.

[MickL]

Wouldnt it be better to have a recommendation instead of forbidding to use newer versions? How it is right now it will fail hard: Local development is no more possible without use of nvm and pipelines are failing.

[josephperrott]

@MickL Both yarn and npm have support for ignoring engine requirements, so you should be able to rely on those if you would like to use these unsupported versions in your development.

Yarn

yarn config set ignore-engines true - Set the config for all yarn usage
yarn install --ignore-engines - Ignore the engines for the specific yarn install run

NPM

From my understanding, npm only warns for engines unless engine-strict in your config is set true in your .npmrc. If however it still is erroring instead of warning, you can overide the engine requirement with --force.

[vladimiry]

In many ways this is our "prod" environment.

I now feel guilty for giving a hint by referring to node's note at https://nodejs.org/en/about/releases/ 😄

it uses node in the language service and compiler (as well as the linker)

Those are development things by definition. These things, of course, can be named "production" at @angular but it doesn't turn them into production things for the rest of the projects that consume @angular as one among other dependencies.

I understand that introducing so strict node version restriction of course might make the processes at @angular easier but it will likely cause other teams/engineers to waste for no real reason thousands of man-hours in summary to adopt the restriction. So one could say that you are simplifying your processes at the expense of others.

@MickL Both yarn and npm have support for ignoring engine requirements, so you should be able to rely on those if you would like to use these unsupported versions in your development.

Such change would affect the entire project, not just @angular dependency, which would be a very very bad thing to apply to any project (do I need to explain why? - short answer is because other dependencies normally use "engines.node" restriction by purpose).

[maxwellium]

@vladimiry has a point here regarding the ignore-engines flag. turning it off globally is a red flag. in our pipelines we've had to downgrade node to get along with the new version which has a lot higher emotional cost than technical cost ;)
most npm projects tend to restrict engines downward and for known issues only. for the peace of my heart and those of our team I would kindly propose to do the same and only bar engine versions that are positively known to break

[PReimers]

... which gives library authors time to add support for them.
... Production applications should only use Active LTS or Maintenance LTS releases.

In many ways this is our "prod" environment.

I thought Angular was a Framework/Library not an Application 🤔

[clydin]

Node.js is a critical part of the toolset used to develop applications. Just as using a prerelease version of the Angular CLI to build an application that will be deployed to production may result in failed builds or a malfunctioning application, using a non-production ready version of Node.js may also result in a similar outcome. This can also apply to other development tools such as IDEs or even the operating system. Using non-production ready software to develop an application introduces risk that the application cannot be built or will be built incorrectly (potentially in a way that may not be obvious until after deployment).

However, this is distinct from the question of whether it should be a hard error at install time.

@vladimiry The Angular prerequisite page that documents the requirement of an Active or Maintenance LTS version ( https://angular.io/guide/setup-local#prerequisites) has a link to https://nodejs.org/about/releases/

[MickL]

Latest node versions are production ready, they just dont have long time support.

[clydin]

The Node.js documentation appears to differ from that statement:

Production applications should only use Active LTS or Maintenance LTS releases

[vladimiry]

@clydin it doesn't matter what node.js doc says about production applications since @angular is not an application but dependency/library/framework. Besides it needs nodejs at dev-time only.

[clydin]

The Angular CLI and the set of framework packages (compiler, compiler-cli, localize, etc.) it directly uses are an application, though, which depends heavily on the behavior and API of Node.js. The stability of a deployed application is linked to the stability of the tools used to create it. However, as mentioned, this is distinct from the question of whether all of the packages should contain hard install errors.

[vladimiry]

@clydin continuing the idea of your message, in order to improve "the stability" the npm/node.js should remove support for "engines.node" field and hardcode/allow LTS node.js versions only in all modes including the development mode, which is fortunately not the case. Again, I understand that introducing such restrictions apparently simplifies the processes in @angular team but I don't think that module/dependency consumers should suffer for no real but imposed reason (saying "imposed" I refer to misuse of "engines.node" field). If some dev teams, including @angular, prefer to use LTS node.js only versions for development then they just do that not forcing the others by misusing "engines.node" field.

[MickL]

The migration guide states it doesnt work with v10 or less but it doesnt state it does not work with v15 or higher:

[ocombe]

Node 16 is going to be the active version in october, and everything just works fine with it (if you ignore the warning), I don't really see a reason to not allow it...

[vladimiry]

just works

Correct. This is why I updated the issue title with "engines.node" field misuse. The "engines.node" doesn't seem to be used by @angular for its intended purpose but apparently for enforcing the work environment policy in the team.

[josephperrott]

Update: We have decided to update the field to be less restrictive (see #42205).

We will work to surface the Node supported version information in the ng version output to express when an unsupported version of node is being used.

[vladimiry]

Closed in 1c3fe69...9f09c3b

[vladimiry]

@alan-agius4 / @josephperrott can I expect that https://github.com/angular/angular-cli/releases/tag/v12.0.2 will fix the issue for @angular-devkit/build-optimizer and @ngtools/webpack modules? Noticed that angular/angular-cli#20796 was closed as duplicate of this issue. Right now the https://github.com/angular/angular-cli/blob/6e2c292365d1015f703bd06dd290c3d73df4bd61/package.json#L43 and https://github.com/angular/angular-cli/blob/fb21c4a968c8b4d8a3d17237d0864b795fffba49/lib/packages.ts#L88 lines don't look very promising.

[vladimiry]

Reopening since angular-cli related stuff doesn't seem to be fixed.

[JoostK]

Reopening since angular-cli related stuff doesn't seem to be fixed.

I have reopened the CLI issue and will be closing this one as there's no more actions for the FW packages.

[vladimiry]

@JoostK thanks for tracking the issue progress. My goal was to highlight possible omission, so we get well prepared release.

[JoostK]

@vladimiry the CLI release is already in the making so any change will come too late.

[vladimiry]

@JoostK thanks for the note. Actually at least in my case, I was able to use @angular v12 stack plus v11 stack of @angular-devkit/build-optimizer and @ngtools/webpack and things worked out (such setup is clearly not recommenced for production). Not using the ng CLI thing though.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}