honeymoose
/
angular-cn
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
angular-cn/integration/ivy-i18n/package.json

76 lines
5.0 KiB
JSON
Raw Normal View History

test(ivy): add cli-hello-world-ivy-i18n integration test (#31609) This test uses localization in the `AppComponent` component: * an `i18n` attribute in the template * a call to the `$localize` tag in the component constructor PR Close #31609
2019-08-12 15:52:58 -04:00
{
"name": "cli-hello-world-ivy-compat",
"version": "0.0.0",
"license": "MIT",
"scripts": {
test: update Angular CLI deps for integration tests (#32957) PR Close #32957
2019-10-02 07:28:23 -04:00
"build": "ng build --prod",
build: add npm_integration_test && angular_integration_test (#33927) * it's tricky to get out of the runfiles tree with `bazel test` as `BUILD_WORKSPACE_DIRECTORY` is not set but I employed a trick to read the `DO_NOT_BUILD_HERE` file that is one level up from `execroot` and that contains the workspace directory. This is experimental and if `bazel test //:test.debug` fails than `bazel run` is still guaranteed to work as `BUILD_WORKSPACE_DIRECTORY` will be set in that context * test //integration:bazel_test and //integration:bazel-schematics_test exclusively * run "exclusive" and "manual" bazel-in-bazel integration tests in their own CI job as they take 8m+ to execute ``` //integration:bazel-schematics_test PASSED in 317.2s //integration:bazel_test PASSED in 167.8s ``` * Skip all integration tests that are now handled by angular_integration_test except the tests that are tracked for payload size; these are: - cli-hello-world* - hello_world__closure * add & pin @babel deps as newer versions of babel break //packages/localize/src/tools/test:test @babel/core dep had to be pinned to 7.6.4 or else //packages/localize/src/tools/test:test failed. Also //packages/localize uses @babel/generator, @babel/template, @babel/traverse & @babel/types so these deps were added to package.json as they were not being hoisted anymore from @babel/core transitive. NB: integration/hello_world__systemjs_umd test must run with systemjs 0.20.0 NB: systemjs must be at 0.18.10 for legacy saucelabs job to pass NB: With Bazel 2.0, the glob for the files to test `"integration/bazel/**"` is empty if integation/bazel is in .bazelignore. This glob worked under these conditions with 1.1.0. I did not bother testing with 1.2.x as not having integration/bazel in .bazelignore is correct. PR Close #33927
2020-02-04 14:45:40 -05:00
"e2e": "ng e2e --port 0",
test(ivy): add cli-hello-world-ivy-i18n integration test (#31609) This test uses localization in the `AppComponent` component: * an `i18n` attribute in the template * a call to the `$localize` tag in the component constructor PR Close #31609
2019-08-12 15:52:58 -04:00
"lint": "ng lint",
"ng": "ng",
test: use puppeteer in integration tests and to download correct chromedriver (#35049) This means integration tests no longer need to depend on a $CI_CHROMEDRIVER_VERSION_ARG environment variable to specify which chromedriver version to download to match the locally installed chrome. This was bad DX and not having it specified was not reliable as webdriver-manager would not always download the chromedriver version to work with the locally installed chrome. webdriver-manager update --gecko=false --standalone=false $CI_CHROMEDRIVER_VERSION_ARG is now replaced with node webdriver-manager-update.js in the root package.json, which checks which version of chrome puppeteer has come bundled with & downloads informs webdriver-manager to download the corresponding chrome driver version. Integration tests now use "webdriver-manager": "file:../../node_modules/webdriver-manager" so they don't have to waste time calling webdriver-manager update in postinstall "// resolutions": "Ensure a single version of webdriver-manager which comes from root node_modules that has already run webdriver-manager update", "resolutions": { "**/webdriver-manager": "file:../../node_modules/webdriver-manager" } This should speed up each integration postinstall by a few seconds. Further, integration test package.json files link puppeteer via file:../../node_modules/puppeteer which is the ideal situation as the puppeteer post-install won't download chrome if it is already downloaded. In CI, since node_modules is cached it should not need to download Chrome either unless the node_modules cache is busted. NB: each version of puppeteer comes bundles with a specific version of chrome. Root package.json & yarn.lock currently pull down puppeteer 2.1.0 which comes with chrome 80. See https://github.com/puppeteer/puppeteer#q-which-chromium-version-does-puppeteer-use for more info. Only two references to CI_CHROMEDRIVER_VERSION_ARG left in integration tests at integration/bazel-schematics/test.sh which I'm not entirely sure how to get rid of it Use a lightweight puppeteer=>chrome version mapping instead of launching chrome and calling browser.version() Launching puppeteer headless chrome and calling browser.version() was a heavy-handed approach to determine the Chrome version. A small and easy to update mappings file is a better solution and it means that the `yarn install` step does not require chrome shared libs available on the system for its postinstall step PR Close #35049
2020-01-31 18:50:44 -05:00
"postinstall": "ngcc --properties es2015 browser module main --first-only --create-ivy-entry-points",
test(ivy): add cli-hello-world-ivy-i18n integration test (#31609) This test uses localization in the `AppComponent` component: * an `i18n` attribute in the template * a call to the `$localize` tag in the component constructor PR Close #31609
2019-08-12 15:52:58 -04:00
"start": "ng serve",
test(localize): add compile time extraction to integration test (#32912) The integration test for i18n now makes use of the new extraction tooling from the `@angular/localize` package rather than the old ViewEngine extractor. PR Close #32912
2019-11-18 05:51:18 -05:00
"pretest": "ng version && rm -fr ../tmp",
test(ivy): i18n - add XMB e2e integration test (#33462) This integration test now does a full e2e test of: * extraction -> build -> translation - serve for both XLIFF 1.2 and XMB formats. Resolves https://github.com/angular/angular/pull/33444#issuecomment-547146280 PR Close #33462
2019-10-29 07:25:26 -04:00
"test": "ng test && yarn e2e --configuration=ci && yarn e2e --configuration=ci-production && yarn translated:test && yarn translated:legacy-xlf:test && yarn translated:legacy-xmb:test",
test(localize): add compile time extraction to integration test (#32912) The integration test for i18n now makes use of the new extraction tooling from the `@angular/localize` package rather than the old ViewEngine extractor. PR Close #32912
2019-11-18 05:51:18 -05:00
"translate": "localize-translate --root \"dist/\" --source \"**/*\" --source-locale \"en-US\" --translations \"[src/locales/messages.de.json, src/locales/extra.de.json]\" [src/locales/messages.fr.json,src/locales/extra.fr.json] --outputPath \"../tmp/translations/{{LOCALE}}\"",
test(ivy): i18n - reenable ivy i18n runtime integration test (#33462) PR Close #33462
2019-10-29 11:04:21 -04:00
"runtime:test": "yarn e2e --configuration=runtime-translations",
feat(ivy): i18n - support source locale inlining (#33101) Add a new flag to `localize-translate` that allows the source locale to be specified. When this locale is provided an extra copy of the files is made for this locale where the is no translation but all the calls to `$localize` are stripped out. Resolves FW-1623 PR Close #33101
2019-10-11 08:42:43 -04:00
"translated:test": "yarn build && yarn translate && yarn translated:fr:e2e && yarn translated:de:e2e && yarn translated:en:e2e",
test: update integration/cli-hello-world-ivy-i18n project structure (#33175) PR Close #33175
2019-10-16 08:04:33 -04:00
"translated:fr:serve": "serve ../tmp/translations/fr --listen 4200",
test: update Angular CLI deps for integration tests (#32957) PR Close #32957
2019-10-02 07:28:23 -04:00
"translated:fr:e2e": "npm-run-all -p -r translated:fr:serve \"ng e2e --configuration=translated-fr\"",
test: update integration/cli-hello-world-ivy-i18n project structure (#33175) PR Close #33175
2019-10-16 08:04:33 -04:00
"translated:de:serve": "serve ../tmp/translations/de --listen 4200",
test: update Angular CLI deps for integration tests (#32957) PR Close #32957
2019-10-02 07:28:23 -04:00
"translated:de:e2e": "npm-run-all -p -r translated:de:serve \"ng e2e --configuration=translated-de\"",
test: update integration/cli-hello-world-ivy-i18n project structure (#33175) PR Close #33175
2019-10-16 08:04:33 -04:00
"translated:en:serve": "serve ../tmp/translations/en-US --listen 4200",
test: update Angular CLI deps for integration tests (#32957) PR Close #32957
2019-10-02 07:28:23 -04:00
"translated:en:e2e": "npm-run-all -p -r translated:en:serve \"ng e2e --configuration=translated-en\"",
test: update integration/cli-hello-world-ivy-i18n project structure (#33175) PR Close #33175
2019-10-16 08:04:33 -04:00
"translated:legacy:serve": "serve ../tmp/translations/legacy --listen 4200",
test(ivy): i18n - add XMB e2e integration test (#33462) This integration test now does a full e2e test of: * extraction -> build -> translation - serve for both XLIFF 1.2 and XMB formats. Resolves https://github.com/angular/angular/pull/33444#issuecomment-547146280 PR Close #33462
2019-10-29 07:25:26 -04:00
"translated:legacy:e2e": "npm-run-all -p -r translated:legacy:serve \"ng e2e --configuration=translated-legacy\"",
test(localize): add compile time extraction to integration test (#32912) The integration test for i18n now makes use of the new extraction tooling from the `@angular/localize` package rather than the old ViewEngine extractor. PR Close #32912
2019-11-18 05:51:18 -05:00
"translated:legacy:translate": "localize-translate --root \"dist/\" --source \"**/*\" --outputPath \"../tmp/translations/{{LOCALE}}\"",
"translated:legacy-xlf:test": "yarn ng build && yarn extract --format xliff --outputPath ../tmp/legacy-locales/messages.legacy.xlf && yarn translated:legacy-xlf:update-translations && yarn ng build --configuration=translated-legacy && yarn translated:legacy:translate -t \"../tmp/legacy-locales/messages.legacy.xlf\" && yarn translated:legacy:e2e",
"translated:legacy-xlf:update-translations": "node scripts/update-xlf-translation-file.js \"../tmp/legacy-locales/messages.legacy.xlf\"",
"translated:legacy-xmb:test": "yarn ng build && yarn extract --format xmb --outputPath ../tmp/legacy-locales/messages.legacy.xmb && yarn translated:legacy-xmb:update-translations && yarn ng build --configuration=translated-legacy-xmb && yarn translated:legacy:translate -t \"../tmp/legacy-locales/messages.legacy.xtb\" && yarn translated:legacy:e2e",
"translated:legacy-xmb:update-translations": "node scripts/update-xmb-translation-file.js \"../tmp/legacy-locales/messages.legacy.xmb\"",
"extract": "localize-extract --source dist/main-es2015*.js"
test(ivy): add cli-hello-world-ivy-i18n integration test (#31609) This test uses localization in the `AppComponent` component: * an `i18n` attribute in the template * a call to the `$localize` tag in the component constructor PR Close #31609
2019-08-12 15:52:58 -04:00
},
"private": true,
"dependencies": {
build: use correct path for local dependencies in `ivy-i18n` integration project (#40756) Previously, the paths to some local dependencies in the `ivy-i18n` integration project were pointing to non-generic bazel files that would normally not exist on a user's machine. This commit changes these paths to relative paths pointing to build artifacts that are guaranteed to exist (once the necessary build commands have been executed). PR Close #40756
2021-02-17 09:15:45 -05:00
"@angular/animations": "file:../../dist/packages-dist/animations",
"@angular/common": "file:../../dist/packages-dist/common",
"@angular/compiler": "file:../../dist/packages-dist/compiler",
"@angular/core": "file:../../dist/packages-dist/core",
"@angular/forms": "file:../../dist/packages-dist/forms",
"@angular/localize": "file:../../dist/packages-dist/localize",
"@angular/platform-browser": "file:../../dist/packages-dist/platform-browser",
"@angular/platform-browser-dynamic": "file:../../dist/packages-dist/platform-browser-dynamic",
"@angular/router": "file:../../dist/packages-dist/router",
"rxjs": "file:../../node_modules/rxjs",
"tslib": "file:../../node_modules/tslib",
"zone.js": "file:../../dist/zone.js-dist/archive/zone.js.tgz"
test(ivy): add cli-hello-world-ivy-i18n integration test (#31609) This test uses localization in the `AppComponent` component: * an `i18n` attribute in the template * a call to the `$localize` tag in the component constructor PR Close #31609
2019-08-12 15:52:58 -04:00
},
"devDependencies": {
build: use correct path for local dependencies in `ivy-i18n` integration project (#40756) Previously, the paths to some local dependencies in the `ivy-i18n` integration project were pointing to non-generic bazel files that would normally not exist on a user's machine. This commit changes these paths to relative paths pointing to build artifacts that are guaranteed to exist (once the necessary build commands have been executed). PR Close #40756
2021-02-17 09:15:45 -05:00
"@angular-devkit/build-angular": "file:../../node_modules/@angular-devkit/build-angular",
"@angular/cli": "file:../../node_modules/@angular/cli",
"@angular/compiler-cli": "file:../../dist/packages-dist/compiler-cli",
"@angular/language-service": "file:../../dist/packages-dist/language-service",
"@types/jasmine": "file:../../node_modules/@types/jasmine",
"@types/jasminewd2": "file:../../node_modules/@types/jasminewd2",
"@types/node": "file:../../node_modules/@types/node",
build: use exact versions for integration project dependencies (#33968) Since we cannot run `yarn install` with the `--frozen-lockfile` option (because we want to be able to install the locally built Angular packages), integration project lockfiles are susceptible to getting out-of-sync with the corresponding `package.json`. When this happens, yarn will install the latest available version that satisfies the version range specified in `package.json`. This commit adds another line of defense, by specifying exact versions for the dependencies in `package.json` files (i.e. `1.33.7` instead of `^1.33.0`). While transitive dependencies will be unpinned, this still ensures that the same version of direct dependencies will be installed in case of an out-of-sync lockfile, thus reducing the probability of random failures. PR Close #33968
2019-11-23 16:52:34 -05:00
"codelyzer": "5.2.0",
"jasmine-core": "3.5.0",
"jasmine-spec-reporter": "4.2.1",
build: upgrade karma to version 4.4.0 (#39180) Upgrade the karma dependency to version 4.4.0 in the root package.json and in integration tests. Compared to version 4.3.0, which most of the packages were previously depending on, it has the following changes: Bug Fixes - runner: remove explicit error on all tests failed Features - client: Add trusted types support - Preprocessor can return Promise - config: add failOnSkippedTests option. - config: clientDisplayNone sets client elements display none. - deps: Remove core-js dependency. The motivation for upgrading the package is the Trusted Types support that it adds, which is necessary to enable Trusted Types in Angular's unit tests. PR Close #39180
2020-10-08 09:08:43 -04:00
"karma": "4.4.0",
build: use exact versions for integration project dependencies (#33968) Since we cannot run `yarn install` with the `--frozen-lockfile` option (because we want to be able to install the locally built Angular packages), integration project lockfiles are susceptible to getting out-of-sync with the corresponding `package.json`. When this happens, yarn will install the latest available version that satisfies the version range specified in `package.json`. This commit adds another line of defense, by specifying exact versions for the dependencies in `package.json` files (i.e. `1.33.7` instead of `^1.33.0`). While transitive dependencies will be unpinned, this still ensures that the same version of direct dependencies will be installed in case of an out-of-sync lockfile, thus reducing the probability of random failures. PR Close #33968
2019-11-23 16:52:34 -05:00
"karma-chrome-launcher": "3.1.0",
"karma-coverage-istanbul-reporter": "2.1.0",
"karma-jasmine": "2.0.1",
"karma-jasmine-html-reporter": "1.4.2",
build: move integration project dependencies to `devDependencies` (#33968) PR Close #33968
2019-11-23 17:12:18 -05:00
"npm-run-all": "4.1.5",
build: use correct path for local dependencies in `ivy-i18n` integration project (#40756) Previously, the paths to some local dependencies in the `ivy-i18n` integration project were pointing to non-generic bazel files that would normally not exist on a user's machine. This commit changes these paths to relative paths pointing to build artifacts that are guaranteed to exist (once the necessary build commands have been executed). PR Close #40756
2021-02-17 09:15:45 -05:00
"protractor": "file:../../node_modules/protractor",
"puppeteer": "file:../../node_modules/puppeteer",
build: move integration project dependencies to `devDependencies` (#33968) PR Close #33968
2019-11-23 17:12:18 -05:00
"serve": "11.2.0",
build: use exact versions for integration project dependencies (#33968) Since we cannot run `yarn install` with the `--frozen-lockfile` option (because we want to be able to install the locally built Angular packages), integration project lockfiles are susceptible to getting out-of-sync with the corresponding `package.json`. When this happens, yarn will install the latest available version that satisfies the version range specified in `package.json`. This commit adds another line of defense, by specifying exact versions for the dependencies in `package.json` files (i.e. `1.33.7` instead of `^1.33.0`). While transitive dependencies will be unpinned, this still ensures that the same version of direct dependencies will be installed in case of an out-of-sync lockfile, thus reducing the probability of random failures. PR Close #33968
2019-11-23 16:52:34 -05:00
"ts-node": "8.3.0",
"tslint": "5.18.0",
build: use correct path for local dependencies in `ivy-i18n` integration project (#40756) Previously, the paths to some local dependencies in the `ivy-i18n` integration project were pointing to non-generic bazel files that would normally not exist on a user's machine. This commit changes these paths to relative paths pointing to build artifacts that are guaranteed to exist (once the necessary build commands have been executed). PR Close #40756
2021-02-17 09:15:45 -05:00
"typescript": "file:../../node_modules/typescript"
test: use puppeteer in integration tests and to download correct chromedriver (#35049) This means integration tests no longer need to depend on a $CI_CHROMEDRIVER_VERSION_ARG environment variable to specify which chromedriver version to download to match the locally installed chrome. This was bad DX and not having it specified was not reliable as webdriver-manager would not always download the chromedriver version to work with the locally installed chrome. webdriver-manager update --gecko=false --standalone=false $CI_CHROMEDRIVER_VERSION_ARG is now replaced with node webdriver-manager-update.js in the root package.json, which checks which version of chrome puppeteer has come bundled with & downloads informs webdriver-manager to download the corresponding chrome driver version. Integration tests now use "webdriver-manager": "file:../../node_modules/webdriver-manager" so they don't have to waste time calling webdriver-manager update in postinstall "// resolutions": "Ensure a single version of webdriver-manager which comes from root node_modules that has already run webdriver-manager update", "resolutions": { "**/webdriver-manager": "file:../../node_modules/webdriver-manager" } This should speed up each integration postinstall by a few seconds. Further, integration test package.json files link puppeteer via file:../../node_modules/puppeteer which is the ideal situation as the puppeteer post-install won't download chrome if it is already downloaded. In CI, since node_modules is cached it should not need to download Chrome either unless the node_modules cache is busted. NB: each version of puppeteer comes bundles with a specific version of chrome. Root package.json & yarn.lock currently pull down puppeteer 2.1.0 which comes with chrome 80. See https://github.com/puppeteer/puppeteer#q-which-chromium-version-does-puppeteer-use for more info. Only two references to CI_CHROMEDRIVER_VERSION_ARG left in integration tests at integration/bazel-schematics/test.sh which I'm not entirely sure how to get rid of it Use a lightweight puppeteer=>chrome version mapping instead of launching chrome and calling browser.version() Launching puppeteer headless chrome and calling browser.version() was a heavy-handed approach to determine the Chrome version. A small and easy to update mappings file is a better solution and it means that the `yarn install` step does not require chrome shared libs available on the system for its postinstall step PR Close #35049
2020-01-31 18:50:44 -05:00
},
"//resolutions-comment": "Ensure a single version of webdriver-manager which comes from root node_modules that has already run webdriver-manager update",
"resolutions": {
build: use correct path for local dependencies in `ivy-i18n` integration project (#40756) Previously, the paths to some local dependencies in the `ivy-i18n` integration project were pointing to non-generic bazel files that would normally not exist on a user's machine. This commit changes these paths to relative paths pointing to build artifacts that are guaranteed to exist (once the necessary build commands have been executed). PR Close #40756
2021-02-17 09:15:45 -05:00
"**/webdriver-manager": "file:../../node_modules/webdriver-manager"
test(ivy): add cli-hello-world-ivy-i18n integration test (#31609) This test uses localization in the `AppComponent` component: * an `i18n` attribute in the template * a call to the `$localize` tag in the component constructor PR Close #31609
2019-08-12 15:52:58 -04:00
}
build: use correct path for local dependencies in `ivy-i18n` integration project (#40756) Previously, the paths to some local dependencies in the `ivy-i18n` integration project were pointing to non-generic bazel files that would normally not exist on a user's machine. This commit changes these paths to relative paths pointing to build artifacts that are guaranteed to exist (once the necessary build commands have been executed). PR Close #40756
2021-02-17 09:15:45 -05:00
}