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

56 lines
2.4 KiB
JSON
Raw Normal View History

test(ivy): ngcc - test compiling a CLI generated project (#26403) This integration test was created from a vanilla CLI generated project with the following modifications: * remove `PercentPipe` usage from `app.component.html` - these are not yet supported by ivy * changed `ng test` in `package.json` to only to `ng build` - right now we can only confirm that the app will build * hard-code `ngDevMode` in `index.html` - the CLI does not yet set this correctly PR Close #26403
2018-10-05 11:45:18 -04:00
{
build: rename cli-hello-world-ivy test to cli-hello-world-ivy-compat (#28372) There are two ways to bootstrap an Ivy app: with `platformBrowserDynamic().bootstrapModule` and `renderComponent`. To distinguish between these two approaches we call the `platformBrowserDynamic().bootstrapModule` way `ivy-compat` and the `renderComponent` way just `ivy`. PR Close #28372
2019-01-28 09:54:34 -05:00
"name": "cli-hello-world-ivy-compat",
test(ivy): ngcc - test compiling a CLI generated project (#26403) This integration test was created from a vanilla CLI generated project with the following modifications: * remove `PercentPipe` usage from `app.component.html` - these are not yet supported by ivy * changed `ng test` in `package.json` to only to `ng build` - right now we can only confirm that the app will build * hard-code `ngDevMode` in `index.html` - the CLI does not yet set this correctly PR Close #26403
2018-10-05 11:45:18 -04:00
"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): ngcc - test compiling a CLI generated project (#26403) This integration test was created from a vanilla CLI generated project with the following modifications: * remove `PercentPipe` usage from `app.component.html` - these are not yet supported by ivy * changed `ng test` in `package.json` to only to `ng build` - right now we can only confirm that the app will build * hard-code `ngDevMode` in `index.html` - the CLI does not yet set this correctly PR Close #26403
2018-10-05 11:45:18 -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): ngcc - test compiling a CLI generated project (#26403) This integration test was created from a vanilla CLI generated project with the following modifications: * remove `PercentPipe` usage from `app.component.html` - these are not yet supported by ivy * changed `ng test` in `package.json` to only to `ng build` - right now we can only confirm that the app will build * hard-code `ngDevMode` in `index.html` - the CLI does not yet set this correctly PR Close #26403
2018-10-05 11:45:18 -04:00
"start": "ng serve",
test: log cli version in `cli-hello-world[-ivy]` integration projects (#26947) This helps debug issues on CI. PR Close #26947
2019-01-17 14:38:19 -05:00
"pretest": "ng version",
test: update Angular CLI deps for integration tests (#32957) PR Close #32957
2019-10-02 07:28:23 -04:00
"test": "ng test && yarn e2e --configuration=ci && yarn e2e --configuration=ci-production"
test(ivy): ngcc - test compiling a CLI generated project (#26403) This integration test was created from a vanilla CLI generated project with the following modifications: * remove `PercentPipe` usage from `app.component.html` - these are not yet supported by ivy * changed `ng test` in `package.json` to only to `ng build` - right now we can only confirm that the app will build * hard-code `ngDevMode` in `index.html` - the CLI does not yet set this correctly PR Close #26403
2018-10-05 11:45:18 -04:00
},
"private": true,
"dependencies": {
"@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/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",
feat: typescript 3.6 support (#32946) BREAKING CHANGE: typescript 3.4 and 3.5 are no longer supported, please update to typescript 3.6 Fixes #32380 PR Close #32946
2019-10-01 19:44:50 -04:00
"tslib": "file:../../node_modules/tslib",
test(ngcc): build `zone.js` from source in `scripts/build-packages-dist.sh` (#33733) In #33046, internal uses of `zone.js` were switched to reference it directly from source (built with Bazel) instead of npm. As a result, the necessary scripts were updated to build `zone.js` as necessary. However, some `integration/**/debug-test.sh` scripts were missed (apparently because they are not used on CI, but only locally as helpers for debugging the integration projects). This commit updates the `scripts/build-packages-dist.sh` script to also build `zone.js`, so that other scripts (such as the various `debug-test.sh` scripts) can use it. PR Close #33733
2019-11-11 10:11:34 -05:00
"zone.js": "file:../../dist/zone.js-dist/zone.js"
test(ivy): ngcc - test compiling a CLI generated project (#26403) This integration test was created from a vanilla CLI generated project with the following modifications: * remove `PercentPipe` usage from `app.component.html` - these are not yet supported by ivy * changed `ng test` in `package.json` to only to `ng build` - right now we can only confirm that the app will build * hard-code `ngDevMode` in `index.html` - the CLI does not yet set this correctly PR Close #26403
2018-10-05 11:45:18 -04:00
},
"devDependencies": {
build: consolidate @angular-devkit/build-angular to the root package.json (#34002) This allows us to update the version of the package in a single place for all tests. Notable exemption of this is aio which currently doesn't depend on anything installed in the root. PR Close #34002
2019-11-22 19:31:40 -05:00
"@angular-devkit/build-angular": "file:../../node_modules/@angular-devkit/build-angular",
build(bazel): Use @angular/cli from root package.json (#28139) A few integration tests now depend on @angular/cli. This commit changes the affected tests to use the dependency on @angular/cli defined at root package.json. PR Close #28139
2019-01-14 16:12:45 -05:00
"@angular/cli": "file:../../node_modules/@angular/cli",
test(ivy): ngcc - test compiling a CLI generated project (#26403) This integration test was created from a vanilla CLI generated project with the following modifications: * remove `PercentPipe` usage from `app.component.html` - these are not yet supported by ivy * changed `ng test` in `package.json` to only to `ng build` - right now we can only confirm that the app will build * hard-code `ngDevMode` in `index.html` - the CLI does not yet set this correctly PR Close #26403
2018-10-05 11:45:18 -04:00
"@angular/compiler-cli": "file:../../dist/packages-dist/compiler-cli",
"@angular/language-service": "file:../../dist/packages-dist/language-service",
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
"@types/jasmine": "file:../../node_modules/@types/jasmine",
"@types/jasminewd2": "file:../../node_modules/@types/jasminewd2",
test: use @types/node compatible with TS 3.6 (#32946) PR Close #32946
2019-10-17 07:18:19 -04:00
"@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",
"karma": "4.3.0",
"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",
test(ivy): ngcc - test compiling a CLI generated project (#26403) This integration test was created from a vanilla CLI generated project with the following modifications: * remove `PercentPipe` usage from `app.component.html` - these are not yet supported by ivy * changed `ng test` in `package.json` to only to `ng build` - right now we can only confirm that the app will build * hard-code `ngDevMode` in `index.html` - the CLI does not yet set this correctly PR Close #26403
2018-10-05 11:45:18 -04:00
"protractor": "file:../../node_modules/protractor",
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
"puppeteer": "file:../../node_modules/puppeteer",
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",
test(ivy): ngcc - test compiling a CLI generated project (#26403) This integration test was created from a vanilla CLI generated project with the following modifications: * remove `PercentPipe` usage from `app.component.html` - these are not yet supported by ivy * changed `ng test` in `package.json` to only to `ng build` - right now we can only confirm that the app will build * hard-code `ngDevMode` in `index.html` - the CLI does not yet set this correctly PR Close #26403
2018-10-05 11:45:18 -04: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": {
"**/webdriver-manager": "file:../../node_modules/webdriver-manager"
test(ivy): ngcc - test compiling a CLI generated project (#26403) This integration test was created from a vanilla CLI generated project with the following modifications: * remove `PercentPipe` usage from `app.component.html` - these are not yet supported by ivy * changed `ng test` in `package.json` to only to `ng build` - right now we can only confirm that the app will build * hard-code `ngDevMode` in `index.html` - the CLI does not yet set this correctly PR Close #26403
2018-10-05 11:45:18 -04:00
}
}