This is a workaround for the schematics runtime to support the requirement of packages containing migrations (or other schematics) to not have a direct/runtime dependency on the schematics package.
Closes: #16392
This is a workaround for the schematics runtime to support the requirement of packages containing migrations (or other schematics) to not have a direct/runtime dependency on the schematics package.
Closes: #16392
Certain node packages depend on native bindings which cannot be bundled, with this fix we add a way to exclude these from being processed by the bundler.
Closes: #16348
All locale i18n options now support an object form which allows a base HREF to be defined for the locale. Each locale can now optionally define a custom base HREF that will be combined with the base HREF defined for the build configuration. By default if the shorthand form for the locale is used or the field is not present in the longhand form, the locale code will be used as the base HREF. To disable automatic augmentation a base HREF value of an empty string (`""`) can be used. This will prevent anything from being added to the existing base HREF.
For common scenarios, the shorthand form will result in the preferred and recommended outcome of each built locale variant of the application containing a defined base HREF containing the locale code.
This change ensures that both the global version and the project version Node.js version requirements are met before the CLI executes a command. Previously an older global version of the CLI would allow a newer project version to execute even if the project version had more strict Node.js version requirements. The Node.js version is now checked twice. Once in an ES5 safe script to ensure that ancient Node.js versions are not in use. And secondly in the CLI entry code that is executed after global/project bootstrapping.
We don't actually know for certain that the migration was successful, only that it finished. This updates the messaging to be more clear about this distinction. I also removed the check mark and green coloring which implied success.
Explained here: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
Current change affects reading of global config from `.angular-config.json`. By default it will be created in user's home directory. If user moves it manually to `$HOME/.config/angular/.angular-config.json`, it will be subsequently read from new location.
Previously we passed `--no-bin-links` because we used to install packages globally in some cases. But now this is no longer needed as we should now have permissions to generate "local" bin links even during a temp installations as these will no longer generate bin links in the global context.
Fixes#16133
Fixes#16060.
Any time a `git commit` is made, the CLI now prints out the hash and short message. For migrations, the message is simply the first line of the commit. For schematics, the commit message isn't all that helpful, so I used the list of packages instead.
With this change we improve the log messages of migration;
> the migration description
> the outcome of the migration
> we also remove the version of the migration which was misleading (Ex: 9.0.0-beta)
In the case users don't have analytics globally configured when the CLI will self update during ng update. It will prompt to configure this.
However, afterwards the update will fail with `Repository is not clean. Please commit or stash any changes before updating.` as there would be uncommited local changed.
