feat(@angular/cli): show Node.js version support status in version command

[clydin]

Unsupported versions of Node.js will now show an unsupported warning when the ng version command is executed.
Currently Node.js major versions 12 and 14 are considered supported and tested.

Closes #20879

[josephperrott]

LGTM

[alan-agius4]

Instead of adding an additional place where we need to update once we change support for Node

Can we instead of engines.node from package JSON and if the current Node doesn't fall within the specified semver, using the semver package we issue a warning?

[petebacondarwin]

If I understand him correctly, I think I agree with @alan-agius4 here. Instead of hiding this information in the version-impl.ts file, how about putting it in the package.json:

"engines": {
  "node.js": ">12...",
  "node.js:supported": "12.x||14.x",
  ...
}

Then it is available to developers and external tooling if they want to read or consume it, while not causing a hard-error if a different version is used.

[josephperrott]

@petebacondarwin @alan-agius4 I think I read Alan's proposal a bit differently which was to use the values in engines.node to determine the semver matching.

I actually tried to do this yesterday after I made the feature request initially before Charles ended up creating this. What I had was (roughly):

private isNodeSupportedForPackages(moduleNames: string[]): boolean {
  const nodeEnginesEntries = new Set<string>();
  let isUnsupportedVersion = false;
  for (const moduleName of moduleNames) {
    // Find the package in the workspace
    try {
      const packagePath = require.resolve(`${moduleName}/package.json`, {
        paths: [this.context.root],
      });
      if (packagePath) {
        const { engines } = require(packagePath) as { engines: { node: string } };
        nodeEnginesEntries.add(engines.node.replace(/(\>=?)/g, '^'));
      }
    } catch {}
  }
  nodeEnginesEntries.forEach((entry: string) => {
    isUnsupportedVersion =
      isUnsupportedVersion || !semver.satisfies(process.versions.node, entry);
  });
  return isUnsupportedVersion;
}

The concern/issue notably is the requirement of doing something like engines.node.replace(/(\>=?)/g, '^') to make our check slightly more restrictive than the actual engines node field.

[alan-agius4]

@josephperrott / @petebacondarwin, following a convo with @clydin on Slack, we decided that for the time being we roll with the current approach. And indeed I did mean to use the node property in the engines field and not create a custom key.

[clydin]

Custom engine fields can also cause install-time errors. We ran into that issue when pnpm was briefly added as an engine for the CLI.

[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.}