By using the `strings` re-export from `@angular-devkit/schematics` instead of from `@angular-devkit/core`,
the number of imports from `@angular-devkit/core` has been reduced and lowers the direct dependency count
for many of the individual schematics.
With this change we update the TypeScript compilation target to `ES2020` for both new and existing projects. This is because all browsers that Angular supports (https://angular.io/guide/browser-support) support `ES2020` features without the need for polyfills.
With this change we update the validation of the libraries and application projects names to fully allow characters that make a valid NPM package name. http://json.schemastore.org/package has been used as reference.
We also remove validators that are no longer needed.
Closes#11051
With this change we sync workspace and library schematic dependencies using Renovate. We do this to avoid having to keep these in sync by hand.
We could have used TypeScripts' `resolveJsonModule` to make the `latestVersion` object typesafe. But `ts_library` doesn't support JSON inputs.
This is not the first time, that this package caused a breaking change in a minor version, were it drops support for older `jasmine-core` versions.
Related to #21326
All TypeScript files have been updated to pass the new eslint-based linting checks. eslint compatible disabling comments have also been added in place of the previous tslint comments.
With this change we update the TypeScript target of server compilation unit for new projects.
- E2E target has been update from `es2018` to `es2019`
- Browser target has been update from `es2015` to `es2017`
- Server target has been update from `es2016` to `es2019`
With this change we do several changes to the `angular.json` configuration for `build` , `server` and `app-shell` targets so that these are `production` by default.
- build, server and app-shell targets are configured to run production by default.
- We add a new configuration named `development` to run the mentioned builder targets in development. Ex: `ng build --configuration development`.
- When adding `universal` or `app-shell`, we generate the full set of configurations as per the `buiid` target. Previously, we only generated the `production` configuration.
- We added a helper script in `package.json` to run build in watch mode. `npm run watch` which is a shortcut for `ng build --watch --configuration development`
When new application is generated with --minimal flag it will be
created without any testing frameworks, linters, etc. But package.json
still contains broken scripts and dependencies.
So "test": "ng test", "lint": "ng lint" and "tslint": "~6.1.0",
"ts-node": "~8.3.0" should be removed. By analogy with "e2e": "ng e2e".
It's confusing and redundant to use `When true` and `when false` in descriptions for a CLI arguments because specifying false/true is redundant in a command line argument flag and in most cases users will not do it.
Example:
`--foo=true` is the same as `--foo`
`--foo=false` is the same as `--no-foo`
The ViewEngine message extraction generates a variety of legacy formats
for extracted message ids. These formats have a number of issues related
to whitespace handling and reliance upon information inside the original
HTML of a template. The new message format is more resilient to things
like whitespace changes, and can be generated directly from calls to
`$localize`, which allows messages in application code to have the same
id as identical messages in templates.
As a first step in migrating projects away from the legacy id format
for i18n messages, this commit updates newly generated projects to turn
off the legacy ids.
In the future the default will be flipped and this can be removed.
Eventually the legacy message id support will be removed altogether,
probably in sync with removal of ViewEngine.
This change adjusts the E2E schematic to generate a protractor configuration with the selenium promise manager disabled. It also adjusts the generated test files to use native promises and async/await to control test execution.
Following feedback from the community, which showed a high number of users found it hard to work with the `no-any` lint rule and also the `sideEffects` package.json file. With DevRel we decided to remove both features when generating a strict workspace and/or application.
