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

39 lines
1.8 KiB
JSON
Raw Normal View History

refactor(compiler-cli): use the transformer based compiler by default The source map does not currently work with the transformer pipeline. It will be re-enabled after TypeScript 2.4 is made the min version. To revert to the former compiler, use the `disableTransformerPipeline` in tsconfig.json: ``` { "angularCompilerOptions": { "disableTransformerPipeline": true } } ```
2017-08-02 14:20:07 -04:00
{
"name": "angular-integration",
"version": "0.0.0",
"license": "MIT",
"dependencies": {
"@angular/common": "file:../../dist/packages-dist/common",
"@angular/compiler": "file:../../dist/packages-dist/compiler",
"@angular/compiler-cli": "file:../../dist/packages-dist/compiler-cli",
"@angular/core": "file:../../dist/packages-dist/core",
"@angular/platform-browser": "file:../../dist/packages-dist/platform-browser",
refactor: update angular to support TypeScript 2.4 Detailed updates: - rxjs@5.0.x - tsickle@0.24.x - typescript@2.4.x - @bazel/typescript@0.10.0 - protractor@5.1.x - selenium-webdriver@3.0.x BREAKING CHANGE: - the Angular compiler now requires TypeScript 2.4.x.
2017-09-08 21:40:32 -04:00
"rxjs": "file:../../node_modules/rxjs",
"typescript": "file:../../node_modules/typescript",
fix(core): disable tsickle pass when producing APF packages (#37221) As of TypeScript 3.9, the tsc emit is not compatible with Closure Compiler due to https://github.com/microsoft/TypeScript/pull/32011. There is some hope that this will be fixed by a solution like the one proposed in https://github.com/microsoft/TypeScript/issues/38374 but currently it's unclear if / when that will happen. Since the Closure support has been somewhat already broken, and the tsickle pass has been a source of headaches for some time for Angular packages, we are removing it for now while we rethink our strategy to make Angular Closure compatible outside of Google. This change has no effect on our Closure compatibility within Google which work well because all the code is compiled from sources and passed through tsickle. This change only disables the tsickle pass but doesn't remove it. A follow up PR should either remove all the traces of tscikle or re-enable the fixed version. BREAKING CHANGE: Angular npm packages no longer contain jsdoc comments to support Closure Compiler's advanced optimizations The support for Closure compiler in Angular packages has been experimental and broken for quite some time. As of TS3.9 Closure is unusable with the JavaScript emit. Please follow https://github.com/microsoft/TypeScript/issues/38374 for more information and updates. If you used Closure compiler with Angular in the past, you will likely be better off consuming Angular packages built from sources directly rather than consuming the version we publish on npm which is primarily optimized for Webpack/Rollup + Terser build pipeline. As a temporary workaround you might consider using your current build pipeline with Closure flag `--compilation_level=SIMPLE`. This flag will ensure that your build pipeline produces buildable and runnable artifacts, at the cost of increased payload size due to advanced optimizations being disabled. If you were affected by this change, please help us understand your needs by leaving a comment on https://github.com/angular/angular/issues/37234. PR Close #37221
2020-05-19 21:11:37 -04:00
"tslib": "file:../../node_modules/tslib",
test(zone.js): test zone.js package with tgz (#38649) Zone.js 0.11.0 release an empty bundle, and now the npm_package tests all target bazel rule `npm_package`, but not `npm_package.pack`, and these two rules may generate different results, for example, Zone.js 0.11.0's issue is `package.json` define files array which make the bundle only include the files in the files array. So this PR install the zone.js package from the archive generated from `npm_package.pack` rule. PR Close #38649
2020-08-31 00:48:41 -04:00
"zone.js": "file:../../dist/zone.js-dist/archive/zone.js.tgz"
refactor(compiler-cli): use the transformer based compiler by default The source map does not currently work with the transformer pipeline. It will be re-enabled after TypeScript 2.4 is made the min version. To revert to the former compiler, use the `disableTransformerPipeline` in tsconfig.json: ``` { "angularCompilerOptions": { "disableTransformerPipeline": true } } ```
2017-08-02 14:20:07 -04:00
},
"devDependencies": {
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",
refactor(compiler-cli): use the transformer based compiler by default The source map does not currently work with the transformer pipeline. It will be re-enabled after TypeScript 2.4 is made the min version. To revert to the former compiler, use the `disableTransformerPipeline` in tsconfig.json: ``` { "angularCompilerOptions": { "disableTransformerPipeline": true } } ```
2017-08-02 14:20:07 -04:00
"concurrently": "3.4.0",
fix(core): disable tsickle pass when producing APF packages (#37221) As of TypeScript 3.9, the tsc emit is not compatible with Closure Compiler due to https://github.com/microsoft/TypeScript/pull/32011. There is some hope that this will be fixed by a solution like the one proposed in https://github.com/microsoft/TypeScript/issues/38374 but currently it's unclear if / when that will happen. Since the Closure support has been somewhat already broken, and the tsickle pass has been a source of headaches for some time for Angular packages, we are removing it for now while we rethink our strategy to make Angular Closure compatible outside of Google. This change has no effect on our Closure compatibility within Google which work well because all the code is compiled from sources and passed through tsickle. This change only disables the tsickle pass but doesn't remove it. A follow up PR should either remove all the traces of tscikle or re-enable the fixed version. BREAKING CHANGE: Angular npm packages no longer contain jsdoc comments to support Closure Compiler's advanced optimizations The support for Closure compiler in Angular packages has been experimental and broken for quite some time. As of TS3.9 Closure is unusable with the JavaScript emit. Please follow https://github.com/microsoft/TypeScript/issues/38374 for more information and updates. If you used Closure compiler with Angular in the past, you will likely be better off consuming Angular packages built from sources directly rather than consuming the version we publish on npm which is primarily optimized for Webpack/Rollup + Terser build pipeline. As a temporary workaround you might consider using your current build pipeline with Closure flag `--compilation_level=SIMPLE`. This flag will ensure that your build pipeline produces buildable and runnable artifacts, at the cost of increased payload size due to advanced optimizations being disabled. If you were affected by this change, please help us understand your needs by leaving a comment on https://github.com/angular/angular/issues/37234. PR Close #37221
2020-05-19 21:11:37 -04:00
"google-closure-compiler": "file:../../node_modules/google-closure-compiler",
refactor(compiler-cli): use the transformer based compiler by default The source map does not currently work with the transformer pipeline. It will be re-enabled after TypeScript 2.4 is made the min version. To revert to the former compiler, use the `disableTransformerPipeline` in tsconfig.json: ``` { "angularCompilerOptions": { "disableTransformerPipeline": true } } ```
2017-08-02 14:20:07 -04:00
"lite-server": "2.2.2",
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
"protractor": "file:../../node_modules/protractor",
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
"puppeteer": "file:../../node_modules/puppeteer",
"tsickle": "file:../../node_modules/tsickle"
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"
refactor(compiler-cli): use the transformer based compiler by default The source map does not currently work with the transformer pipeline. It will be re-enabled after TypeScript 2.4 is made the min version. To revert to the former compiler, use the `disableTransformerPipeline` in tsconfig.json: ``` { "angularCompilerOptions": { "disableTransformerPipeline": true } } ```
2017-08-02 14:20:07 -04:00
},
"scripts": {
fix(core): disable tsickle pass when producing APF packages (#37221) As of TypeScript 3.9, the tsc emit is not compatible with Closure Compiler due to https://github.com/microsoft/TypeScript/pull/32011. There is some hope that this will be fixed by a solution like the one proposed in https://github.com/microsoft/TypeScript/issues/38374 but currently it's unclear if / when that will happen. Since the Closure support has been somewhat already broken, and the tsickle pass has been a source of headaches for some time for Angular packages, we are removing it for now while we rethink our strategy to make Angular Closure compatible outside of Google. This change has no effect on our Closure compatibility within Google which work well because all the code is compiled from sources and passed through tsickle. This change only disables the tsickle pass but doesn't remove it. A follow up PR should either remove all the traces of tscikle or re-enable the fixed version. BREAKING CHANGE: Angular npm packages no longer contain jsdoc comments to support Closure Compiler's advanced optimizations The support for Closure compiler in Angular packages has been experimental and broken for quite some time. As of TS3.9 Closure is unusable with the JavaScript emit. Please follow https://github.com/microsoft/TypeScript/issues/38374 for more information and updates. If you used Closure compiler with Angular in the past, you will likely be better off consuming Angular packages built from sources directly rather than consuming the version we publish on npm which is primarily optimized for Webpack/Rollup + Terser build pipeline. As a temporary workaround you might consider using your current build pipeline with Closure flag `--compilation_level=SIMPLE`. This flag will ensure that your build pipeline produces buildable and runnable artifacts, at the cost of increased payload size due to advanced optimizations being disabled. If you were affected by this change, please help us understand your needs by leaving a comment on https://github.com/angular/angular/issues/37234. PR Close #37221
2020-05-19 21:11:37 -04:00
"closure": "google-closure-compiler --flagfile closure.conf",
build(common): specify explicit locales dir in package.json (#21016) PR Close #21016
2017-09-29 05:08:12 -04:00
"test": "ngc && yarn run closure && concurrently \"yarn run serve\" \"yarn run protractor\" --kill-others --success first && npm run test-locale-folder",
"test-locale-folder": "node test-locale-folder.js",
refactor(compiler-cli): use the transformer based compiler by default The source map does not currently work with the transformer pipeline. It will be re-enabled after TypeScript 2.4 is made the min version. To revert to the former compiler, use the `disableTransformerPipeline` in tsconfig.json: ``` { "angularCompilerOptions": { "disableTransformerPipeline": true } } ```
2017-08-02 14:20:07 -04:00
"serve": "lite-server -c e2e/browser.config.json",
"preprotractor": "tsc -p e2e",
"protractor": "protractor e2e/protractor.config.js"
}
ci: pin ChromeDriver to a version compatible with docker image's Chrome (#28494) By default, `webdriver-manager update` will download the latest ChromeDriver version, which might not be compatible with the Chrome version included in the [docker image used on CI], causing CI failures. Previously, we used to pin the ChromeDriver version on CI in [ngcontainer's Dockerfile][2]. This was accidentally broken in #26691, while moving from ngcontainer to default CircleCI docker images. This commit fixes the issue by pinning ChromeDriver to a known compatible version. [1]: https://github.com/angular/angular/blob/bfd48d156d5663cc49d1ec40c2d73ff76a2fe62f/.circleci/config.yml#L16 [2]: https://github.com/angular/angular/blob/bfd48d156d5663cc49d1ec40c2d73ff76a2fe62f/tools/ngcontainer/Dockerfile#L63 PR Close #28494
2019-02-01 16:40:33 -05:00
}