Node.js v16 will be entering an LTS state prior to the release of Angular v13 which allows Node.js v16 to be marked as officially supported by the Angular CLI. The initial bootstrapping check now adds Node.js v16 to the output message in the event of an unsupported Node.js version.
NOTE: Prior to the final v13 release, the Node.js v16 minor should be updated to the actual LTS version once available.
The original update analysis would prepend the package name to all migration collection files. This was required at the time to ensure the migration collection files would be found. The existing update logic, however, no longer requires this change but the change previously had no negative effects as both the relative and module specifier methods would successfully resolve the migrations. But with the conversion to ESM-based packages that use the package.json `exports` field, deep imports into a package are no longer possible unless the migration collection files are explicitly exported. Relative migration collection paths are now preferred since they are based off of the location of the package's `package.json` and do not require additional `exports` field entries. The original update analysis logic, unfortunately, prevent the relative paths from working as intended. Since this original logic is no longer required by the update process, it has been removed allowing the relative paths to be kept and used directly.
To support the eventual migration of the CLI to ESM, the CLI commandline tool is now bootstrapped by dynamically importing the main initialization code. This is done to allow the main bin file (`ng`) to remain CommonJS so that older versions of Node.js can be checked and validated prior to the execution of the CLI. This separate bootstrap file is needed to allow the use of a dynamic import expression without crashing older versions of Node.js that do not support dynamic import expressions and would otherwise throw a syntax error. This bootstrap file is required from the main bin file only after the Node.js version is determined to be in the supported range. The use of the dynamic import expression allows CommonJS code to execute either CommonJS or ESM code.
rules_nodejs 4 requires that a package_name property be specified within a ts_library rule for the output to be linked into the package repository. Failing to add the property can cause test failures due to unresolved packages.
Much like the framework packages, the VERSION property will eventually be set via build-time stamping but the necessary build infrastructure is not yet in place. Until then, the global require usage has been replaced with a file read and JSON parse which provides the equivalent required behavior.
To support the eventual conversion of the `@angular/cli` package to ESM, the usage of the global require function must be removed as it is not supported in ESM code. Node.js does have the facility to create custom require functions that can be used when the need to synchronously load a file at runtime is required. Such cases have now been converted to use custom require functions where appropriate.
The `no-useless-escape` eslint rule has now been enabled which removes unneeded characters and complexity from string literals and regular expressions. All files that were in violation of this rule have also been corrected.
All Angular builders are now located within one subdirectory of the `src` directory. This organization provides better discovery of the builders and will allow builder specific code to be stored in a single area.
The typings package was already present for `npm-package-arg` and the removal of require usage supports the eventual shift to an ESM output for the CLI package.
Some organizations are moving away from storing tokens/secrets in an NPM config file in favor
of environment variables that only exist for the span of a terminal session. This commit will
make sure those variables are read even when there is no NPM config file present.
The CLI contains a helper class instance that provides the version of the executing CLI. By using this helper throughtout the code, repeat `require` calls are no longer necessary.
The `esModuleInterop` option is recommended to be enable by TypeScript and corrects several assumptions TypeScript would otherwise make when importing CommonJS files.
This option change helps ensure compatibility as packages move towards ESM.
Reference: https://www.typescriptlang.org/tsconfig#esModuleInterop
This change removes the usage of the shell execution when spawning the latest CLI version when bootstrapping the update command. The absolute path of the node process is now spawned which removes the need for any shell path resolution. This also removes the need to quote and/or escape command arguments which can be error-prone. Node.js and the OS will now handle any quoting and escaping automatically and without any custom logic.
