The new routing APIs don't support `browser` builder, but calling `ng add @angular/ssr` with a `browser` builder would still prompt the user to add them. If the user said "Yes", it would actually ignore that answer and not enable the new APIs.
With this change, `ng add @angular/ssr` when using `browser` builder does not show the prompt and assumes the answer is "No". It also throws an error if the user runs `ng add @angular/ssr --server-routing`.
I'm not aware of a built-in prompting mechanism in schematics beyond `x-prompt`, which can't be used here, so instead I just called Inquirer directly. Unfortunately testing the prompt is a little awkward, as Inquirier does not provide useful APIs in this space. I evaluated `@inquirer/testing`, but ultimately decided that was more intended for testing custom Inquirer prompts, not mocking usage of standard prompts. Schematics APIs do not provide a useful way to inject additional data like a mock, so instead I had to do this through a `setPrompterForTestOnly` function. I'm not a huge fan of it, but I don't see a more straightforward way of solving the problem.
This commit revises the app-shell and ssr schematics to incorporate the new Server Rendering API, along with the integration of server-side routes.
BREAKING CHANGE: The app-shell schematic is no longer compatible with Webpack-based builders.
Updates for all angular.io links to the new angular.dev domain. Additionally, adjustment to new resources where the equivalent does not exist on the new site (e.g. Tour of Heroes tutorial)
The `assets` directory is confusing for the users and commonly users place "assets" which are not meant to be copied but instead processed by the build system. This causes some files both bundled and copied.
With this change we rename the `assets` directory to `public` and also move the `favicon.ico` inside this newly created directory.
This commit enabled users to opt-in adding SSR and SSG to their application during the `ng new` experience. This can be done either by using the `--ssr` option or answer `Yes` when prompted.
This commit updates the `ng generate application` to use the esbuild `application` builder. This also updates the schematics to support both `browser` and `application` builders.
BREAKING CHANGE: `rootModuleClassName`, `rootModuleFileName` and `main` options have been removed from the public `pwa` and `app-shell` schematics.
This commits updates the `routing` option in the `ng new` and `ng generation application` schematics to `true` by default and also removed the `Would you like to add Angular routing?` prompt.
BREAKING CHANGE: Routing is enabled by default for new applications when using `ng generate application` and `ng new`. The `--no-routing` command line option can be used to disable this behaviour.
These async methods are a replacement for the Observable based `runSchematicAsync` and `runExternalSchematicAsync` methods.
DEPRECATED:
The Observable based `SchematicTestRunner.runSchematicAsync` and `SchematicTestRunner.runExternalSchematicAsync` method have been deprecated in favor of the Promise based `SchematicTestRunner.runSchematic` and `SchematicTestRunner.runExternalSchematic`.
`@angular-devkit/build-angular` now has a built in Karma config. Users can still create their own Karma configuration if they want to override the default configuration.
This commit removes the usage of environment files and `fileReplacements` in new application projects. Previously, the environment files was used to distinguish between a prod build to invoke `enableProdMode`. The `enableProdMode` however needed only for the case of JIT mode in production mode, which is a rare case as JIT mode is recommanded to be used in production.
In the CLI, calling `enableProdMode` is not needed as `ngDevMode` it's set using the minifier.
The test.ts is now included in `@angular-devkit/build-angular` and unless this needs to be customized is no longer needed to be provided.
Default config:
```js
// This file is required by karma.conf.js and loads recursively all the .spec and framework files
import { getTestBed } from '@angular/core/testing';
import {
BrowserDynamicTestingModule,
platformBrowserDynamicTesting
} from '@angular/platform-browser-dynamic/testing';
// First, initialize the Angular testing environment.
getTestBed().initTestEnvironment(BrowserDynamicTestingModule, platformBrowserDynamicTesting(), {
errorOnUnknownElements: true,
errorOnUnknownProperties: true
});
```
With this change we drop the `polyfills.ts` from new application projects and add the polyfills directly in the `angular.json`. This is possible as now the `polyfills` option accept an array of module specifiers.
This change also fixes another open issue (#14432) which was caused by the missing polyfills file in the library test setup.
Closes#14432
The Browserslist configuration file is redundant as we set the defaults directly in @angular-devkit/build-angular. 8da926966e/packages/angular_devkit/build_angular/src/utils/supported-browsers.ts (L12-L19)
With this commit, we remove the `.browserlistrc` configuration file from the schematics application template and through a migration in existing projects when the Browserslist query result matches the default.
Users needing a finer grain support should still create a `.browserlistrc` in the root directory of the project.
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
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.
With this change we removed several deprecated `@schematics/angular` deprecated options.
BREAKING CHANGE:
We removed several deprecated `@schematics/angular` deprecated options.
- `lintFix` have been removed from all schematics. `ng lint --fix` should be used instead.
- `legacyBrowsers` have been removed from the `application` schematics since IE 11 is no longer supported.
- `configuration` has been removed from the `web-worker` as it was unused.
- `target` has been removed from the `service-worker` as it was unused.
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.
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.
BREAKING CHANGE:
`styl` (Stylus) is no longer a supported value as `style` in `application`, `component`, `ng-new` schematics. Stylus is not actively maintained and only 0.3% of the Angular CLI users use it.
The `style` option for the application schematic specifies the language/preprocessor to use for the application's external style files and should also setup the default for inline styles as well via the `inlineStyleLanguage` build option. The value can be adjusted after application generation if needed.
This change allows `inlineTemplate=false` and/or `inlineStyle=false` to be used with the `minimal` option when creating an application either by `ng new` or `ng generate application`.
Closes#17528
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.
BREAKING CHANGE:
Deprecated support for IE 9-10 has been removed in Angular 11.
Only IE 9-10 support has been removed. IE 11 is officially supported in Angular 11.
Additional information can be found here: https://v10.angular.io/guide/deprecations#ie-9-10-and-mobile
The schematics recently siwtcher to `jsonc-parser` as the JSOn parser, and that introduced a small regression in the tslint.json file where the rules order is not the same as previously.
See https://github.com/cexbrayat/angular-cli-diff/compare/10.0.2...10.1.0-next.0
This commit should fix the issue by providing the insertion index when merging the tslint files.
A test has also been added to avoid further regressions.
Since the tsconfig for e2e’s is named tsconfig.json there is no reason why it should be included in the solutions typescript configuration file.
Closes#18190
With this change we enable stricter type checking and optimization effective coding rules when using the `--strict` option.
Changes in schematics
- `ng-new`: A prompt for the `--strict` option was added. This option is a proxy and will be passed to the application and workspace schematics.
- `application`: A `package.json` was added in the `app` folder, to tell the bundlers whether the application is free from side-effect code. When `strict` is `true`. the `sideEffects` will be set `false`.
- `workspace` When `strict` is true, we add stricter TypeScript and Angular type-checking options.
Note: AIO is already using these strict TypeScript compiler settings. PR to enable `strictTemplates` https://github.com/angular/angular/pull/36391
Reference: TOOL-1366
By default, we now generate new applications which support only evergreen browsers, as a result differential loading is now opt-in.
A new flag `--legacy-browsers`, was added to generate applications which support non evergreen browsers such as Internet Explorer 11.
**Note**: After an application is generated opting in and out of differential loading is still possible through the supported browsers configuration in the browserslist configuration file defaulted to `.browserslistrc`.
