angular-cn/package.json

191 lines
7.8 KiB
JSON
Raw Normal View History

2014-09-18 17:56:38 -04:00
{
"name": "angular-srcs",
2020-02-27 00:02:12 -05:00
"version": "9.1.0-next.2",
"private": true,
"description": "Angular - a web framework for modern web apps",
"homepage": "https://github.com/angular/angular",
"bugs": "https://github.com/angular/angular/issues",
"license": "MIT",
"//engines-comment": "Keep this in sync with /aio/package.json and /aio/tools/examples/shared/package.json",
"engines": {
"node": ">=10.9.0 <13.0.0",
"yarn": ">=1.21.1 <2"
},
"repository": {
"type": "git",
"url": "https://github.com/angular/angular.git"
},
2014-09-18 17:56:38 -04:00
"scripts": {
"bazel:format": "find . -type f \\( -name \"*.bzl\" -or -name WORKSPACE -or -name BUILD -or -name BUILD.bazel \\) ! -path \"*/node_modules/*\" | xargs buildifier -v --warnings=attr-cfg,attr-license,attr-non-empty,attr-output-default,attr-single-file,constant-glob,ctx-args,depset-iteration,depset-union,dict-concatenation,duplicated-name,filetype,git-repository,http-archive,integer-division,load,load-on-top,native-build,native-package,output-group,package-name,package-on-top,positional-args,redefined-variable,repository-name,same-origin-load,string-iteration,unused-variable",
"bazel:lint": "yarn bazel:format --lint=warn",
"bazel:lint-fix": "yarn bazel:format --lint=fix",
"preinstall": "node tools/yarn/check-yarn.js",
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": "node scripts/webdriver-manager-update.js && node --preserve-symlinks --preserve-symlinks-main ./tools/postinstall-patches.js",
"check-env": "gulp check-env",
"commitmsg": "node ./scripts/git/commit-msg.js",
"test-ivy-aot": "bazel test --config=ivy --build_tag_filters=-no-ivy-aot,-fixme-ivy-aot --test_tag_filters=-no-ivy-aot,-fixme-ivy-aot",
"test-non-ivy": "bazel test --build_tag_filters=-ivy-only --test_tag_filters=-ivy-only",
"test-fixme-ivy-aot": "bazel test --config=ivy --build_tag_filters=-no-ivy-aot --test_tag_filters=-no-ivy-aot",
"list-fixme-ivy-targets": "bazel query --output=label 'attr(\"tags\", \"\\[.*fixme-ivy.*\\]\", //...) except kind(\"sh_binary\", //...) except kind(\"devmode_js_sources\", //...)' | sort",
"bazel": "bazel",
"//circleci-win-comment": "See the test-win circleci job for why these are needed. If they are not needed anymore, remove them.",
"circleci-win-ve": "bazel test --build_tag_filters=-ivy-only --test_tag_filters=-ivy-only,-browser:chromium-local //packages/compiler-cli/... //tools/ts-api-guardian/...",
"circleci-win-ivy": "bazel test --config=ivy --build_tag_filters=-no-ivy-aot,-fixme-ivy-aot --test_tag_filters=-no-ivy-aot,-fixme-ivy-aot,-browser:chromium-local //packages/compiler-cli/... //tools/ts-api-guardian/..."
2014-09-18 17:56:38 -04:00
},
"// 1": "dependencies are used locally and by bazel",
2014-09-18 17:56:38 -04:00
"dependencies": {
"@angular-devkit/architect": "0.900.3",
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
"@angular-devkit/build-angular": "0.900.3",
"@angular-devkit/build-optimizer": "0.900.3",
"@angular-devkit/core": "9.0.3",
"@angular-devkit/schematics": "9.0.3",
"@angular/bazel": "file:./tools/npm/@angular_bazel",
"@babel/core": "^7.8.6",
"@babel/generator": "^7.8.6",
"@babel/template": "^7.8.6",
"@babel/traverse": "^7.8.6",
"@babel/types": "^7.8.6",
"@bazel/jasmine": "1.3.0",
"@bazel/karma": "1.3.0",
"@bazel/protractor": "1.3.0",
"@bazel/rollup": "1.3.0",
"@bazel/terser": "1.3.0",
"@bazel/typescript": "1.3.0",
"@microsoft/api-extractor": "^7.3.9",
"@schematics/angular": "9.0.3",
"@types/angular": "^1.6.47",
"@types/babel__core": "^7.1.6",
"@types/babel__generator": "^7.6.1",
"@types/babel__template": "^7.0.2",
"@types/babel__traverse": "^7.0.9",
"@types/base64-js": "1.2.5",
"@types/bluebird": "^3.5.27",
"@types/chai": "^4.1.2",
"@types/convert-source-map": "^1.5.1",
"@types/diff": "^3.5.1",
"@types/fs-extra": "4.0.2",
"@types/hammerjs": "2.0.35",
"@types/inquirer": "^0.0.44",
"@types/jasmine": "^2.8.8",
"@types/jasminewd2": "^2.0.6",
"@types/minimist": "^1.2.0",
"@types/node": "^12.11.1",
"@types/selenium-webdriver": "3.0.7",
"@types/semver": "^6.0.2",
"@types/shelljs": "^0.8.6",
"@types/systemjs": "0.19.32",
"@types/yaml": "^1.2.0",
"@types/yargs": "^11.1.1",
"@webcomponents/custom-elements": "^1.0.4",
"angular": "npm:angular@1.7",
"angular-1.5": "npm:angular@1.5",
"angular-1.6": "npm:angular@1.6",
"angular-mocks": "npm:angular-mocks@1.7",
"angular-mocks-1.5": "npm:angular-mocks@1.5",
"angular-mocks-1.6": "npm:angular-mocks@1.6",
"base64-js": "1.2.1",
"bluebird": "^3.5.5",
"brotli": "^1.3.2",
"canonical-path": "1.0.0",
"chai": "^4.1.2",
"chalk": "^2.3.1",
"chokidar": "^3.0.0",
"convert-source-map": "^1.5.1",
"core-js": "^2.4.1",
"dependency-graph": "^0.7.2",
"diff": "^3.5.0",
"domino": "2.1.2",
"fs-extra": "4.0.2",
"hammerjs": "2.0.8",
"http-server": "^0.11.1",
"incremental-dom": "0.4.1",
"jasmine": "^3.1.0",
"jasmine-core": "^3.1.0",
"jquery": "3.0.0",
"karma": "~4.1.0",
"karma-chrome-launcher": "^2.2.0",
"karma-firefox-launcher": "^1.2.0",
"karma-jasmine": "^2.0.1",
"karma-requirejs": "^1.1.0",
"karma-sourcemap-loader": "^0.3.7",
"magic-string": "^0.25.0",
"materialize-css": "1.0.0",
"minimatch": "^3.0.4",
"minimist": "1.2.0",
"node-uuid": "1.4.8",
"nodejs-websocket": "^1.7.2",
"protractor": "^5.4.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
"puppeteer": "2.1.1",
"reflect-metadata": "^0.1.3",
"requirejs": "^2.3.6",
build: remove deps on legacy nodejs rules rollup_bundle internals (#33201) (#33607) The legacy nodejs rules rollup_bundle is now deprecated and will be removed in the nodejs rules 1.0 release due in mid-November. This PR brings in the rules_nodejs internal API deps that ng_rollup_bundle, ng_package and ls_rollup_bundle depend on into this repo to break the dependency. In the future these rules should switch to use the new rollup_bundle via a macro as done in https://github.com/angular/angular/pull/33329 but this is not possible right now due to the complication of having esm5 re-rooted ts_library dependencies. The es6 sources now have .mjs extensions so they no longer need to be re-rooted to `{package}.es6`. This eliminates the need for the collect_es6_sources() function. Note: repo has been updated to the newest working version of rollup which is 1.25.2. There is some regression in 1.26.0 which causes the following bundling failure: ``` ERROR: /Users/greg/google/angular/packages/localize/BUILD.bazel:20:1: Optimizing JavaScript packages/localize/localize.umd.min.js [terser] failed (Exit 1) terser.sh failed: error executing command bazel-out/host/bin/external/npm/terser/bin/terser.sh bazel-out/darwin-fastbuild/bin/packages/localize/localize.umd.js --output bazel-out/darwin-fastbuild/bin/packages/localize/localize.umd.min.js ... (remaining 5 argument(s) skipped) Use --sandbox_debug to see verbose messages from the sandbox Parse error at packages/localize/localize.umd.js:491,4 export * from './src/constants'; ^ ERROR: Export statement may only appear at top level at js_error (/private/var/tmp/_bazel_greg/5e8f8a9cd1c6fbc1afd11e37ee1fe2e5/sandbox/darwin-sandbox/79/execroot/angular/bazel-out/host/bin/external/npm/terser/bin/terser.sh.runfiles/npm/node_modules/terser/lib/parse.js:357:11) at Dn.visit (/private/var/tmp/_bazel_greg/5e8f8a9cd1c6fbc1afd11e37ee1fe2e5/sandbox/darwin-sandbox/79/execroot/angular/bazel-out/host/bin/external/npm/terser/bin/terser.sh.runfiles/npm/node_modules/terser/lib/scope.js:347:13) at Dn._visit (/private/var/tmp/_bazel_greg/5e8f8a9cd1c6fbc1afd11e37ee1fe2e5/sandbox/darwin-sandbox/79/execroot/angular/bazel-out/host/bin/external/npm/terser/bin/terser.sh.runfiles/npm/node_modules/terser/lib/ast.js:1207:24) at AST_Export._walk (/private/var/tmp/_bazel_greg/5e8f8a9cd1c6fbc1afd11e37ee1fe2e5/sandbox/darwin-sandbox/79/execroot/angular/bazel-out/host/bin/external/npm/terser/bin/terser.sh.runfiles/npm/node_modules/terser/lib/ast.js:718:17) at walk_body (/private/var/tmp/_bazel_greg/5e8f8a9cd1c6fbc1afd11e37ee1fe2e5/sandbox/darwin-sandbox/79/execroot/angular/bazel-out/host/bin/external/npm/terser/bin/terser.sh.runfiles/npm/node_modules/terser/lib/ast.js:168:17) at AST_Function.call (/private/var/tmp/_bazel_greg/5e8f8a9cd1c6fbc1afd11e37ee1fe2e5/sandbox/darwin-sandbox/79/execroot/angular/bazel-out/host/bin/external/npm/terser/bin/terser.sh.runfiles/npm/node_modules/terser/lib/ast.js:430:13) at descend (/private/var/tmp/_bazel_greg/5e8f8a9cd1c6fbc1afd11e37ee1fe2e5/sandbox/darwin-sandbox/79/execroot/angular/bazel-out/host/bin/external/npm/terser/bin/terser.sh.runfiles/npm/node_modules/terser/lib/ast.js:1208:21) at Dn.visit (/private/var/tmp/_bazel_greg/5e8f8a9cd1c6fbc1afd11e37ee1fe2e5/sandbox/darwin-sandbox/79/execroot/angular/bazel-out/host/bin/external/npm/terser/bin/terser.sh.runfiles/npm/node_modules/terser/lib/scope.js:256:13) at Dn._visit (/private/var/tmp/_bazel_greg/5e8f8a9cd1c6fbc1afd11e37ee1fe2e5/sandbox/darwin-sandbox/79/execroot/angular/bazel-out/host/bin/external/npm/terser/bin/terser.sh.runfiles/npm/node_modules/terser/lib/ast.js:1207:24) at AST_Function._walk (/private/var/tmp/_bazel_greg/5e8f8a9cd1c6fbc1afd11e37ee1fe2e5/sandbox/darwin-sandbox/79/execroot/angular/bazel-out/host/bin/external/npm/terser/bin/terser.sh.runfiles/npm/node_modules/terser/lib/ast.js:424:24) [Function] Target //packages/localize:npm_package failed to build Use --verbose_failures to see the command lines of failed build steps. ERROR: /Users/greg/google/angular/packages/localize/BUILD.bazel:20:1 Optimizing JavaScript packages/localize/localize.umd.min.js [terser] failed (Exit 1) terser.sh failed: error executing command bazel-out/host/bin/external/npm/terser/bin/terser.sh bazel-out/darwin-fastbuild/bin/packages/localize/localize.umd.js --output bazel-out/darwin-fastbuild/bin/packages/localize/localize.umd.min.js ... (remaining 5 argument(s) skipped) ``` Will leave that for another day. Terser also updated to 4.3.3. Updating to 4.3.4 (https://github.com/terser/terser/blob/master/CHANGELOG.md) turns comments preservation on by default which increases the size of the //packages/core/test/bundling/todo:bundle.min.js in CI. After bazelbuild/rules_nodejs#1317 terser can be updated to the latest as passing —comments /a^/ to args can turn off all comments for the //packages/core/test/bundling/todo:bundle.min.js size test. PR Close #33201 PR Close #33607
2019-10-29 17:21:30 -04:00
"rollup": "~1.25.0",
"rollup-plugin-commonjs": "^10.1.0",
"rollup-plugin-node-resolve": "^5.2.0",
"rollup-plugin-sourcemaps": "^0.4.2",
"rxjs": "^6.5.3",
"selenium-webdriver": "3.5.0",
"shelljs": "^0.8.3",
"source-map": "^0.6.1",
"source-map-support": "0.5.9",
"sourcemap-codec": "^1.4.8",
"systemjs": "0.18.10",
"terser": "^4.4.0",
"tsickle": "0.38.0",
"tslib": "^1.10.0",
"tslint": "5.7.0",
"typescript": "~3.7.4",
"xhr2": "0.1.4",
"yaml": "^1.7.2",
"yargs": "13.1.0"
},
"// 2": "devDependencies are not used under Bazel. Many can be removed after test.sh is deleted.",
"// 3": "when updating @bazel/bazel version you also need to update the RBE settings in .bazelrc (see https://github.com/angular/angular/pull/27935)",
"devDependencies": {
"@angular/cli": "9.0.3",
"@bazel/bazel": "2.1.0",
"@bazel/buildifier": "^0.29.0",
"@bazel/ibazel": "^0.11.1",
"@types/minimist": "^1.2.0",
"@yarnpkg/lockfile": "^1.1.0",
"browserstacktunnel-wrapper": "2.0.1",
"check-side-effects": "0.0.21",
"clang-format": "1.0.41",
"cldr": "4.10.0",
"cldr-data": "36.0.0",
"cldrjs": "0.5.0",
"conventional-changelog": "^2.0.3",
"entities": "1.1.1",
"firebase-tools": "^7.11.0",
"firefox-profile": "1.0.3",
"glob": "7.1.2",
"gulp": "3.9.1",
build: downgrade `gulp-clang-format` to 1.0.23 (#31295) The `gulp format*` tasks have been broken since 5eb742621. These include the `gulp format:enforce` task, which is what runs on CI to enforce consistent code style. Here is what (I believe) happened: - I assume formatting was failing in 5eb742621 (moving `zone.js` into `angular/angular`). The reason must have been that [this glob pattern][1] matches `packages/zone.js/` (which is a directory) and passes it to `clang-format` claiming it is a file. - I further assume that in an attempt to fix the issue, `gulp-clang-format` was updated to the latest version (1.0.27) in 5eb742621. - `gulp format:enforce` stopped complaining, so everyone thought formatting was fine and moved on. - Formatting still wasn't fine, but the task completed successfully nevertheless :scream: - The reason is that angular/gulp-clang-format@55b697c5c (and subsequent commits) changed the way the `done()` callback was called, leaving it to `clang-format` to call it (while previously it was also called when the associated stream ended). - In the old version of `clang-format` that we are using (1.0.41), there is a bug (which has been fixed in angular/clang-format@4cce2c4ee): The callback is not called [unless the process exits with an error][2]. One can also see that the `gulp format:enforce` task is not completed in `gulp lint`. Example output from [build 374722][3]: ``` yarn gulp lint ... Starting 'format:enforce'... Starting 'validate-commit-messages'... ... Finished 'validate-commit-messages' after 833 ms Starting 'tools:build'... Finished 'tools:build' after 1.75 s Starting 'tslint'... Finished 'tslint' after 19 s Done in 21.82s. ``` Notice that all tasks have a corresponding "Finished X` log, except for `format:enforce`. For reference: The problem was originally reported by @ocombe on Slack ([discussion][4]). --- This commit fixes the issue by downgrading `gulp-clang-format` to 1.0.23. The linting failures due to formatting issues will be addressed in subsequent commits. [1]: https://github.com/angular/angular/blob/a8f3b317f/tools/gulp-tasks/format.js#L13 [2]: https://github.com/angular/clang-format/blob/b8c7df0b7/index.js#L95 [3]: https://circleci.com/gh/angular/angular/374722 [4]: https://angular-team.slack.com/archives/C042EU9T5/p1561480241191000 PR Close #31295
2019-06-26 14:09:32 -04:00
"gulp-clang-format": "1.0.23",
"gulp-conventional-changelog": "^2.0.3",
"gulp-filter": "^5.1.0",
"gulp-git": "^2.7.0",
"gulp-tslint": "8.1.2",
"husky": "^0.14.3",
"jpm": "1.3.1",
"karma-browserstack-launcher": "^1.3.0",
"karma-sauce-launcher": "^2.0.2",
"madge": "^3.6.0",
"mutation-observer": "^1.0.3",
"rewire": "2.5.2",
"sauce-connect": "https://saucelabs.com/downloads/sc-4.5.1-linux.tar.gz",
"semver": "^6.3.0",
"tslint-eslint-rules": "4.1.1",
"tslint-no-toplevel-property-access": "0.0.2",
"tsutils": "2.27.2",
"universal-analytics": "0.4.15",
"vlq": "0.2.2",
"vrsource-tslint-rules": "5.1.1"
build: Fix gulp format for Node >= 10.14 (#28213) With Node.js v10.14 and greater, running `yarn gulp format` produces the following error: ``` $ nvm current v10.15.0 $ yarn gulp format:changed yarn run v1.12.3 $ /usr/local/google/home/kyliau/Documents/GitHub/angular/node_modules/.bin/gulp format:changed internal/util/inspect.js:31 const types = internalBinding('types'); ^ ReferenceError: internalBinding is not defined at internal/util/inspect.js:31:15 at req_ (/usr/local/google/home/kyliau/Documents/GitHub/angular/node_modules/natives/index.js:137:5) at require (/usr/local/google/home/kyliau/Documents/GitHub/angular/node_modules/natives/index.js:110:12) at util.js:25:21 at req_ (/usr/local/google/home/kyliau/Documents/GitHub/angular/node_modules/natives/index.js:137:5) at require (/usr/local/google/home/kyliau/Documents/GitHub/angular/node_modules/natives/index.js:110:12) at fs.js:42:21 at req_ (/usr/local/google/home/kyliau/Documents/GitHub/angular/node_modules/natives/index.js:137:5) at Object.req [as require] (/usr/local/google/home/kyliau/Documents/GitHub/angular/node_modules/natives/index.js:54:10) at Object.<anonymous> (/usr/local/google/home/kyliau/Documents/GitHub/angular/node_modules/vinyl-fs/node_modules/graceful-fs/fs.js:1:99) ``` A search on GitHub reveals this issue is due to natives@1.1.4: gulpjs/gulp#2246 ``` $ yarn why natives yarn why v1.12.3 [1/4] Why do we have the module "natives"...? [2/4] Initialising dependency graph... [3/4] Finding dependency... [4/4] Calculating file sizes... => Found "natives@1.1.6" info Reasons this module exists - "gulp#vinyl-fs#graceful-fs" depends on it - Hoisted from "gulp#vinyl-fs#graceful-fs#natives" - Hoisted from "browserstacktunnel-wrapper#unzip#fstream#graceful-fs#natives" ``` The solution is to add a manual resolution for natives@1.1.6 PR Close #28213
2019-01-18 13:43:04 -05:00
},
"// 4": "Overwrite graceful-fs to a version that does not rely on the 'natives' package. This fixes gulp for >= 10.13, more information: #28213",
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
"// 5": "Ensure a single version of webdriver-manager so it is hoisted as the integration tests depend on it being found at ../../node_modules/webdriver-manager",
build: Fix gulp format for Node >= 10.14 (#28213) With Node.js v10.14 and greater, running `yarn gulp format` produces the following error: ``` $ nvm current v10.15.0 $ yarn gulp format:changed yarn run v1.12.3 $ /usr/local/google/home/kyliau/Documents/GitHub/angular/node_modules/.bin/gulp format:changed internal/util/inspect.js:31 const types = internalBinding('types'); ^ ReferenceError: internalBinding is not defined at internal/util/inspect.js:31:15 at req_ (/usr/local/google/home/kyliau/Documents/GitHub/angular/node_modules/natives/index.js:137:5) at require (/usr/local/google/home/kyliau/Documents/GitHub/angular/node_modules/natives/index.js:110:12) at util.js:25:21 at req_ (/usr/local/google/home/kyliau/Documents/GitHub/angular/node_modules/natives/index.js:137:5) at require (/usr/local/google/home/kyliau/Documents/GitHub/angular/node_modules/natives/index.js:110:12) at fs.js:42:21 at req_ (/usr/local/google/home/kyliau/Documents/GitHub/angular/node_modules/natives/index.js:137:5) at Object.req [as require] (/usr/local/google/home/kyliau/Documents/GitHub/angular/node_modules/natives/index.js:54:10) at Object.<anonymous> (/usr/local/google/home/kyliau/Documents/GitHub/angular/node_modules/vinyl-fs/node_modules/graceful-fs/fs.js:1:99) ``` A search on GitHub reveals this issue is due to natives@1.1.4: gulpjs/gulp#2246 ``` $ yarn why natives yarn why v1.12.3 [1/4] Why do we have the module "natives"...? [2/4] Initialising dependency graph... [3/4] Finding dependency... [4/4] Calculating file sizes... => Found "natives@1.1.6" info Reasons this module exists - "gulp#vinyl-fs#graceful-fs" depends on it - Hoisted from "gulp#vinyl-fs#graceful-fs#natives" - Hoisted from "browserstacktunnel-wrapper#unzip#fstream#graceful-fs#natives" ``` The solution is to add a manual resolution for natives@1.1.6 PR Close #28213
2019-01-18 13:43:04 -05:00
"resolutions": {
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
"**/graceful-fs": "4.2.2",
"**/webdriver-manager": "12.1.7"
},
"cldr-data-coverage": "full"
2019-10-02 14:43:00 -04:00
}