iSharkFly-Docs
/
angular-docs-cn
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
angular-docs-cn/package.json

206 lines
8.5 KiB
JSON
Raw Normal View History

build - refactor
2014-09-18 17:56:38 -04:00
{
chore(package.json): remove typings bundles This was used for , but now that our typings are laid out in the node_module, users should no longer need that. Also fix the project name in root package.json. There is a risk that someone runs npm publish in this directory, which will create a new version of angular 1, and contain a scary source tree. So this package.json may as well have a name that doesn't exist on npm, and if we did publish by accident, it would be a package name that matches the contents.
2015-10-15 12:57:29 -04:00
"name": "angular-srcs",
release: cut the v10.0.0-next.1 release
2020-04-08 15:28:12 -04:00
"version": "10.0.0-next.1",
repackaging: all the repackaging changes squashed
2016-04-28 20:50:03 -04:00
"private": true,
docs: branding fixes (#14132) Angular 1.x -> AngularJS Angular 1 -> AngularJS Angular1 -> AngularJS Angular 2+ -> Angular Angular 2.0 -> Angular Angular2 -> Angular I have deliberately not touched any of the symbol names as that would cause big merge collisions with Tobias's work. All the renames are in .md, .json, and inline comments and jsdocs. PR Close #14132
2017-01-27 01:30:42 -05:00
"description": "Angular - a web framework for modern web apps",
feat(build): add npm publish script Also fixes gulpfile: - `runSequence` needs to be called with `done` callback - `es5build` should only run when the task executes…
2015-02-10 18:18:16 -05:00
"homepage": "https://github.com/angular/angular",
"bugs": "https://github.com/angular/angular/issues",
doc(*): change package.json license field to MIT Align the package.json license with the LICENSE file from the repo Closes #6432
2016-01-12 11:36:43 -05:00
"license": "MIT",
build: set upper version limit for yarn to <2 (#34236) Rather than bumping up the allowed version of yarn on each release we should instead just allow for anything within the major version 1 range. PR Close #34236
2019-12-04 15:05:53 -05:00
"//engines-comment": "Keep this in sync with /aio/package.json and /aio/tools/examples/shared/package.json",
chore(package.json): add range of supported node versions as engines Closes #5535
2015-12-01 17:09:31 -05:00
"engines": {
ci: use circleci windows preview (#31266) PR Close #31266
2019-07-25 10:47:02 -04:00
"node": ">=10.9.0 <13.0.0",
build: update to yarn@1.21.1 (#34384) This updates yarn throughout the monorepo for both build and CI. PR Close #34384
2019-12-12 16:26:42 -05:00
"yarn": ">=1.21.1 <2"
chore(package.json): add range of supported node versions as engines Closes #5535
2015-12-01 17:09:31 -05:00
},
chore(package.json): npm No repository field. npm install yields a warning ```bash npm WARN package.json angular@0.0.0 No repository field. ``` also include `"bugs": "https://github.com/angular/angular/issues"`
2015-01-24 13:50:18 -05:00
"repository": {
"type": "git",
"url": "https://github.com/angular/angular.git"
},
build - refactor
2014-09-18 17:56:38 -04:00
"scripts": {
build: update buildifier to version that supports windows (#31112) * Updates buildifier to a version that also comes with windows binaries. * Fixes a few new formatting/lint warnings * Removes the `args-order` warning because it is no longer a warning.. and is now part of the formatter. PR Close #31112
2019-06-18 13:39:29 -04:00
"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",
ci: use buildifier binary release (#27489) Switch from Skylint to buildifier --lint - this is required for the Bazel 0.20 upgrade since Bazel no longer lets us use the embedded JDK to build and run Java programs, and Skylint is a Java program PR Close #27489
2018-12-05 15:16:14 -05:00
"bazel:lint": "yarn bazel:format --lint=warn",
"bazel:lint-fix": "yarn bazel:format --lint=fix",
build: upgrade yarn to 1.3.2 (#21406) Fixes #20566 PR Close #21406
2018-01-09 05:02:03 -05:00
"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",
refactor: add a commit-msg git hook to check commit messages (#22969) The commit command will fail if the commit message header does not follow the Angular convetions as defined in /CONTRIBUTING.md. You can force the commit by adding the `--no-verify` option. NOTE: You should remove all unused hooks (in <angular>/.git/hooks) before running `yarn` so that husky hooks are installed correctly. PR Close #22969
2018-03-23 19:07:33 -04:00
"check-env": "gulp check-env",
build: depend on bazelisk rather than directly on Bazel (#36078) This has a couple benefits: - we now use a .bazelversion file rather than package.json to pin the version of bazel we want. This means even if you install bazel on your computer rather than via yarn, you'll still get a warning if your bazel version is wrong. - you no longer end up downloading three copies of bazel due to bugs in both npm and yarn where they download all tarballs before checking the metadata to see which are usable on the local platform. - bazelisk correctly handles the tools/bazel trick for wrapping functionality, which we want to use to instrument developer build latencies PR Close #36078
2020-02-04 19:14:21 -05:00
"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",
"bazel": "bazelisk",
ci: use circleci windows preview (#31266) PR Close #31266
2019-07-25 10:47:02 -04:00
"//circleci-win-comment": "See the test-win circleci job for why these are needed. If they are not needed anymore, remove them.",
build: depend on bazelisk rather than directly on Bazel (#36078) This has a couple benefits: - we now use a .bazelversion file rather than package.json to pin the version of bazel we want. This means even if you install bazel on your computer rather than via yarn, you'll still get a warning if your bazel version is wrong. - you no longer end up downloading three copies of bazel due to bugs in both npm and yarn where they download all tarballs before checking the metadata to see which are usable on the local platform. - bazelisk correctly handles the tools/bazel trick for wrapping functionality, which we want to use to instrument developer build latencies PR Close #36078
2020-02-04 19:14:21 -05:00
"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/...",
build: no longer run tslint from within gulp task (#35800) Switches our tslint setup to the standard `tslint.json` linter excludes. The set of files that need to be linted is specified through a Yarn script. For IDEs, open files are linted with the closest tslint configuration, if the tslint IDE extension is set up, and the source file is not excluded. We cannot use the language service plugin for tslint as we have multiple nested tsconfig files, and we don't want to add the plugin to each tsconfig. We could reduce that bloat by just extending from a top-level tsconfig that defines the language service plugin, but unfortunately the tslint plugin does not allow the use of tslint configs which are not part of the tsconfig project. This is problematic since the tslint configuration is at the project root, and we don't want to copy tslint configurations next to each tsconfig file. Additionally, linting of `d.ts` files has been re-enabled. This has been disabled in the past and a TODO has been left. This commit fixes the lint issues and re-enables linting. PR Close #35800
2020-03-02 12:35:30 -05:00
"lint": "yarn -s tslint && yarn gulp lint",
ci: move public-api goldens to goldens directory (#35768) Moves the public api .d.ts files from tools/public_api_guard to goldens/public-api. Additionally, provides a README in the goldens directory and a script assist in testing the current state of the repo against the goldens as well as a command for accepting all changes to the goldens in a single command. PR Close #35768
2020-02-26 12:09:35 -05:00
"tslint": "tsc -p tools/tsconfig.json && tslint -c tslint.json \"+(packages|modules|scripts|tools)/**/*.+(js|ts)\"",
"public-api:check": "node goldens/public-api/manage.js test",
build: create tool for validating typescript circular dependencies (#35647) Creates a tool for validating TypeScript circular dependencies. The tool has been designed in a way that allows us to slowly burn down the amount of circular dependencies while ensuring that we don't regress. The tool doesn't rely on Madge since it doesn't provide a programmatic way for doing path mapping. We need path mapping since we also want to check for cycles across different entry-points or packages. The tool uses the TypeScript AST to manually collect cycles. This code is not a lot of bloat and also gives us more flexibility (if we ever need it). Closes #35041. PR Close #35647
2020-02-24 06:03:15 -05:00
"public-api:update": "node goldens/public-api/manage.js accept",
feat(dev-infra): standard CLI commands using yargs (#36326) Creates a standard model for CLI commands provided by ng-dev. Allows for us to have any of the tools/scripts extend to be included in the ng-dev command, or be standalone using the same yargs parser. PR Close #36326
2020-03-26 13:45:09 -04:00
"ts-circular-deps": "ts-node --transpile-only -- dev-infra/ts-circular-dependencies/index.ts --config ./packages/circular-deps-test.conf.js",
build: allow custom module resolution for ts-circular-deps tests (#36226) Currently the `ts-circular-deps` tool uses a hard-coded module resolver that only works in the `angular/angular` repository. If the tool is consumed in other repositories through the shared dev-infra package, the module resolution won't work, and a few resolvable imports (usually cross-entry-points) are accidentally skipped. For each test, the resolution might differ, so tests can now configure their module resolution in a configuration file. Note that we intentionally don't rely on tsconfig's for module resolution as parsing their mappings rather complicates the circular dependency tool. Additionally, not every test has a corresponding tsconfig file. Also, hard-coding mappings to `@angular/*` while accepting a path to the packages folder would work, but it would mean that the circular deps tool is no longer self-contained. Rather, and also for better flexibility, a custom resolver should be specified. PR Close #36226
2020-03-24 10:43:54 -04:00
"ts-circular-deps:check": "yarn -s ts-circular-deps check",
feat(dev-infra): standard CLI commands using yargs (#36326) Creates a standard model for CLI commands provided by ng-dev. Allows for us to have any of the tools/scripts extend to be included in the ng-dev command, or be standalone using the same yargs parser. PR Close #36326
2020-03-26 13:45:09 -04:00
"ts-circular-deps:approve": "yarn -s ts-circular-deps approve",
"ng-dev": "ts-node --transpile-only -- dev-infra/cli.ts"
build - refactor
2014-09-18 17:56:38 -04:00
},
build: Move non-bazel deps to devDependencies (#26691) This makes yarn_install of ngdeps under Bazel faster, since we don't need many of the large dependencies. It's important because downstream angular/bazel users will observe the same install time. PR Close #26691
2018-10-22 17:26:52 -04:00
"// 1": "dependencies are used locally and by bazel",
build - refactor
2014-09-18 17:56:38 -04:00
"dependencies": {
build: update cli packages to latest versions (#35608) PR Close #35608
2020-02-21 04:09:15 -05:00
"@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",
build: update cli packages to latest versions (#35608) PR Close #35608
2020-02-21 04:09:15 -05:00
"@angular-devkit/build-optimizer": "0.900.3",
"@angular-devkit/core": "9.0.3",
"@angular-devkit/schematics": "9.0.3",
build: enable IDE type checking of $localize code (#35711) The `packages/localize/src/tools` folder was excluded from the top level `tsconfig.json` which meant that in IDEs these source files were not being given the correct configuration. It was originally excluded because it required the native `node` typings but this is no longer a requirement. Removing this folder from the exclusion list exposed a new issue where there was a typings mismatch between `@babel/...` sources and the associated `@types/babel__...` typings packages. A clean up of the package.json and yarn.lock appears to fix this. PR Close #35711
2020-02-27 04:32:13 -05:00
"@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",
build: update to rules_nodejs 1.6.0 (#36580) Lots of bug fixes and stability fixes. Last 1.x release for rules_nodejs. PR Close #36580
2020-04-11 12:15:16 -04:00
"@bazel/jasmine": "1.6.0",
"@bazel/karma": "1.6.0",
"@bazel/protractor": "1.6.0",
"@bazel/rollup": "1.6.0",
"@bazel/terser": "1.6.0",
"@bazel/typescript": "1.6.0",
build: rebuild yarn lock from scratch (#36377) Rebuild the yarn lock file from scratch to collapse instances where one package is able to satisfy multiple dependencies. Currently we have some situations where we have multiple versions when one would work. Example: ``` "@babel/code-frame@^7.0.0": version "7.0.0" resolved "https://registry.yarnpkg.com/@babel/cod integrity sha512-OfC2uemaknXr87bdLUkWog7nYuliM9Ij dependencies: "@babel/highlight" "^7.0.0" "@babel/code-frame@^7.5.5": version "7.5.5" resolved "https://registry.yarnpkg.com/@babel/cod integrity sha512-27d4lZoomVyo51VegxI20xZPuSHusqbQ dependencies: "@babel/highlight" "^7.0.0" "@babel/code-frame@^7.8.3": version "7.8.3" resolved "https://registry.yarnpkg.com/@babel/cod integrity sha512-a9gxpmdXtZEInkCSHUJDLHZVBgb1QS0j dependencies: "@babel/highlight" "^7.8.3" ``` becomes ``` "@babel/code-frame@^7.0.0", "@babel/code-frame@^7.5.5", "@babel/code-frame@^7.8.3": version "7.8.3" resolved "https://registry.yarnpkg.com/@babel/cod integrity sha512-a9gxpmdXtZEInkCSHUJDLHZVBgb1QS0j dependencies: "@babel/highlight" "^7.8.3" ``` PR Close #36377
2020-03-24 13:20:28 -04:00
"@microsoft/api-extractor": "~7.6.0",
build: update cli packages to latest versions (#35608) PR Close #35608
2020-02-21 04:09:15 -05:00
"@schematics/angular": "9.0.3",
build: switch example e2e tests to bazel (#28402) * No longer builds the example e2e tests using "tsc". The examples are now built with Bazel and can therefore be built with Ivy by using the `--define=compile=aot` switch. * No longer runs the example e2e tests using the protractor CLI. example e2e tests are executed with the Bazel protractor rule and can therefore run incrementally. NOTE: Unit tests found within the examples are still running within the legacy jobs. PR Close #28402
2019-01-28 15:59:25 -05:00
"@types/angular": "^1.6.47",
build: enable IDE type checking of $localize code (#35711) The `packages/localize/src/tools` folder was excluded from the top level `tsconfig.json` which meant that in IDEs these source files were not being given the correct configuration. It was originally excluded because it required the native `node` typings but this is no longer a requirement. Removing this folder from the exclusion list exposed a new issue where there was a typings mismatch between `@babel/...` sources and the associated `@types/babel__...` typings packages. A clean up of the package.json and yarn.lock appears to fix this. PR Close #35711
2020-02-27 04:32:13 -05:00
"@types/babel__core": "^7.1.6",
build: explicitly define @babel/generator dep in package.json (#34974) Previously we just happened to be able to use it because of npm hoisting. PR Close #34974
2020-01-26 15:03:54 -05:00
"@types/babel__generator": "^7.6.1",
build: enable IDE type checking of $localize code (#35711) The `packages/localize/src/tools` folder was excluded from the top level `tsconfig.json` which meant that in IDEs these source files were not being given the correct configuration. It was originally excluded because it required the native `node` typings but this is no longer a requirement. Removing this folder from the exclusion list exposed a new issue where there was a typings mismatch between `@babel/...` sources and the associated `@types/babel__...` typings packages. A clean up of the package.json and yarn.lock appears to fix this. PR Close #35711
2020-02-27 04:32:13 -05:00
"@types/babel__template": "^7.0.2",
"@types/babel__traverse": "^7.0.9",
build: switch playground examples to bazel (#28490) Currently all playground examples are built with `tsc` and served with the `gulp serve` task. In order to be able to test these examples easily with Ivy, we now build and serve the examples using Bazel. This allows us to expand our Ivy test coverage and additionally it allows us to move forward with the overall Bazel migration. Building & serving individual examples is now very easy and doesn't involve building everything inside of `/modules`. PR Close #28490
2019-02-01 08:27:13 -05:00
"@types/base64-js": "1.2.5",
build: move zone.js to angular repo (#30962) PR Close #30962
2019-05-31 11:56:07 -04:00
"@types/bluebird": "^3.5.27",
build(bazel): remove @ts-api-guardian_deps yarn_install (#29799) PR Close #29799
2019-04-09 21:08:13 -04:00
"@types/chai": "^4.1.2",
build: add dependencies to be used by ngcc (#24897) PR Close #24897
2018-07-16 02:08:48 -04:00
"@types/convert-source-map": "^1.5.1",
build(bazel): remove @ts-api-guardian_deps yarn_install (#29799) PR Close #29799
2019-04-09 21:08:13 -04:00
"@types/diff": "^3.5.1",
build: update npm dependencies (#19328) PR Close #19328
2017-09-22 13:51:03 -04:00
"@types/fs-extra": "4.0.2",
"@types/hammerjs": "2.0.35",
refactor(core): allow developers to select static-query migration strategy (#29876) Currently there are two available migration strategies for the `static-query` schematic. Both have benefits and negatives which depend on what the developer prefers. Since we can't decide which migration strategy is the best for a given project, the developer should be able to select a specific strategy through a simple choice prompt. In order to be able to use prompts in a migration schematic, we need to take advantage of the "inquirer" package which is also used by the CLI schematic prompts (schematic prompts are usually only statically defined in the schema). Additionally the schematic needs to be made "async" because with prompts the schematic can no longer execute synchronously without implementing some logic that blocks the execution. PR Close #29876
2019-04-12 18:14:33 -04:00
"@types/inquirer": "^0.0.44",
build: update jasmine to 3.5 (#34625) 1. update jasmine to 3.5 2. update @types/jasmine to 3.5 3. update @types/jasminewd2 to 2.0.8 Also fix several cases, the new jasmine 3 will help to create test cases correctly, such as in the `jasmine 2.x` version, the following case will pass ``` expect(1 == 2); ``` But in jsamine 3, the case will need to be ``` expect(1 == 2).toBeTrue(); ``` PR Close #34625
2020-01-03 00:28:06 -05:00
"@types/jasmine": "3.5.10",
"@types/jasminewd2": "^2.0.8",
build(bazel): remove @ts-api-guardian_deps yarn_install (#29799) PR Close #29799
2019-04-09 21:08:13 -04:00
"@types/minimist": "^1.2.0",
test: use @types/node compatible with TS 3.6 (#32946) PR Close #32946
2019-10-17 07:18:19 -04:00
"@types/node": "^12.11.1",
build: update npm dependencies (#19328) PR Close #19328
2017-09-22 13:51:03 -04:00
"@types/selenium-webdriver": "3.0.7",
feat(ngcc): support version ranges in project/default configurations (#33008) By appending a version range to the package name, it is now possible to target configuration to specific versions of a package. PR Close #33008
2019-10-04 06:54:33 -04:00
"@types/semver": "^6.0.2",
build: fix build scripts on macOS (#33854) In #33823, `scripts/package-builds.sh` (which is used by both `build-packages-dist.sh` and `build-ivy-npm-packages.sh`) was updated to use `realpath`. It turns out that `realpath` does not exist on macOS, so the build scripts do not work there. In order to fix this (and also reduce the likelihood of introducing similar issues in the future), this commit changes these bash scripts to Node.js scripts (using [ShellJS](https://github.com/shelljs/shelljs) for a cross-platform implementation of Unix shell commands where necessary). PR Close #33854
2019-11-14 19:56:55 -05:00
"@types/shelljs": "^0.8.6",
build: move zone.js to angular repo (#30962) PR Close #30962
2019-05-31 11:56:07 -04:00
"@types/systemjs": "0.19.32",
ci: add verification of the pullapprove config (#35060) Verify that all files in the repo are covered by the pullapprove config and that all rules in the pullapprove config match at least one file in the repo. PR Close #35060
2020-01-30 11:05:40 -05:00
"@types/yaml": "^1.2.0",
fix(ivy): ngcc should compile entry-points in the correct order (#25862) The compiler should process all an entry-points dependencies before processing that entry-point. PR Close #25862
2018-08-09 10:59:10 -04:00
"@types/yargs": "^11.1.1",
build: fix elements test failures on IE (#35940) Fixes the following issues which caused the `elements` unit tests to break on IE: 1. `core.js` wasn't included which caused an error about `Promise` and `Symbol` to be thrown. 2. We were using a version of `@webcomponents/custom-elements` which was shipping ES6 code to npm. As a result, IE was throwing a syntax error. PR Close #35940
2020-03-08 11:52:17 -04:00
"@webcomponents/custom-elements": "^1.1.0",
test(upgrade): run tests against AngularJS v1.7.x as well (#25231) PR Close #25231
2018-07-31 08:10:13 -04:00
"angular": "npm:angular@1.7",
test(upgrade): run tests against multiple AngularJS versions (#22167) Fixes #19332 PR Close #22167
2018-02-15 12:21:18 -05:00
"angular-1.5": "npm:angular@1.5",
test(upgrade): run tests against AngularJS v1.7.x as well (#25231) PR Close #25231
2018-07-31 08:10:13 -04:00
"angular-1.6": "npm:angular@1.6",
"angular-mocks": "npm:angular-mocks@1.7",
test(upgrade): run tests against multiple AngularJS versions (#22167) Fixes #19332 PR Close #22167
2018-02-15 12:21:18 -05:00
"angular-mocks-1.5": "npm:angular-mocks@1.5",
test(upgrade): run tests against AngularJS v1.7.x as well (#25231) PR Close #25231
2018-07-31 08:10:13 -04:00
"angular-mocks-1.6": "npm:angular-mocks@1.6",
build: update npm dependencies (#19328) PR Close #19328
2017-09-22 13:51:03 -04:00
"base64-js": "1.2.1",
build: move zone.js to angular repo (#30962) PR Close #30962
2019-05-31 11:56:07 -04:00
"bluebird": "^3.5.5",
build: Remove cc_binary dependency on brotli (#29912) Just use the JavaScript port instead. We don't care about speed since we compress once as a build step. PR Close #29912
2019-04-15 14:57:36 -04:00
"brotli": "^1.3.2",
build: update `canonical-path` dependency (#26719) This new version (1.0.0) provides a typings file! PR Close #26719
2018-10-24 08:24:14 -04:00
"canonical-path": "1.0.0",
build(bazel): remove @ts-api-guardian_deps yarn_install (#29799) PR Close #29799
2019-04-09 21:08:13 -04:00
"chai": "^4.1.2",
"chalk": "^2.3.1",
build(compiler-cli): update to chokidar 3.x (#35047) Update from chokidar 2.x to 3.x in ngc/ngtsc, to eliminate any possibility of a security issue with a downstream dependency of the package. FW-1809 #resolve PR Close #35047
2020-01-29 16:16:52 -05:00
"chokidar": "^3.0.0",
build: Move non-bazel deps to devDependencies (#26691) This makes yarn_install of ngdeps under Bazel faster, since we don't need many of the large dependencies. It's important because downstream angular/bazel users will observe the same install time. PR Close #26691
2018-10-22 17:26:52 -04:00
"convert-source-map": "^1.5.1",
build: move zone.js to angular repo (#30962) PR Close #30962
2019-05-31 11:56:07 -04:00
"core-js": "^2.4.1",
build: Move non-bazel deps to devDependencies (#26691) This makes yarn_install of ngdeps under Bazel faster, since we don't need many of the large dependencies. It's important because downstream angular/bazel users will observe the same install time. PR Close #26691
2018-10-22 17:26:52 -04:00
"dependency-graph": "^0.7.2",
test(bazel): fix all ng_package tests not working on windows (#27829) PR Close #27829
2018-12-25 14:50:54 -05:00
"diff": "^3.5.0",
feat: upgrade domino to v2.1.2 (#28767) PR Close #28767
2019-02-15 16:18:44 -05:00
"domino": "2.1.2",
build: Move non-bazel deps to devDependencies (#26691) This makes yarn_install of ngdeps under Bazel faster, since we don't need many of the large dependencies. It's important because downstream angular/bazel users will observe the same install time. PR Close #26691
2018-10-22 17:26:52 -04:00
"fs-extra": "4.0.2",
build: switch playground examples to bazel (#28490) Currently all playground examples are built with `tsc` and served with the `gulp serve` task. In order to be able to test these examples easily with Ivy, we now build and serve the examples using Bazel. This allows us to expand our Ivy test coverage and additionally it allows us to move forward with the overall Bazel migration. Building & serving individual examples is now very easy and doesn't involve building everything inside of `/modules`. PR Close #28490
2019-02-01 08:27:13 -05:00
"hammerjs": "2.0.8",
build: update to rules_nodejs 0.38 (#32889) PR Close #32889
2019-09-27 18:49:59 -04:00
"http-server": "^0.11.1",
build: serve benchmark tree examples with bazel (#28568) PR Close #28568
2019-02-06 12:02:07 -05:00
"incremental-dom": "0.4.1",
build: update jasmine to 3.5 (#34625) 1. update jasmine to 3.5 2. update @types/jasmine to 3.5 3. update @types/jasminewd2 to 2.0.8 Also fix several cases, the new jasmine 3 will help to create test cases correctly, such as in the `jasmine 2.x` version, the following case will pass ``` expect(1 == 2); ``` But in jsamine 3, the case will need to be ``` expect(1 == 2).toBeTrue(); ``` PR Close #34625
2020-01-03 00:28:06 -05:00
"jasmine": "^3.5.0",
"jasmine-core": "^3.5.0",
build: update jquery to latest (#28719) Versions less than 3.0.0 have security vulnerabilities PR Close #28719
2019-02-13 19:09:00 -05:00
"jquery": "3.0.0",
build: update to nodejs rules 0.41.0 (#33996) This bring is changes to the @nodejs repository required for https://github.com/angular/angular/pull/33927. See release notes for more details: https://github.com/bazelbuild/rules_nodejs/releases/tag/0.41.0. rules_nodejs is approaching 1.0 and breaking changes for that release are being made more frequently. In this release, the ts_devserver API changed and it no longer injects html script tags into a provided index.html file. The diff on this commit is large as this breaking change affects quite a few tests. Also note that we don’t update @angular/bazel schematics and integration/bazel as 0.41.0 is not a recommended update for angular users yet due to the breaking changes in ts_devserver & web_package (now named pkg_web). When a suitable plain npm package that is in progress is finished then it will be possible to easily replace the html injection functionality removed from ts_devserver & pkg_web. PR Close #33996
2019-11-22 16:12:05 -05:00
"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",
build: rebuild yarn lock from scratch (#36377) Rebuild the yarn lock file from scratch to collapse instances where one package is able to satisfy multiple dependencies. Currently we have some situations where we have multiple versions when one would work. Example: ``` "@babel/code-frame@^7.0.0": version "7.0.0" resolved "https://registry.yarnpkg.com/@babel/cod integrity sha512-OfC2uemaknXr87bdLUkWog7nYuliM9Ij dependencies: "@babel/highlight" "^7.0.0" "@babel/code-frame@^7.5.5": version "7.5.5" resolved "https://registry.yarnpkg.com/@babel/cod integrity sha512-27d4lZoomVyo51VegxI20xZPuSHusqbQ dependencies: "@babel/highlight" "^7.0.0" "@babel/code-frame@^7.8.3": version "7.8.3" resolved "https://registry.yarnpkg.com/@babel/cod integrity sha512-a9gxpmdXtZEInkCSHUJDLHZVBgb1QS0j dependencies: "@babel/highlight" "^7.8.3" ``` becomes ``` "@babel/code-frame@^7.0.0", "@babel/code-frame@^7.5.5", "@babel/code-frame@^7.8.3": version "7.8.3" resolved "https://registry.yarnpkg.com/@babel/cod integrity sha512-a9gxpmdXtZEInkCSHUJDLHZVBgb1QS0j dependencies: "@babel/highlight" "^7.8.3" ``` PR Close #36377
2020-03-24 13:20:28 -04:00
"magic-string": "0.25.4",
build: fix web_worker playground examples using external resources (#28562) The `web_workers/images` example is not being tested by any e2e spec and therefore it's technically not necessary to fix that it uses external resources, though in order to ensure that the Bazel builds are hermetic and that we can eventually add e2e specs for the web_worker/image example, we should avoid any use of external resources. We remove the `web-animations` polyfill in the `web_workers/animations` example because we should try to vendor as few as possible deps. Also the animations API is already supported by browsers we run the e2e tests against (note here: `web_workers/animations` is currently also disabled) PR Close #28562
2019-02-06 06:33:17 -05:00
"materialize-css": "1.0.0",
ci: add verification of the pullapprove config (#35060) Verify that all files in the repo are covered by the pullapprove config and that all rules in the pullapprove config match at least one file in the repo. PR Close #35060
2020-01-30 11:05:40 -05:00
"minimatch": "^3.0.4",
build: Move non-bazel deps to devDependencies (#26691) This makes yarn_install of ngdeps under Bazel faster, since we don't need many of the large dependencies. It's important because downstream angular/bazel users will observe the same install time. PR Close #26691
2018-10-22 17:26:52 -04:00
"minimist": "1.2.0",
"node-uuid": "1.4.8",
build: move zone.js to angular repo (#30962) PR Close #30962
2019-05-31 11:56:07 -04:00
"nodejs-websocket": "^1.7.2",
ci: move e2e tests from travis to circleci (#27937) PR Close #27937
2019-01-05 08:01:47 -05:00
"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",
build: Move non-bazel deps to devDependencies (#26691) This makes yarn_install of ngdeps under Bazel faster, since we don't need many of the large dependencies. It's important because downstream angular/bazel users will observe the same install time. PR Close #26691
2018-10-22 17:26:52 -04:00
"reflect-metadata": "^0.1.3",
build: update to nodejs rules 0.41.0 (#33996) This bring is changes to the @nodejs repository required for https://github.com/angular/angular/pull/33927. See release notes for more details: https://github.com/bazelbuild/rules_nodejs/releases/tag/0.41.0. rules_nodejs is approaching 1.0 and breaking changes for that release are being made more frequently. In this release, the ts_devserver API changed and it no longer injects html script tags into a provided index.html file. The diff on this commit is large as this breaking change affects quite a few tests. Also note that we don’t update @angular/bazel schematics and integration/bazel as 0.41.0 is not a recommended update for angular users yet due to the breaking changes in ts_devserver & web_package (now named pkg_web). When a suitable plain npm package that is in progress is finished then it will be possible to easily replace the html injection functionality removed from ts_devserver & pkg_web. PR Close #33996
2019-11-22 16:12:05 -05:00
"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",
build(bazel): Use local rollup & build-optimizer for ng_rollup_bundle (#28215) The current build workflow depends on cross workspace dependency by installing angular-cli as a Bazel repository. This is not ideal because it introduces separate node_module directories other than the one installed by Angular through the yarn_install rule (ngdeps). This commit removes angular-cli from the Bazel workspace and installs rollup and @angular-devkit/build-optimizer locally. PR Close #28215
2019-01-17 15:40:11 -05:00
"rollup-plugin-sourcemaps": "^0.4.2",
build: update rxjs to 6.5.3 (#32812) PR Close #32812
2019-09-23 04:44:21 -04:00
"rxjs": "^6.5.3",
build: Move non-bazel deps to devDependencies (#26691) This makes yarn_install of ngdeps under Bazel faster, since we don't need many of the large dependencies. It's important because downstream angular/bazel users will observe the same install time. PR Close #26691
2018-10-22 17:26:52 -04:00
"selenium-webdriver": "3.5.0",
build: fix build scripts on macOS (#33854) In #33823, `scripts/package-builds.sh` (which is used by both `build-packages-dist.sh` and `build-ivy-npm-packages.sh`) was updated to use `realpath`. It turns out that `realpath` does not exist on macOS, so the build scripts do not work there. In order to fix this (and also reduce the likelihood of introducing similar issues in the future), this commit changes these bash scripts to Node.js scripts (using [ShellJS](https://github.com/shelljs/shelljs) for a cross-platform implementation of Unix shell commands where necessary). PR Close #33854
2019-11-14 19:56:55 -05:00
"shelljs": "^0.8.3",
build: Move non-bazel deps to devDependencies (#26691) This makes yarn_install of ngdeps under Bazel faster, since we don't need many of the large dependencies. It's important because downstream angular/bazel users will observe the same install time. PR Close #26691
2018-10-22 17:26:52 -04:00
"source-map": "^0.6.1",
build: update source-map-support to get rid of Node's DeprecationWarning (#27538) Removes the following when bazel runs any of our jasmine_node_tests: (node:85494) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead. I was able to find the source of the warning by running the target with the following tags: ``` bazel test packages/language-service/... --test_arg=--node_options=--throw-deprecation ``` PR Close #27538
2018-12-07 03:20:32 -05:00
"source-map-support": "0.5.9",
feat(ngcc): implement source-map flattening (#35132) The library used by ngcc to update the source files (MagicString) is able to generate a source-map but it is not able to account for any previous source-map that the input text is already associated with. There have been various attempts to fix this but none have been very successful, since it is not a trivial problem to solve. This commit contains a novel approach that is able to load up a tree of source-files connected by source-maps and flatten them down into a single source-map that maps directly from the final generated file to the original sources referenced by the intermediate source-maps. PR Close #35132
2020-02-16 15:07:30 -05:00
"sourcemap-codec": "^1.4.8",
build: switch playground examples to bazel (#28490) Currently all playground examples are built with `tsc` and served with the `gulp serve` task. In order to be able to test these examples easily with Ivy, we now build and serve the examples using Bazel. This allows us to expand our Ivy test coverage and additionally it allows us to move forward with the overall Bazel migration. Building & serving individual examples is now very easy and doesn't involve building everything inside of `/modules`. PR Close #28490
2019-02-01 08:27:13 -05:00
"systemjs": "0.18.10",
build: update to terser 4.4.0 (#33835) Now that terser_minified supports args as of nodejs rules 0.40.0, ng_rollup_bundle can updated to the pass —comments /a^/ to args can turn off all comments and maintain the current ng_rollup_bundle behavior with the latest version fo terser. //packages/core/test/bundling/todo:bundle.min.js size test passes with this fix. Tho not strictly necessary to update terser, this will be a rough edge when someone does try it as it is not obvious why the //packages/core/test/bundling/todo:bundle.min.js size test fails. Updating now should save time in the future by not hitting this issue.\ This change also affect ng_package output as the default comments that are preserved by terser are now Comments with @preserve, @license, @cc_on as well as comments starting with /*! and /**! are now preserved by default.. (https://github.com/terser/terser/blob/master/CHANGELOG.md). Example ng_package golden file also updated as there are not some /*! comments preserved that were in older versions of terser. PR Close #33835
2019-11-14 16:08:40 -05:00
"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",
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": "^1.10.0",
build: update tslint to latest version (#35800) The old version we currently use does not properly implement the option to exclude files from within the `tslint.json` file. PR Close #35800
2020-03-02 13:00:50 -05:00
"tslint": "6.0.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
"typescript": "~3.8.3",
fix(platform-server): update `xhr2` dependency (#36366) Previous versions of xhr2 used the depreciated "new Buffer()". Closes #36358 PR Close #36366
2020-04-01 07:35:30 -04:00
"xhr2": "0.2.0",
ci: add verification of the pullapprove config (#35060) Verify that all files in the repo are covered by the pullapprove config and that all rules in the pullapprove config match at least one file in the repo. PR Close #35060
2020-01-30 11:05:40 -05:00
"yaml": "^1.7.2",
build: update yargs to 15.3.0 (#36010) This is needed as we require the following fix https://github.com/yargs/yargs/issues/1325 PR Close #36010
2020-03-11 06:18:58 -04:00
"yargs": "15.3.0"
build: Move non-bazel deps to devDependencies (#26691) This makes yarn_install of ngdeps under Bazel faster, since we don't need many of the large dependencies. It's important because downstream angular/bazel users will observe the same install time. PR Close #26691
2018-10-22 17:26:52 -04:00
},
"// 2": "devDependencies are not used under Bazel. Many can be removed after test.sh is deleted.",
"devDependencies": {
build: update cli packages to latest versions (#35608) PR Close #35608
2020-02-21 04:09:15 -05:00
"@angular/cli": "9.0.3",
build: depend on bazelisk rather than directly on Bazel (#36078) This has a couple benefits: - we now use a .bazelversion file rather than package.json to pin the version of bazel we want. This means even if you install bazel on your computer rather than via yarn, you'll still get a warning if your bazel version is wrong. - you no longer end up downloading three copies of bazel due to bugs in both npm and yarn where they download all tarballs before checking the metadata to see which are usable on the local platform. - bazelisk correctly handles the tools/bazel trick for wrapping functionality, which we want to use to instrument developer build latencies PR Close #36078
2020-02-04 19:14:21 -05:00
"@bazel/bazelisk": "^1.3.0",
build: update to @bazel/buildifier@0.29.0 (#33866) the previously used version was incompatible with the bazel vscode extension. PR Close #33866
2019-11-15 23:34:49 -05:00
"@bazel/buildifier": "^0.29.0",
build: update to latest `@bazel/ibazel` version (#36097) Updates to the latest `@bazel/ibazel` version that properly resolves local `@bazel/bazelisk` installations. The support for this temporarily broke from `0.12.0` to `0.12.2`. https://github.com/bazelbuild/bazel-watcher/issues/352. PR Close #36097
2020-03-17 06:40:12 -04:00
"@bazel/ibazel": "^0.12.3",
build: creates a script to get contributor stats from across the angular org (#35834) This script gets all of the current users for the organization and retrieves information about PR/Issue contributions/authorship since a provided date. Returning this information as a CSV. PR Close #35834
2020-03-03 13:16:18 -05:00
"@octokit/graphql": "^4.3.1",
feat(dev-infra): create common config file loading util (#36091) Create a common config file loading utility function and the necessary util directory. This util directory can provide common utility functions for usage inside of the dev-infra package. PR Close #36091
2020-03-16 14:31:24 -04:00
"@types/json5": "^0.0.30",
build: Move non-bazel deps to devDependencies (#26691) This makes yarn_install of ngdeps under Bazel faster, since we don't need many of the large dependencies. It's important because downstream angular/bazel users will observe the same install time. PR Close #26691
2018-10-22 17:26:52 -04:00
"@types/minimist": "^1.2.0",
ci: check versions of non-local integration project dependencies (#33968) In order to keep integration tests on CI as determinitstic as possible, we need to ensure that the same dependencies (including transitive ones) are installed each time. One way to ensure that is using a lockfile (such as `yarn.lock`) to pin the dependencies to exact versions. This works as long as the lockfile itself is in-sync with the corresponding `package.json`, which specifies the dependencies. Ideally, we would run `yarn install` with the `--frozen-lockfile` option to verify that the lockfile is in-sync with `package.json`, but we cannot do that for integration projects, because we want to be able to install the locally built Angular packages). Therefore, we must manually esnure that the integration project lockfiles remain in-sync, which is error-prone. This commit introduces a helper script that performs some checks on each project's (non-local) dependencies: - Ensure that exact versions (not version ranges) are specified in `package.json`. This reduces the probability of installing a breaking version of a direct or transitive dependency, in case of an out-of-sync lockfile. - Ensure that the lockfile is in-sync with `package.json` wrt these dependencies. While these checks are not full-proof, they provide yet another line of defense against indeterminism. PR Close #33968
2019-11-25 10:48:18 -05:00
"@yarnpkg/lockfile": "^1.1.0",
build: Move non-bazel deps to devDependencies (#26691) This makes yarn_install of ngdeps under Bazel faster, since we don't need many of the large dependencies. It's important because downstream angular/bazel users will observe the same install time. PR Close #26691
2018-10-22 17:26:52 -04:00
"browserstacktunnel-wrapper": "2.0.1",
test: update side-effects test to be more descriptive (#31005) This test will now list diffs for failed expectations and the full command to update them. Fix #30570 PR Close #31005
2019-06-12 11:11:14 -04:00
"check-side-effects": "0.0.21",
build: update to clang 1.4.0 and only run clang format on changed files (#36203) Update to clang@1.4.0 to gain support for optional changing and nullish coalescing. Because this would trigger a change on >1800 files in the repository, also changes our format enforcement to only be run against changed files. This will allow us to incramentally roll out the value add of the upgraded clang format. PR Close #36203
2020-03-23 11:53:42 -04:00
"clang-format": "^1.4.0",
fix(common): use correct ICU plural for locale mk (#24659) PR Close #24659
2018-06-25 11:17:56 -04:00
"cldr": "4.10.0",
build: update cldr-data package to 36.0.0 (#33584) PR Close #33584
2019-11-07 12:56:39 -05:00
"cldr-data": "36.0.0",
build: switch from npm to yarn (#19328) PR Close #19328
2017-09-21 09:39:43 -04:00
"cldrjs": "0.5.0",
build: update `conventional-changelog` and simplify `changelog` gulp task (#25838) The version prefix issue has been fixed with conventional-changelog/conventional-changelog#179. PR Close #25838
2018-09-06 04:36:27 -04:00
"conventional-changelog": "^2.0.3",
build: switch from npm to yarn (#19328) PR Close #19328
2017-09-21 09:39:43 -04:00
"entities": "1.1.1",
build: update `firebase-tools` to the latest version (#34682) This fixes `Server Error. certificate has expired` errors that cause AIO deployment to fail. (Example CI failure: https://circleci.com/gh/angular/angular/578227) PR Close #34682
2020-01-08 15:26:59 -05:00
"firebase-tools": "^7.11.0",
build: update npm dependencies (#19328) PR Close #19328
2017-09-22 13:51:03 -04:00
"firefox-profile": "1.0.3",
"glob": "7.1.2",
build: switch from npm to yarn (#19328) PR Close #19328
2017-09-21 09:39:43 -04:00
"gulp": "3.9.1",
build: update to clang 1.4.0 and only run clang format on changed files (#36203) Update to clang@1.4.0 to gain support for optional changing and nullish coalescing. Because this would trigger a change on >1800 files in the repository, also changes our format enforcement to only be run against changed files. This will allow us to incramentally roll out the value add of the upgraded clang format. PR Close #36203
2020-03-23 11:53:42 -04:00
"gulp-clang-format": "^1.0.27",
style: update gulp task to format untracked and diff files separately (#24969) PR Close #24969
2018-09-10 21:19:14 -04:00
"gulp-conventional-changelog": "^2.0.3",
style: add gulp task to only format changed files (#24969) Closes #24904 PR Close #24969
2018-07-18 12:09:55 -04:00
"gulp-filter": "^5.1.0",
"gulp-git": "^2.7.0",
build: update npm dependencies (#19328) PR Close #19328
2017-09-22 13:51:03 -04:00
"gulp-tslint": "8.1.2",
build: update to latest version of husky (#36459) PR Close #36459
2020-04-06 16:21:00 -04:00
"husky": "^4.2.3",
build: update npm dependencies (#19328) PR Close #19328
2017-09-22 13:51:03 -04:00
"jpm": "1.3.1",
feat(dev-infra): create common config file loading util (#36091) Create a common config file loading utility function and the necessary util directory. This util directory can provide common utility functions for usage inside of the dev-infra package. PR Close #36091
2020-03-16 14:31:24 -04:00
"json5": "^2.1.2",
build: update to nodejs rules 0.41.0 (#33996) This bring is changes to the @nodejs repository required for https://github.com/angular/angular/pull/33927. See release notes for more details: https://github.com/bazelbuild/rules_nodejs/releases/tag/0.41.0. rules_nodejs is approaching 1.0 and breaking changes for that release are being made more frequently. In this release, the ts_devserver API changed and it no longer injects html script tags into a provided index.html file. The diff on this commit is large as this breaking change affects quite a few tests. Also note that we don’t update @angular/bazel schematics and integration/bazel as 0.41.0 is not a recommended update for angular users yet due to the breaking changes in ts_devserver & web_package (now named pkg_web). When a suitable plain npm package that is in progress is finished then it will be possible to easily replace the html injection functionality removed from ts_devserver & pkg_web. PR Close #33996
2019-11-22 16:12:05 -05:00
"karma-browserstack-launcher": "^1.3.0",
build: update to latest karma-sauce-launcher version (#27634) PR Close #27634
2018-12-12 17:07:21 -05:00
"karma-sauce-launcher": "^2.0.2",
build: create bazel marco to test for circular dependencies (#34774) Creates a Bazel macro that can be used to test packages for circular dependencies. We face one limitation with Bazel: * Built packages use module imports, and not relative source file paths. This means we need custom resolution. Fortunately, tools like `madge` support custom resolution. Also removes the outdated `check-cycles` gulp task that didn't catch circular dependencies. It seems like the test became broken when we switched the packages-dist output to Bazel. It breaks because the Bazel output doesn't use relative paths, but uses the module imports. This will be handled in the new Bazel macro/rule. PR Close #34774
2020-01-14 09:15:01 -05:00
"madge": "^3.6.0",
feat(elements): add support for creating custom elements (#22413) PR Close #22413
2018-02-28 12:45:11 -05:00
"mutation-observer": "^1.0.3",
build: switch from npm to yarn (#19328) PR Close #19328
2017-09-21 09:39:43 -04:00
"rewire": "2.5.2",
ci: downgrade to sauce-connect v4.5.1 (#28659) We currently face a lot of flakiness with our Saucelabs CI jobs. These randomly exceed the 10min CircleCI no-output limit because something throws off `sauce-connect` in a long-lasting loop where it tries to connect to some of their Saucelabs servers. The initial assumption from the Saucelabs team was that we might have some invalid firewall rules, but this does not answer why this happens _randomly_, so the latest update from the support is that there have been some changes in the latest version of `sauce-connect` version that **could** cause this flakiness. I've manually did multiple test runs and was only able to reproduce the issues with v4.5.3 (latest version), so it might be worth downgrading to v4.5.1. This is also what the Saucelabs support proposed us to do (though it's not guaranteed that v4.5.1 is unaffected by the same issue) PR Close #28659
2019-02-12 12:36:28 -05:00
"sauce-connect": "https://saucelabs.com/downloads/sc-4.5.1-linux.tar.gz",
feat(ngcc): support version ranges in project/default configurations (#33008) By appending a version range to the package name, it is now possible to target configuration to specific versions of a package. PR Close #33008
2019-10-04 06:54:33 -04:00
"semver": "^6.3.0",
build: creates a script to get contributor stats from across the angular org (#35834) This script gets all of the current users for the organization and retrieves information about PR/Issue contributions/authorship since a provided date. Returning this information as a CSV. PR Close #35834
2020-03-03 13:16:18 -05:00
"ts-node": "^8.6.2",
build: update tslint to latest version (#35800) The old version we currently use does not properly implement the option to exclude files from within the `tslint.json` file. PR Close #35800
2020-03-02 13:00:50 -05:00
"tslint-eslint-rules": "5.4.0",
refactor: remove toplevel property accesses (#29329) PR Close #29329
2019-05-02 11:44:24 -04:00
"tslint-no-toplevel-property-access": "0.0.2",
build(bazel): use fine-grained npm deps (#26111) (#26488) PR Close #26488
2018-10-04 16:14:14 -04:00
"tsutils": "2.27.2",
build: creates a script to get contributor stats from across the angular org (#35834) This script gets all of the current users for the organization and retrieves information about PR/Issue contributions/authorship since a provided date. Returning this information as a CSV. PR Close #35834
2020-03-03 13:16:18 -05:00
"typed-graphqlify": "^2.3.0",
build: update npm dependencies (#19328) PR Close #19328
2017-09-22 13:51:03 -04:00
"universal-analytics": "0.4.15",
build: switch from npm to yarn (#19328) PR Close #19328
2017-09-21 09:39:43 -04:00
"vlq": "0.2.2",
build: remove unused webpack npm dependency (#34366) We no longer need it. PR Close #34366
2019-12-12 03:53:13 -05:00
"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
},
build: fix gulp setup not working with node v12 (#33348) It looks like the gulp setup does not work with NodeJS v12. This is because we still use gulp for a few tasks, but gulp v3 is not compatible with NodeJS v12. We had a similar issue for NodeJS v12, but worked around it by updating the `natives` module version. To actually solve this in a more future-proof way, without updating or removing Gulp (for now), we just overwrite the `graceful-fs` version. The latest version of `graceful-fs` does no longer depend on the `natives` package and therefore works properly with NodeJS >= v10. PR Close #33348
2019-10-23 06:49:49 -04: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"
fix: use full cldr data to support all locales (#33682) switching to cldr-data package resulted in loss of some locales, since by default only core locales are loaded. This PR adds a flag to tell cldr-data to use full locale coverage fixes: #33681 PR Close #33682
2019-11-08 03:52:39 -05:00
},
build: update to latest version of husky (#36459) PR Close #36459
2020-04-06 16:21:00 -04:00
"cldr-data-coverage": "full",
"husky": {
"hooks": {
fix(dev-infra): fix commit message validation in git worktrees (#36507) Previously, the `pre-commit-validate` command (used in the `commit-msg` git hook) assumed that the commit message was stored in `.git/COMMIT_EDITMSG` file. This is usually true, but not when using [git worktrees](https://git-scm.com/docs/git-worktree), where `.git` is a file containing the path to the actual git directory. This commit fixes it by taking advantage of the fact that git passes the actual path of the file holding the commit message to the `commit-msg` hook and husky exposes the arguments passed by git as `$HUSKY_GIT_PARAMS`. NOTE: We cannot use the environment variable directly in the `commit-msg` hook command, because environment variables need to be referenced differently on Windows (`%VAR_NAME%`) vs macOS/Linux (`$VAR_NAME`). Instead, we pass the name of the environment variable and the validation script reads the variable's value off of `process.env`. PR Close #36507
2020-04-08 16:56:05 -04:00
"commit-msg": "yarn -s ng-dev commit-message pre-commit-validate --file-env-variable HUSKY_GIT_PARAMS"
build: update to latest version of husky (#36459) PR Close #36459
2020-04-06 16:21:00 -04:00
}
}
release: cut the v9.0.0-next.9 release
2019-10-02 14:43:00 -04:00
}