angular/aio/angular.json

266 lines
8.2 KiB
JSON
Raw Normal View History

{
"$schema": "./node_modules/@angular/cli/lib/config/schema.json",
"version": 1,
"cli": {
"packageManager": "yarn",
"warnings": {
"typescriptMismatch": false
},
"analytics": false,
"cache": {
// Disable build caching as the cache folder will just be dropped
// when run under Bazel sandboxed execution.
"enabled": false
}
},
"newProjectRoot": "projects",
"projects": {
"site": {
"projectType": "application",
"schematics": {
"@schematics/angular:application": {
"strict": true
},
"@schematics/angular:component": {
"inlineStyle": true,
"style": "scss"
}
},
"root": "",
"sourceRoot": "src",
"prefix": "aio",
"architect": {
"build": {
"builder": "@angular-devkit/build-angular:browser",
"options": {
"outputPath": "dist",
"index": "src/index.html",
"main": "src/main.ts",
"polyfills": "src/polyfills.ts",
"ngswConfigPath": "src/generated/ngsw-config.json",
"tsConfig": "tsconfig.app.json",
"webWorkerTsConfig": "tsconfig.worker.json",
"optimization": {
"fonts": {
"inline": false
},
"scripts": true,
"styles": {
"inlineCritical": false,
"minify": true
}
},
"outputHashing": "all",
"sourceMap": true,
"namedChunks": true,
"assets": [
// Architect on Windows has difficulty service assets files within a
// Bazel runfiles symlink forest. Using "followSymlinks" seems to
// fix this. Note that the assets below don't need this workaround as
// symlinked tree artifacts pointing to the output tree don't appear
// to have the same issue.
{
"followSymlinks": true,
"input": "src/assets",
"glob": "**/*",
"output": "/assets/"
},
{
"followSymlinks": true,
"input": "src/",
"glob": "**/pwa-manifest.json",
"output": "/"
},
{
"followSymlinks": true,
"input": "src/",
"glob": "**/google385281288605d160.html",
"output": "/"
},
{
"input": "stackblitz/generated",
"output": "generated",
"glob": "**"
},
{
"input": "example-zips/generated",
"output": "generated",
"glob": "**"
},
{
"input": "dgeni/generated",
"output": "generated",
"glob": "**"
},
{
"input": "dgeni-fast/generated",
"output": "generated",
"glob": "**"
}
],
"styles": [
"src/styles/main.scss",
{
"inject": false,
"input": "src/styles/custom-themes/dark-theme.scss",
"bundleName": "dark-theme"
},
{
"inject": false,
"input": "src/styles/custom-themes/light-theme.scss",
"bundleName": "light-theme"
}
],
"scripts": [],
"budgets": [
{
"type": "initial",
"maximumWarning": "850kb",
"maximumError": "1mb"
},
{
"type": "anyComponentStyle",
"maximumWarning": "2kb",
"maximumError": "4kb"
}
]
},
"configurations": {
"next": {
"fileReplacements": [
{
"replace": "src/environments/environment.ts",
"with": "src/environments/environment.next.ts"
}
],
"serviceWorker": true
},
"rc": {
"fileReplacements": [
{
"replace": "src/environments/environment.ts",
"with": "src/environments/environment.rc.ts"
}
],
"serviceWorker": true
},
"stable": {
"fileReplacements": [
{
"replace": "src/environments/environment.ts",
"with": "src/environments/environment.stable.ts"
}
],
"serviceWorker": true
},
"archive": {
"fileReplacements": [
{
"replace": "src/environments/environment.ts",
"with": "src/environments/environment.archive.ts"
}
],
"serviceWorker": true
},
"ci": {
"progress": false
},
"development": {
"buildOptimizer": false,
"optimization": false,
"outputHashing": "none",
"vendorChunk": true,
"extractLicenses": false
}
},
"defaultConfiguration": "stable"
},
"serve": {
"builder": "@angular-devkit/build-angular:dev-server",
"options": {
"headers": {
feat(docs-infra): set up Google Analytics 4 along with keeping legacy Universal Analytics (#46716) We currently use Universal Analytics. This is deprecated in favor of Google Analytics 4 and UA will stop processing hits in October 2023. This change intends to prepare us for this migration, and to already pre-populate our GA4 property (there is no way to migrate existing data /properties into a GA4 property -- a new one needs to be created). This will help us minimize the data gap so that we can: * Continue to look at the UA property with the full time span until October 2023 * Can start using the GA4 property long-term in the future, starting with data even before Universal Analytics stops processing new data. We need to keep the existing `analytics.js` setup. Initially we have considered using `gtag.js` for both the UA and GA4 properties, as it supports that, but that doesn't work with our strict trusted types enforcement because it results in multiple `gtag.js` scripts (specific versions for UA or GA4) that recreate the same trusted type policies. This causes runtime errors and breaks the setup. Instead, with continued use of `analytics.js` we have the benefit of a good separation of trusted types + events and configuration. There is some problematic with translation of Universal Analytics Events to GA4, or the other way around (even though we don't use custom events currenlty) We also do not need to send page views for our GA4 property because GA4 with gtag supports this automatically (respecting the history state -- using the `Enhanced measurement events` setting in the UI). For our UA legacy instance we continue to dispatch events manually. This logic can be removed in the future. More details can be found here: https://docs.google.com/document/d/1aK8u4ZlXbqQ2wMqmgSX7Ces8iLgamC13oCoG6VeBruA/edit?usp=sharing&resourcekey=0-EVe-Rhnme3bj_pkz2RcOmw. PR Close #46716
2022-07-05 17:57:00 +00:00
// Keep in sync with the `firebase.json` file.
// Note: Unlike in `firebase.json` we omit the `report-uri` for development.
"Content-Security-Policy": "require-trusted-types-for 'script'; trusted-types angular angular#bundler angular#unsafe-bypass aio#analytics google#safe goog#html"
}
},
"configurations": {
"next": {
"browserTarget": "site:build:next"
},
"rc": {
"browserTarget": "site:build:rc"
},
"stable": {
"browserTarget": "site:build:stable"
},
"archive": {
"browserTarget": "site:build:archive"
},
"ci": {
"browserTarget": "site:build:ci"
},
"development": {
"browserTarget": "site:build:development"
}
},
"defaultConfiguration": "development"
},
"extract-i18n": {
"builder": "@angular-devkit/build-angular:extract-i18n",
"options": {
"browserTarget": "site:build"
}
},
"test": {
"builder": "@angular-devkit/build-angular:karma",
"options": {
"main": "src/test.ts",
"polyfills": "src/polyfills.ts",
"tsConfig": "tsconfig.spec.json",
"webWorkerTsConfig": "tsconfig.worker.json",
"karmaConfig": "karma.conf.js",
feat(docs-infra): set up Google Analytics 4 along with keeping legacy Universal Analytics (#46716) We currently use Universal Analytics. This is deprecated in favor of Google Analytics 4 and UA will stop processing hits in October 2023. This change intends to prepare us for this migration, and to already pre-populate our GA4 property (there is no way to migrate existing data /properties into a GA4 property -- a new one needs to be created). This will help us minimize the data gap so that we can: * Continue to look at the UA property with the full time span until October 2023 * Can start using the GA4 property long-term in the future, starting with data even before Universal Analytics stops processing new data. We need to keep the existing `analytics.js` setup. Initially we have considered using `gtag.js` for both the UA and GA4 properties, as it supports that, but that doesn't work with our strict trusted types enforcement because it results in multiple `gtag.js` scripts (specific versions for UA or GA4) that recreate the same trusted type policies. This causes runtime errors and breaks the setup. Instead, with continued use of `analytics.js` we have the benefit of a good separation of trusted types + events and configuration. There is some problematic with translation of Universal Analytics Events to GA4, or the other way around (even though we don't use custom events currenlty) We also do not need to send page views for our GA4 property because GA4 with gtag supports this automatically (respecting the history state -- using the `Enhanced measurement events` setting in the UI). For our UA legacy instance we continue to dispatch events manually. This logic can be removed in the future. More details can be found here: https://docs.google.com/document/d/1aK8u4ZlXbqQ2wMqmgSX7Ces8iLgamC13oCoG6VeBruA/edit?usp=sharing&resourcekey=0-EVe-Rhnme3bj_pkz2RcOmw. PR Close #46716
2022-07-05 17:57:00 +00:00
"assets": ["src/assets", "src/pwa-manifest.json", "src/google385281288605d160.html"],
"styles": [
"src/styles/main.scss",
{
"inject": false,
"input": "src/styles/custom-themes/dark-theme.scss",
"bundleName": "dark-theme"
},
{
"inject": false,
"input": "src/styles/custom-themes/light-theme.scss",
"bundleName": "light-theme"
}
],
"scripts": []
}
},
"lint": {
refactor(docs-infra): migrate aio from tslint to eslint (#42820) migrate aio to eslint as tslint has been deprecated, the migration is restricted to the aio app and its e2e tests and does not include the other tools, for such reason both tslint and codelyzer have not been removed (to be done in a next PR) some minor tweaks needed to be applied to the code so that it would adhere to the new ESLinting behaviour most TSLint rules have been substituted with their ESLint equivalent, with some exceptions: * [whitespace] does not have an ESLint equivalent (suggested to be handled by prettier) * [import-spacing] does not have an ESLint equivalent (suggested to be handled by prettier) * [ban] replaced with [no-restricted-syntax] as there is no (official/included) ESLint equivalent some rules have minor different behaviours compared to their TSLint counterparts: * @typescript-eslint/naming-convention: - typescript-eslint does not enforce uppercase for const only. * @typescript-eslint/no-unused-expressions: - The TSLint optional config "allow-new" is the default ESLint behavior and will no longer be ignored. * arrow-body-style: - ESLint will throw an error if the function body is multiline yet has a one-line return on it. * eqeqeq: - Option "smart" allows for comparing two literal values, evaluating the value of typeof and null comparisons. * no-console: - Custom console methods, if they exist, will no longer be allowed. * no-invalid-this: - Functions in methods will no longer be ignored. * no-underscore-dangle: - Leading and trailing underscores (_) on identifiers will now be ignored. * prefer-arrow/prefer-arrow-functions: - ESLint does not support allowing standalone function declarations. - ESLint does not support allowing named functions defined with the function keyword. * space-before-function-paren: - Option "constructor" is not supported by ESLint. - Option "method" is not supported by ESLint. additional notes: * the current typescript version used by the aio app is 4.3.5, which is not supported by typescript-eslint (the supported versions are >=3.3.1 and <4.3.0). this causes a warning message to appear during linting, this issue should likely/hopefully disappear in the future as typescript-eslint catches up * The new "no-console" rule is not completely equivalent to what we had prior the migration, this is because TSLint's "no-console" rule let you specify the methods you did not want to allow, whilst ESLint's "no-console" lets you specify the methods that you do want to allow, so and in order not to have a very long list of methods in the ESLint rule it's been decided for the time being to simply only allow the "log", "warn" and "error" methods * 4 dependencies have been added as they have been considered necessary (see: https://github.com/angular/angular/pull/42820#discussion_r669978232) extra: * the migration has been performed by following: https://github.com/angular-eslint/angular-eslint#migrating-an-angular-cli-project-from-codelyzer-and-tslin * more on typescript-eslint at: https://github.com/typescript-eslint/typescript-eslint PR Close #42820
2021-07-15 20:59:57 +00:00
"builder": "@angular-eslint/builder:lint",
"options": {
refactor(docs-infra): migrate aio from tslint to eslint (#42820) migrate aio to eslint as tslint has been deprecated, the migration is restricted to the aio app and its e2e tests and does not include the other tools, for such reason both tslint and codelyzer have not been removed (to be done in a next PR) some minor tweaks needed to be applied to the code so that it would adhere to the new ESLinting behaviour most TSLint rules have been substituted with their ESLint equivalent, with some exceptions: * [whitespace] does not have an ESLint equivalent (suggested to be handled by prettier) * [import-spacing] does not have an ESLint equivalent (suggested to be handled by prettier) * [ban] replaced with [no-restricted-syntax] as there is no (official/included) ESLint equivalent some rules have minor different behaviours compared to their TSLint counterparts: * @typescript-eslint/naming-convention: - typescript-eslint does not enforce uppercase for const only. * @typescript-eslint/no-unused-expressions: - The TSLint optional config "allow-new" is the default ESLint behavior and will no longer be ignored. * arrow-body-style: - ESLint will throw an error if the function body is multiline yet has a one-line return on it. * eqeqeq: - Option "smart" allows for comparing two literal values, evaluating the value of typeof and null comparisons. * no-console: - Custom console methods, if they exist, will no longer be allowed. * no-invalid-this: - Functions in methods will no longer be ignored. * no-underscore-dangle: - Leading and trailing underscores (_) on identifiers will now be ignored. * prefer-arrow/prefer-arrow-functions: - ESLint does not support allowing standalone function declarations. - ESLint does not support allowing named functions defined with the function keyword. * space-before-function-paren: - Option "constructor" is not supported by ESLint. - Option "method" is not supported by ESLint. additional notes: * the current typescript version used by the aio app is 4.3.5, which is not supported by typescript-eslint (the supported versions are >=3.3.1 and <4.3.0). this causes a warning message to appear during linting, this issue should likely/hopefully disappear in the future as typescript-eslint catches up * The new "no-console" rule is not completely equivalent to what we had prior the migration, this is because TSLint's "no-console" rule let you specify the methods you did not want to allow, whilst ESLint's "no-console" lets you specify the methods that you do want to allow, so and in order not to have a very long list of methods in the ESLint rule it's been decided for the time being to simply only allow the "log", "warn" and "error" methods * 4 dependencies have been added as they have been considered necessary (see: https://github.com/angular/angular/pull/42820#discussion_r669978232) extra: * the migration has been performed by following: https://github.com/angular-eslint/angular-eslint#migrating-an-angular-cli-project-from-codelyzer-and-tslin * more on typescript-eslint at: https://github.com/typescript-eslint/typescript-eslint PR Close #42820
2021-07-15 20:59:57 +00:00
"lintFilePatterns": [
"src/!(generated)/**/*.ts",
"src/!(generated)/**/*.html",
"tests/**/*.ts"
]
}
},
"e2e": {
"builder": "@angular-devkit/build-angular:protractor",
"options": {
"protractorConfig": "tests/e2e/protractor.conf.js",
"devServerTarget": "site:serve"
},
"configurations": {
"ci": {
"devServerTarget": "site:serve:ci"
}
}
}
}
}
}
}