Angular-cli: Angular v11 - Node v15 Compatibility - Karma test runner

[prabh-62]

As per Angular docs, Angular supports current, active LTS, or maintenance LTS version of Node.js

And, according to testing docs, Karma is the default test runner.

Does this mean tools provided by default in Angular CLI follow same node compatibility? Specifically, Should the default test framework, Karma, support node v15 (current)?

Issues: https://github.com/karma-runner/karma/issues/3570, https://github.com/karma-runner/karma/issues/3571

[alan-agius4]

Thanks @prabh-62, for bringing this up. I've put this up for discussion with the rest of the team.

[dgp1130]

Node has a strange versioning scheme where the odd-numbered versions are more like "pre-releases" for the even-numbered LTS versions. So while Angular has historically supported current, odd-numbered Node versions, that isn't universal in the community as Karma shows. Node itself recommends:

Production applications should only use Active LTS or Maintenance LTS releases.

Rather than try to get all of Angular's dependencies to support current, odd-numbered Node versions, we feel it is simpler to change Angular's official policy about this to give less guarantees about such Node versions.

We actually have a check to stop users from running the CLI with unsupported Node versions, although it hasn't been updated in quite some time. Node v11 is not allowed, although Node v13 is, but probably should not be considering the Node team doesn't support it anymore.

package.json does support an engines field to more accurately define which versions of Node are supported and this should be used instead. Yarn will actually fail if its version doesn't satisfy this, although Node will ignore it by default. We should consider updating our own version check to validate this field at runtime. This would give proper error messages to users for Node

We still want to allow users to try the current, odd-numbered Node version and support that at least on a best-effort basis. Many bugs that arise from this are also relevant for the subsequent even-numbered version, so they are problems we would likely need to handle eventually anyways, and the sooner we know about such problems the sooner we can address them. Instead, we'll include the current odd-numbered Node version to the engines field (if applicable) and show a warning instead. This will allow users to try it out and report possible issues, but also let them know that it isn't fully supported.

Since Node engines doesn't actually change anything. However Node v13 is technically allowed even though it isn't actually supported. We should remove Node v13 from engines with Angular v12 to avoid introducing a breaking change in a non-major version (that doesn't mean Node v13 is supported with Angular v11, just that we don't give a hard error about it).

We should also update our docs to reflect this as well. With this change in policy, we will only officially support Node LTS versions. Of course, we also don't necessarily support a new version on day one, as we have a vetting and testing process to go through before a new version can be supported. Once that is done and we have CI set up, we can update the engines field to include the new version, meaning that engines is the real source of truth. Docs should just point to (or update itself from) this field to more clearly communicate the exact versions supported with the latest version of Angular.

We should also update the engines field for compiler-cli, which is in the main repo, but should have consistent versioning with tooling.

That's a lot of background and justification, so the core action items here are:

1. Update engines field to be more accurate in both CLI and compiler-cli. This would allow Node v10, v12, v14 (LTS releases), v15 (current, odd-numbered release), and v13 (legacy to avoid a breaking change).
2. Update our startup check to use this engines field so it does not fall out of date over time.
3. Add a warning when users run on an odd-numbered version that it isn't totally supported and they should prefer even-numbered LTS releases.
4. Remove Node v13 in Angular v12, as it shouldn't have survived this long anyways.
5. Update AIO to state that we only officially support Node LTS versions and link to or generate from the engines field to more clearly state the currently supported versions.

[simonua]

@dgp1130, thank you very much for making this clear. IMHO, that's a sensible and right approach to Node versioning. If it has not been considered yet, may I suggest, when showing the warning in the CLI in the future, adding a link to Node's Releases documentation that provides further details to your point 3 above, please? Thank you!