angular-cn/package.json

219 lines
8.6 KiB
JSON
Raw Normal View History

2014-09-18 17:56:38 -04:00
{
"name": "angular-srcs",
"version": "11.0.0-next.0",
"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.22.4 <2"
},
"repository": {
"type": "git",
"url": "https://github.com/angular/angular.git"
},
2014-09-18 17:56:38 -04:00
"scripts": {
"/": "",
"// 1": "Many developer of our checks/scripts/tools have moved to our ng-dev tool",
"// 2": "Find the usage you are looking for with:",
"// 3": "yarn ng-dev --help",
"/ ": "",
"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",
"test-ivy-aot": "bazelisk test --config=ivy --build_tag_filters=-no-ivy-aot,-fixme-ivy-aot --test_tag_filters=-no-ivy-aot,-fixme-ivy-aot",
"test-non-ivy": "bazelisk test --build_tag_filters=-ivy-only --test_tag_filters=-ivy-only",
"test-fixme-ivy-aot": "bazelisk test --config=ivy --build_tag_filters=-no-ivy-aot --test_tag_filters=-no-ivy-aot",
"list-fixme-ivy-targets": "bazelisk query --output=label 'attr(\"tags\", \"\\[.*fixme-ivy.*\\]\", //...) except kind(\"sh_binary\", //...) except kind(\"devmode_js_sources\", //...)' | sort",
"//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": "bazelisk test --build_tag_filters=-ivy-only --test_tag_filters=-ivy-only,-browser:chromium-local //packages/compiler-cli/... //tools/ts-api-guardian/...",
"circleci-win-ivy": "bazelisk 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/...",
"lint": "yarn -s tslint && yarn -s ng-dev format changed --check",
"tslint": "tsc -p tools/tsconfig.json && tslint -c tslint.json \"+(dev-infra|packages|modules|scripts|tools)/**/*.+(js|ts)\"",
"public-api:check": "node goldens/public-api/manage.js test",
"public-api:update": "node goldens/public-api/manage.js accept",
"ts-circular-deps": "ts-node --transpile-only -- dev-infra/ts-circular-dependencies/index.ts --config ./packages/circular-deps-test.conf.js",
"ts-circular-deps:check": "yarn -s ts-circular-deps check",
"ts-circular-deps:approve": "yarn -s ts-circular-deps approve",
"ng-dev": "ts-node --transpile-only -- dev-infra/cli.ts"
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.1000.0-rc.2",
"@angular-devkit/build-angular": "0.1000.0-rc.2",
"@angular-devkit/build-optimizer": "0.1000.0-rc.2",
"@angular-devkit/core": "10.0.0-rc.2",
"@angular-devkit/schematics": "10.0.0-rc.2",
"@babel/cli": "^7.8.4",
"@babel/core": "^7.8.6",
"@babel/generator": "^7.8.6",
"@babel/preset-env": "^7.10.2",
"@babel/template": "^7.8.6",
"@babel/traverse": "^7.8.6",
"@babel/types": "^7.8.6",
"@bazel/jasmine": "1.7.0",
"@bazel/karma": "1.7.0",
"@bazel/protractor": "1.7.0",
"@bazel/rollup": "1.7.0",
"@bazel/terser": "1.7.0",
"@bazel/typescript": "1.7.0",
"@microsoft/api-extractor": "7.7.11",
"@octokit/rest": "16.28.7",
"@octokit/types": "^5.0.1",
"@schematics/angular": "10.0.0-rc.2",
"@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": "^7.3.0",
"@types/jasmine": "3.5.10",
"@types/jasmine-ajax": "^3.3.1",
"@types/jasminewd2": "^2.0.8",
"@types/minimist": "^1.2.0",
"@types/node": "^12.11.1",
"@types/node-fetch": "^2.5.7",
"@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": "^15.0.5",
"@webcomponents/custom-elements": "^1.1.0",
"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",
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": "20200517.0.0",
"hammerjs": "2.0.8",
"http-server": "^0.11.1",
"incremental-dom": "0.4.1",
"jasmine": "^3.5.0",
"jasmine-ajax": "^4.0.0",
"jasmine-core": "^3.5.0",
"jquery": "3.0.0",
"js-levenshtein": "^1.1.6",
"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.4",
"materialize-css": "1.0.0",
"minimatch": "^3.0.4",
"minimist": "1.2.0",
"node-fetch": "^2.6.0",
"node-uuid": "1.4.8",
"nodejs-websocket": "^1.7.2",
"protractor": "^5.4.2",
"puppeteer": "3.3.0",
"reflect-metadata": "^0.1.3",
"requirejs": "^2.3.6",
"rollup": "^2.16.1",
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-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",
build: typescript 3.8 support (#35864) This commit adds support in the Angular monorepo and in the Angular compiler(s) for TypeScript 3.8. All packages can now compile with TS 3.8. For most of the repo, only a handful few typings adjustments were needed: * TS 3.8 has a new `CustomElementConstructor` DOM type, which enforces a zero-argument constructor. The `NgElementConstructor` type previously declared a required `injector` argument despite the fact that its implementation allowed `injector` to be optional. The interface type was updated to reflect the optionality of the argument. * Certain error messages were changed, and expectations in tests were updated as a result. * tsserver (part of language server) now returns performance information in responses, so test expectations were changed to only assert on the actual body content of responses. For compiler-cli and schematics (which use the TypeScript AST) a major breaking change was the introduction of the export form: ```typescript export * as foo from 'bar'; ``` This is a `ts.NamespaceExport`, and the `exportClause` of a `ts.ExportDeclaration` can now take this type as well as `ts.NamedExports`. This broke a lot of places where `exportClause` was assumed to be `ts.NamedExports`. For the most part these breakages were in cases where it is not necessary to handle the new `ts.NamedExports` anyway. ngtsc's design uses the `ts.TypeChecker` APIs to understand syntax and so automatically supports the new form of exports. The View Engine compiler on the other hand extracts TS structures into metadata.json files, and that format was not designed for namespaced exports. As a result it will take a nontrivial amount of work if we want to support such exports in View Engine. For now, these new exports are not accounted for in metadata.json, and so using them in "folded" Angular expressions will result in errors (probably claiming that the referenced exported namespace doesn't exist). Care was taken to only use TS APIs which are present in 3.7/3.6, as Angular needs to remain compatible with these for the time being. This commit does not update angular.io. PR Close #35864
2020-03-04 20:27:27 -05:00
"tsickle": "0.38.1",
"tslib": "^2.0.0",
"tslint": "6.1.3",
"typescript": "~4.0.2",
"xhr2": "0.2.0",
"yaml": "^1.7.2",
"yargs": "^15.4.1"
},
"// 2": "devDependencies are not used under Bazel. Many can be removed after test.sh is deleted.",
"devDependencies": {
"@angular/cli": "9.1.0",
"@bazel/bazelisk": "^1.4.0",
"@bazel/buildifier": "^0.29.0",
"@bazel/ibazel": "^0.12.3",
"@octokit/graphql": "^4.3.1",
"@types/cli-progress": "^3.4.2",
"@types/minimist": "^1.2.0",
"@yarnpkg/lockfile": "^1.1.0",
"browserstacktunnel-wrapper": "2.0.1",
"check-side-effects": "0.0.21",
"clang-format": "^1.4.0",
"cldr": "4.10.0",
"cldr-data": "36.0.0",
"cldrjs": "0.5.0",
"cli-progress": "^3.7.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",
"gulp-conventional-changelog": "^2.0.3",
"husky": "^4.2.5",
"inquirer": "^7.3.3",
"inquirer-autocomplete-prompt": "^1.0.2",
"jpm": "1.3.1",
"karma-browserstack-launcher": "^1.3.0",
"karma-sauce-launcher": "^2.0.2",
"madge": "^3.6.0",
"multimatch": "^4.0.0",
"mutation-observer": "^1.0.3",
"nock": "^13.0.3",
"rewire": "2.5.2",
"sauce-connect": "https://saucelabs.com/downloads/sc-4.5.1-linux.tar.gz",
"semver": "^6.3.0",
"ts-node": "^8.6.2",
"tslint-eslint-rules": "5.4.0",
"tslint-no-toplevel-property-access": "0.0.2",
"tsutils": "2.27.2",
"typed-graphqlify": "^2.3.0",
"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",
"husky": {
"hooks": {
"pre-commit": "yarn -s ng-dev format staged",
"commit-msg": "yarn -s ng-dev commit-message pre-commit-validate --file-env-variable HUSKY_GIT_PARAMS",
"prepare-commit-msg": "yarn -s ng-dev commit-message restore-commit-message-draft --file-env-variable HUSKY_GIT_PARAMS"
}
}
}