honeymoose/angular-cn
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
angular-cn/integration/language_service_plugin/yarn.lock

99 lines
3.4 KiB
Plaintext
Raw Normal View History

ci: Add back the CLI integration test with pinning (#21555) The CLI app is now checked in, rather than generated dynamically with `ng new`. This loses some assertion power, but gains hermeticity. It also checks in lock files for all integration tests, avoiding floating version numbers. We'll need another place to integration test between changes in the various repositories - but the angular/angular PR-blocking status is not the right place to do this. PR Close #21555
2018-01-16 07:09:59 -08:00
# THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY.
# yarn lockfile v1
"@angular/core@file:../../dist/packages-dist/core":
build: update lockfiles for integration projects (#33968) In the `integration_test` CircleCI job, we run `yarn install` on all projects in the `integration/` directory. If a project has no lockfile or if the lockfile is out-of-sync with the corresponding `package.json` file, then the installed dependency versions are no longer pinned, which can result in different versions being installed between different runs of the same job (if, for example, a new version is released for a package) and breaks hermeticity. This could be prevented by using the `--frozen-lockfile` option with `yarn install`, but this is not possible with the current setup, because yarn needs to be able to install the locally built Angular packages, whose checksums will be different from the ones in the lockfile. Therefore, we have to manually ensure that the lockfiles remain in-sync with the corresponding `package.json` files for the rest of the dependencies. For example, previously, [cli-hello-world-lazy/yarn.lock][1] had an entry for `@angular-devkit/build-angular@0.900.0-next.9` (pinned to `0.900.0-next.9`), but [cli-hello-world-lazy/package.json][2] specified the `@angular-devkit/build-angular` version as `^0.900.0-rc.0` (note the leading caret). As a result, since the version in the lock file does not much the one in `package.json`, the lockfile is ignored and the latest available version that matches `^0.900.0-rc.0` is installed. This, for example, started causing unrelated CI failures ([example][3]), when `@angular-devkit/build-angular@9.0.0-rc.3` was released with a size improvement. This commit ensures that all integration projects have a lockfile and that lockfiles are up-to-date (with the current `package.json` files). [1]: https://github.com/angular/angular/blob/fc2f6b845/integration/cli-hello-world-lazy/yarn.lock#L13 [2]: https://github.com/angular/angular/blob/fc2f6b845/integration/cli-hello-world-lazy/package.json#L26 [3]: https://circleci.com/gh/angular/angular/535959#tests/containers/2 PR Close #33968
2019-11-21 21:09:33 +02:00
version "9.0.0-rc.1"
ci: Add back the CLI integration test with pinning (#21555) The CLI app is now checked in, rather than generated dynamically with `ng new`. This loses some assertion power, but gains hermeticity. It also checks in lock files for all integration tests, avoiding floating version numbers. We'll need another place to integration test between changes in the various repositories - but the angular/angular PR-blocking status is not the right place to do this. PR Close #21555
2018-01-16 07:09:59 -08:00
"@angular/language-service@file:../../dist/packages-dist/language-service":
build: update lockfiles for integration projects (#33968) In the `integration_test` CircleCI job, we run `yarn install` on all projects in the `integration/` directory. If a project has no lockfile or if the lockfile is out-of-sync with the corresponding `package.json` file, then the installed dependency versions are no longer pinned, which can result in different versions being installed between different runs of the same job (if, for example, a new version is released for a package) and breaks hermeticity. This could be prevented by using the `--frozen-lockfile` option with `yarn install`, but this is not possible with the current setup, because yarn needs to be able to install the locally built Angular packages, whose checksums will be different from the ones in the lockfile. Therefore, we have to manually ensure that the lockfiles remain in-sync with the corresponding `package.json` files for the rest of the dependencies. For example, previously, [cli-hello-world-lazy/yarn.lock][1] had an entry for `@angular-devkit/build-angular@0.900.0-next.9` (pinned to `0.900.0-next.9`), but [cli-hello-world-lazy/package.json][2] specified the `@angular-devkit/build-angular` version as `^0.900.0-rc.0` (note the leading caret). As a result, since the version in the lock file does not much the one in `package.json`, the lockfile is ignored and the latest available version that matches `^0.900.0-rc.0` is installed. This, for example, started causing unrelated CI failures ([example][3]), when `@angular-devkit/build-angular@9.0.0-rc.3` was released with a size improvement. This commit ensures that all integration projects have a lockfile and that lockfiles are up-to-date (with the current `package.json` files). [1]: https://github.com/angular/angular/blob/fc2f6b845/integration/cli-hello-world-lazy/yarn.lock#L13 [2]: https://github.com/angular/angular/blob/fc2f6b845/integration/cli-hello-world-lazy/package.json#L26 [3]: https://circleci.com/gh/angular/angular/535959#tests/containers/2 PR Close #33968
2019-11-21 21:09:33 +02:00
version "9.0.0-rc.1"
ci: Add back the CLI integration test with pinning (#21555) The CLI app is now checked in, rather than generated dynamically with `ng new`. This loses some assertion power, but gains hermeticity. It also checks in lock files for all integration tests, avoiding floating version numbers. We'll need another place to integration test between changes in the various repositories - but the angular/angular PR-blocking status is not the right place to do this. PR Close #21555
2018-01-16 07:09:59 -08:00
test(language-service): Improve integration test (#28168) The current integration test for language service involves piping the results of one process to another using Unix pipes. This makes the test hard to debug, and hard to configure. This commit refactors the integration test to use regular Jasmine scaffolding. More importantly, it tests the way the language service will actually be installed by end users. Users would not have to add `@angular/language-service` to the plugins section in tsconfig.json Instead, all they need to do is install the *extension* from the VS Code Marketplace and Angular Language Service will be loaded as a global plugin. PR Close #28168
2018-12-17 23:44:26 -08:00
"@types/node@file:../../node_modules/@types/node":
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 16:44:50 -07:00
version "12.11.1"
ci: Add back the CLI integration test with pinning (#21555) The CLI app is now checked in, rather than generated dynamically with `ng new`. This loses some assertion power, but gains hermeticity. It also checks in lock files for all integration tests, avoiding floating version numbers. We'll need another place to integration test between changes in the various repositories - but the angular/angular PR-blocking status is not the right place to do this. PR Close #21555
2018-01-16 07:09:59 -08:00
balanced-match@^1.0.0:
version "1.0.0"
resolved "https://registry.yarnpkg.com/balanced-match/-/balanced-match-1.0.0.tgz#89b4d199ab2bee49de164ea02b89ce462d71b767"
test(language-service): Improve integration test (#28168) The current integration test for language service involves piping the results of one process to another using Unix pipes. This makes the test hard to debug, and hard to configure. This commit refactors the integration test to use regular Jasmine scaffolding. More importantly, it tests the way the language service will actually be installed by end users. Users would not have to add `@angular/language-service` to the plugins section in tsconfig.json Instead, all they need to do is install the *extension* from the VS Code Marketplace and Angular Language Service will be loaded as a global plugin. PR Close #28168
2018-12-17 23:44:26 -08:00
integrity sha1-ibTRmasr7kneFk6gK4nORi1xt2c=
ci: Add back the CLI integration test with pinning (#21555) The CLI app is now checked in, rather than generated dynamically with `ng new`. This loses some assertion power, but gains hermeticity. It also checks in lock files for all integration tests, avoiding floating version numbers. We'll need another place to integration test between changes in the various repositories - but the angular/angular PR-blocking status is not the right place to do this. PR Close #21555
2018-01-16 07:09:59 -08:00
brace-expansion@^1.1.7:
test(language-service): Improve integration test (#28168) The current integration test for language service involves piping the results of one process to another using Unix pipes. This makes the test hard to debug, and hard to configure. This commit refactors the integration test to use regular Jasmine scaffolding. More importantly, it tests the way the language service will actually be installed by end users. Users would not have to add `@angular/language-service` to the plugins section in tsconfig.json Instead, all they need to do is install the *extension* from the VS Code Marketplace and Angular Language Service will be loaded as a global plugin. PR Close #28168
2018-12-17 23:44:26 -08:00
version "1.1.11"
resolved "https://registry.yarnpkg.com/brace-expansion/-/brace-expansion-1.1.11.tgz#3c7fcbf529d87226f3d2f52b966ff5271eb441dd"
integrity sha512-iCuPHDFgrHX7H2vEI/5xpz07zSHB00TpugqhmYtVmMO6518mCuRMoOYFldEBl0g187ufozdaHgWKcYFb61qGiA==
ci: Add back the CLI integration test with pinning (#21555) The CLI app is now checked in, rather than generated dynamically with `ng new`. This loses some assertion power, but gains hermeticity. It also checks in lock files for all integration tests, avoiding floating version numbers. We'll need another place to integration test between changes in the various repositories - but the angular/angular PR-blocking status is not the right place to do this. PR Close #21555
2018-01-16 07:09:59 -08:00
dependencies:
balanced-match "^1.0.0"
concat-map "0.0.1"
concat-map@0.0.1:
version "0.0.1"
resolved "https://registry.yarnpkg.com/concat-map/-/concat-map-0.0.1.tgz#d8a96bd77fd68df7793a73036a3ba0d5405d477b"
test(language-service): Improve integration test (#28168) The current integration test for language service involves piping the results of one process to another using Unix pipes. This makes the test hard to debug, and hard to configure. This commit refactors the integration test to use regular Jasmine scaffolding. More importantly, it tests the way the language service will actually be installed by end users. Users would not have to add `@angular/language-service` to the plugins section in tsconfig.json Instead, all they need to do is install the *extension* from the VS Code Marketplace and Angular Language Service will be loaded as a global plugin. PR Close #28168
2018-12-17 23:44:26 -08:00
integrity sha1-2Klr13/Wjfd5OnMDajug1UBdR3s=
ci: Add back the CLI integration test with pinning (#21555) The CLI app is now checked in, rather than generated dynamically with `ng new`. This loses some assertion power, but gains hermeticity. It also checks in lock files for all integration tests, avoiding floating version numbers. We'll need another place to integration test between changes in the various repositories - but the angular/angular PR-blocking status is not the right place to do this. PR Close #21555
2018-01-16 07:09:59 -08:00
fs.realpath@^1.0.0:
version "1.0.0"
resolved "https://registry.yarnpkg.com/fs.realpath/-/fs.realpath-1.0.0.tgz#1504ad2523158caa40db4a2787cb01411994ea4f"
test(language-service): Improve integration test (#28168) The current integration test for language service involves piping the results of one process to another using Unix pipes. This makes the test hard to debug, and hard to configure. This commit refactors the integration test to use regular Jasmine scaffolding. More importantly, it tests the way the language service will actually be installed by end users. Users would not have to add `@angular/language-service` to the plugins section in tsconfig.json Instead, all they need to do is install the *extension* from the VS Code Marketplace and Angular Language Service will be loaded as a global plugin. PR Close #28168
2018-12-17 23:44:26 -08:00
integrity sha1-FQStJSMVjKpA20onh8sBQRmU6k8=
ci: Add back the CLI integration test with pinning (#21555) The CLI app is now checked in, rather than generated dynamically with `ng new`. This loses some assertion power, but gains hermeticity. It also checks in lock files for all integration tests, avoiding floating version numbers. We'll need another place to integration test between changes in the various repositories - but the angular/angular PR-blocking status is not the right place to do this. PR Close #21555
2018-01-16 07:09:59 -08:00
test(language-service): Improve integration test (#28168) The current integration test for language service involves piping the results of one process to another using Unix pipes. This makes the test hard to debug, and hard to configure. This commit refactors the integration test to use regular Jasmine scaffolding. More importantly, it tests the way the language service will actually be installed by end users. Users would not have to add `@angular/language-service` to the plugins section in tsconfig.json Instead, all they need to do is install the *extension* from the VS Code Marketplace and Angular Language Service will be loaded as a global plugin. PR Close #28168
2018-12-17 23:44:26 -08:00
glob@^7.0.6:
version "7.1.3"
resolved "https://registry.yarnpkg.com/glob/-/glob-7.1.3.tgz#3960832d3f1574108342dafd3a67b332c0969df1"
integrity sha512-vcfuiIxogLV4DlGBHIUOwI0IbrJ8HWPc4MU7HzviGeNho/UJDfi6B5p3sHeWIQ0KGIU0Jpxi5ZHxemQfLkkAwQ==
ci: Add back the CLI integration test with pinning (#21555) The CLI app is now checked in, rather than generated dynamically with `ng new`. This loses some assertion power, but gains hermeticity. It also checks in lock files for all integration tests, avoiding floating version numbers. We'll need another place to integration test between changes in the various repositories - but the angular/angular PR-blocking status is not the right place to do this. PR Close #21555
2018-01-16 07:09:59 -08:00
dependencies:
fs.realpath "^1.0.0"
inflight "^1.0.4"
inherits "2"
minimatch "^3.0.4"
once "^1.3.0"
path-is-absolute "^1.0.0"
inflight@^1.0.4:
version "1.0.6"
resolved "https://registry.yarnpkg.com/inflight/-/inflight-1.0.6.tgz#49bd6331d7d02d0c09bc910a1075ba8165b56df9"
test(language-service): Improve integration test (#28168) The current integration test for language service involves piping the results of one process to another using Unix pipes. This makes the test hard to debug, and hard to configure. This commit refactors the integration test to use regular Jasmine scaffolding. More importantly, it tests the way the language service will actually be installed by end users. Users would not have to add `@angular/language-service` to the plugins section in tsconfig.json Instead, all they need to do is install the *extension* from the VS Code Marketplace and Angular Language Service will be loaded as a global plugin. PR Close #28168
2018-12-17 23:44:26 -08:00
integrity sha1-Sb1jMdfQLQwJvJEKEHW6gWW1bfk=
ci: Add back the CLI integration test with pinning (#21555) The CLI app is now checked in, rather than generated dynamically with `ng new`. This loses some assertion power, but gains hermeticity. It also checks in lock files for all integration tests, avoiding floating version numbers. We'll need another place to integration test between changes in the various repositories - but the angular/angular PR-blocking status is not the right place to do this. PR Close #21555
2018-01-16 07:09:59 -08:00
dependencies:
once "^1.3.0"
wrappy "1"
test(language-service): Improve integration test (#28168) The current integration test for language service involves piping the results of one process to another using Unix pipes. This makes the test hard to debug, and hard to configure. This commit refactors the integration test to use regular Jasmine scaffolding. More importantly, it tests the way the language service will actually be installed by end users. Users would not have to add `@angular/language-service` to the plugins section in tsconfig.json Instead, all they need to do is install the *extension* from the VS Code Marketplace and Angular Language Service will be loaded as a global plugin. PR Close #28168
2018-12-17 23:44:26 -08:00
inherits@2:
ci: Add back the CLI integration test with pinning (#21555) The CLI app is now checked in, rather than generated dynamically with `ng new`. This loses some assertion power, but gains hermeticity. It also checks in lock files for all integration tests, avoiding floating version numbers. We'll need another place to integration test between changes in the various repositories - but the angular/angular PR-blocking status is not the right place to do this. PR Close #21555
2018-01-16 07:09:59 -08:00
version "2.0.3"
resolved "https://registry.yarnpkg.com/inherits/-/inherits-2.0.3.tgz#633c2c83e3da42a502f52466022480f4208261de"
test(language-service): Improve integration test (#28168) The current integration test for language service involves piping the results of one process to another using Unix pipes. This makes the test hard to debug, and hard to configure. This commit refactors the integration test to use regular Jasmine scaffolding. More importantly, it tests the way the language service will actually be installed by end users. Users would not have to add `@angular/language-service` to the plugins section in tsconfig.json Instead, all they need to do is install the *extension* from the VS Code Marketplace and Angular Language Service will be loaded as a global plugin. PR Close #28168
2018-12-17 23:44:26 -08:00
integrity sha1-Yzwsg+PaQqUC9SRmAiSA9CCCYd4=
ci: Add back the CLI integration test with pinning (#21555) The CLI app is now checked in, rather than generated dynamically with `ng new`. This loses some assertion power, but gains hermeticity. It also checks in lock files for all integration tests, avoiding floating version numbers. We'll need another place to integration test between changes in the various repositories - but the angular/angular PR-blocking status is not the right place to do this. PR Close #21555
2018-01-16 07:09:59 -08:00
feat(language-service): Implement `definitionAndBoundSpan` (#30125) This PR adds the implementation for `definitionAndBoundSpan` because it's now preferred over `definition`. vscode would send this new request for `Go to definition`. As part of this PR the implementation for `definition` is refactored and simplified. Goldens for both methods are checked in. PR Close #30125
2019-04-25 11:11:33 -07:00
jasmine-core@~3.3.0:
version "3.3.0"
resolved "https://registry.yarnpkg.com/jasmine-core/-/jasmine-core-3.3.0.tgz#dea1cdc634bc93c7e0d4ad27185df30fa971b10e"
integrity sha512-3/xSmG/d35hf80BEN66Y6g9Ca5l/Isdeg/j6zvbTYlTzeKinzmaTM4p9am5kYqOmE05D7s1t8FGjzdSnbUbceA==
ci: Add back the CLI integration test with pinning (#21555) The CLI app is now checked in, rather than generated dynamically with `ng new`. This loses some assertion power, but gains hermeticity. It also checks in lock files for all integration tests, avoiding floating version numbers. We'll need another place to integration test between changes in the various repositories - but the angular/angular PR-blocking status is not the right place to do this. PR Close #21555
2018-01-16 07:09:59 -08:00
test(language-service): Improve integration test (#28168) The current integration test for language service involves piping the results of one process to another using Unix pipes. This makes the test hard to debug, and hard to configure. This commit refactors the integration test to use regular Jasmine scaffolding. More importantly, it tests the way the language service will actually be installed by end users. Users would not have to add `@angular/language-service` to the plugins section in tsconfig.json Instead, all they need to do is install the *extension* from the VS Code Marketplace and Angular Language Service will be loaded as a global plugin. PR Close #28168
2018-12-17 23:44:26 -08:00
"jasmine@file:../../node_modules/jasmine":
feat(language-service): Implement `definitionAndBoundSpan` (#30125) This PR adds the implementation for `definitionAndBoundSpan` because it's now preferred over `definition`. vscode would send this new request for `Go to definition`. As part of this PR the implementation for `definition` is refactored and simplified. Goldens for both methods are checked in. PR Close #30125
2019-04-25 11:11:33 -07:00
version "3.3.1"
ci: Add back the CLI integration test with pinning (#21555) The CLI app is now checked in, rather than generated dynamically with `ng new`. This loses some assertion power, but gains hermeticity. It also checks in lock files for all integration tests, avoiding floating version numbers. We'll need another place to integration test between changes in the various repositories - but the angular/angular PR-blocking status is not the right place to do this. PR Close #21555
2018-01-16 07:09:59 -08:00
dependencies:
test(language-service): Improve integration test (#28168) The current integration test for language service involves piping the results of one process to another using Unix pipes. This makes the test hard to debug, and hard to configure. This commit refactors the integration test to use regular Jasmine scaffolding. More importantly, it tests the way the language service will actually be installed by end users. Users would not have to add `@angular/language-service` to the plugins section in tsconfig.json Instead, all they need to do is install the *extension* from the VS Code Marketplace and Angular Language Service will be loaded as a global plugin. PR Close #28168
2018-12-17 23:44:26 -08:00
glob "^7.0.6"
feat(language-service): Implement `definitionAndBoundSpan` (#30125) This PR adds the implementation for `definitionAndBoundSpan` because it's now preferred over `definition`. vscode would send this new request for `Go to definition`. As part of this PR the implementation for `definition` is refactored and simplified. Goldens for both methods are checked in. PR Close #30125
2019-04-25 11:11:33 -07:00
jasmine-core "~3.3.0"
ci: Add back the CLI integration test with pinning (#21555) The CLI app is now checked in, rather than generated dynamically with `ng new`. This loses some assertion power, but gains hermeticity. It also checks in lock files for all integration tests, avoiding floating version numbers. We'll need another place to integration test between changes in the various repositories - but the angular/angular PR-blocking status is not the right place to do this. PR Close #21555
2018-01-16 07:09:59 -08:00
test(language-service): Improve integration test (#28168) The current integration test for language service involves piping the results of one process to another using Unix pipes. This makes the test hard to debug, and hard to configure. This commit refactors the integration test to use regular Jasmine scaffolding. More importantly, it tests the way the language service will actually be installed by end users. Users would not have to add `@angular/language-service` to the plugins section in tsconfig.json Instead, all they need to do is install the *extension* from the VS Code Marketplace and Angular Language Service will be loaded as a global plugin. PR Close #28168
2018-12-17 23:44:26 -08:00
minimatch@^3.0.4:
ci: Add back the CLI integration test with pinning (#21555) The CLI app is now checked in, rather than generated dynamically with `ng new`. This loses some assertion power, but gains hermeticity. It also checks in lock files for all integration tests, avoiding floating version numbers. We'll need another place to integration test between changes in the various repositories - but the angular/angular PR-blocking status is not the right place to do this. PR Close #21555
2018-01-16 07:09:59 -08:00
version "3.0.4"
resolved "https://registry.yarnpkg.com/minimatch/-/minimatch-3.0.4.tgz#5166e286457f03306064be5497e8dbb0c3d32083"
test(language-service): Improve integration test (#28168) The current integration test for language service involves piping the results of one process to another using Unix pipes. This makes the test hard to debug, and hard to configure. This commit refactors the integration test to use regular Jasmine scaffolding. More importantly, it tests the way the language service will actually be installed by end users. Users would not have to add `@angular/language-service` to the plugins section in tsconfig.json Instead, all they need to do is install the *extension* from the VS Code Marketplace and Angular Language Service will be loaded as a global plugin. PR Close #28168
2018-12-17 23:44:26 -08:00
integrity sha512-yJHVQEhyqPLUTgt9B83PXu6W3rx4MvvHvSUvToogpwoGDOUQ+yDrR0HRot+yOCdCO7u4hX3pWft6kWBBcqh0UA==
ci: Add back the CLI integration test with pinning (#21555) The CLI app is now checked in, rather than generated dynamically with `ng new`. This loses some assertion power, but gains hermeticity. It also checks in lock files for all integration tests, avoiding floating version numbers. We'll need another place to integration test between changes in the various repositories - but the angular/angular PR-blocking status is not the right place to do this. PR Close #21555
2018-01-16 07:09:59 -08:00
dependencies:
brace-expansion "^1.1.7"
test(language-service): Improve integration test (#28168) The current integration test for language service involves piping the results of one process to another using Unix pipes. This makes the test hard to debug, and hard to configure. This commit refactors the integration test to use regular Jasmine scaffolding. More importantly, it tests the way the language service will actually be installed by end users. Users would not have to add `@angular/language-service` to the plugins section in tsconfig.json Instead, all they need to do is install the *extension* from the VS Code Marketplace and Angular Language Service will be loaded as a global plugin. PR Close #28168
2018-12-17 23:44:26 -08:00
once@^1.3.0:
ci: Add back the CLI integration test with pinning (#21555) The CLI app is now checked in, rather than generated dynamically with `ng new`. This loses some assertion power, but gains hermeticity. It also checks in lock files for all integration tests, avoiding floating version numbers. We'll need another place to integration test between changes in the various repositories - but the angular/angular PR-blocking status is not the right place to do this. PR Close #21555
2018-01-16 07:09:59 -08:00
version "1.4.0"
resolved "https://registry.yarnpkg.com/once/-/once-1.4.0.tgz#583b1aa775961d4b113ac17d9c50baef9dd76bd1"
test(language-service): Improve integration test (#28168) The current integration test for language service involves piping the results of one process to another using Unix pipes. This makes the test hard to debug, and hard to configure. This commit refactors the integration test to use regular Jasmine scaffolding. More importantly, it tests the way the language service will actually be installed by end users. Users would not have to add `@angular/language-service` to the plugins section in tsconfig.json Instead, all they need to do is install the *extension* from the VS Code Marketplace and Angular Language Service will be loaded as a global plugin. PR Close #28168
2018-12-17 23:44:26 -08:00
integrity sha1-WDsap3WWHUsROsF9nFC6753Xa9E=
ci: Add back the CLI integration test with pinning (#21555) The CLI app is now checked in, rather than generated dynamically with `ng new`. This loses some assertion power, but gains hermeticity. It also checks in lock files for all integration tests, avoiding floating version numbers. We'll need another place to integration test between changes in the various repositories - but the angular/angular PR-blocking status is not the right place to do this. PR Close #21555
2018-01-16 07:09:59 -08:00
dependencies:
wrappy "1"
path-is-absolute@^1.0.0:
version "1.0.1"
resolved "https://registry.yarnpkg.com/path-is-absolute/-/path-is-absolute-1.0.1.tgz#174b9268735534ffbc7ace6bf53a5a9e1b5c5f5f"
test(language-service): Improve integration test (#28168) The current integration test for language service involves piping the results of one process to another using Unix pipes. This makes the test hard to debug, and hard to configure. This commit refactors the integration test to use regular Jasmine scaffolding. More importantly, it tests the way the language service will actually be installed by end users. Users would not have to add `@angular/language-service` to the plugins section in tsconfig.json Instead, all they need to do is install the *extension* from the VS Code Marketplace and Angular Language Service will be loaded as a global plugin. PR Close #28168
2018-12-17 23:44:26 -08:00
integrity sha1-F0uSaHNVNP+8es5r9TpanhtcX18=
ci: Add back the CLI integration test with pinning (#21555) The CLI app is now checked in, rather than generated dynamically with `ng new`. This loses some assertion power, but gains hermeticity. It also checks in lock files for all integration tests, avoiding floating version numbers. We'll need another place to integration test between changes in the various repositories - but the angular/angular PR-blocking status is not the right place to do this. PR Close #21555
2018-01-16 07:09:59 -08:00
"typescript@file:../../node_modules/typescript":
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 16:44:50 -07:00
version "3.6.4"
ci: Add back the CLI integration test with pinning (#21555) The CLI app is now checked in, rather than generated dynamically with `ng new`. This loses some assertion power, but gains hermeticity. It also checks in lock files for all integration tests, avoiding floating version numbers. We'll need another place to integration test between changes in the various repositories - but the angular/angular PR-blocking status is not the right place to do this. PR Close #21555
2018-01-16 07:09:59 -08:00
wrappy@1:
version "1.0.2"
resolved "https://registry.yarnpkg.com/wrappy/-/wrappy-1.0.2.tgz#b5243d8f3ec1aa35f1364605bc0d1036e30ab69f"
test(language-service): Improve integration test (#28168) The current integration test for language service involves piping the results of one process to another using Unix pipes. This makes the test hard to debug, and hard to configure. This commit refactors the integration test to use regular Jasmine scaffolding. More importantly, it tests the way the language service will actually be installed by end users. Users would not have to add `@angular/language-service` to the plugins section in tsconfig.json Instead, all they need to do is install the *extension* from the VS Code Marketplace and Angular Language Service will be loaded as a global plugin. PR Close #28168
2018-12-17 23:44:26 -08:00
integrity sha1-tSQ9jz7BqjXxNkYFvA0QNuMKtp8=
Reference in New Issue Copy Permalink