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

37 lines
956 B
JSON
Raw Normal View History

build: remove rollup packaging from dev-infra (#35647) The dev-infra package currently uses rollup for packaging. This has been done initially as a way to workaround manifest paths being used in the AMD JavaScript output. The actual solution to this problem is setting module names that match the `package.json` name. This ensures that the package can be consumed correctly in Bazel, and through NPM. This allows us to get rid of the rollup bundling, and we don't need to hard-code which dependencies should be external or included. Additionally, tools that are part of `dev-infra` can now specify their external dependencies simply in the `package.json`. To reduce version duplication, and out-of-sync versions, a new genrule has been created that syncs the versions with the top-level project `package.json`. PR Close #35647
2020-03-17 07:58:17 -04:00
{
"name": "@angular/dev-infra-private",
"version": "0.0.0",
"description": "INTERNAL USE ONLY - Angular internal DevInfra tooling/scripts - INTERNAL USE ONLY",
"license": "MIT",
"private": true,
"bin": {
"ng-dev": "./cli.js",
"ts-circular-deps": "./ts-circular-dependencies/index.js"
},
build(dev-infra): cleanup package dependencies for shared package (#36980) As per our discussion in the dev-infra sync meeting, we don't want to have all dependencies show up as peer dependencies. Instead, we only want to have larger dependencies such as `typescript` or buildifier as peer dependencies. Tslib is also included for the sake of it being generally a peer dependency of all Angular framework packages. The rationale is that Yarn is smart enough to collapse packages if all satisfy a given range. This means that we don't necessarily need to have all dependencies as peer dependencies. The initial idea was to keep all dependencies as peer dependencies so that we have control over duplication of packages as downloading multiple packages w/ different versions impacts local dev, CI and caches. At the same time though, we don't want to bother with setting up peer dependencies all the time. Not every consumer of the shared dev-infra package would like to manually specify `yaml` or `multimatch` etc. in the project `package.json`. Hence we decided to go with a hybrid approach where only more impactful dependencies are peer dependencies, and other smaller ones can be standard depdencies that are usually collapsed by Yarn anyway. Also this commit removes tslib from build targets that don't rely on it. PR Close #36980
2020-05-12 12:48:02 -04:00
"dependencies": {
feat(dev-infra): create tool to determine conflicts created by a PR (#37051) Creates a tool in ng-dev to determine the PRs which become conflicted by merging a specified PR. Often the question is brought up of how many PRs require a rebase as a result of a change. This script allows to determine this impact. PR Close #37051
2020-05-05 18:37:31 -04:00
"@octokit/graphql": "<from-root>",
build: remove rollup packaging from dev-infra (#35647) The dev-infra package currently uses rollup for packaging. This has been done initially as a way to workaround manifest paths being used in the AMD JavaScript output. The actual solution to this problem is setting module names that match the `package.json` name. This ensures that the package can be consumed correctly in Bazel, and through NPM. This allows us to get rid of the rollup bundling, and we don't need to hard-code which dependencies should be external or included. Additionally, tools that are part of `dev-infra` can now specify their external dependencies simply in the `package.json`. To reduce version duplication, and out-of-sync versions, a new genrule has been created that syncs the versions with the top-level project `package.json`. PR Close #35647
2020-03-17 07:58:17 -04:00
"chalk": "<from-root>",
feat(dev-infra): create format tool in @angular/dev-infra-private (#36726) Previously we used gulp to run our formatter, currently clang-format, across our repository. This new tool within ng-dev allows us to migrate away from our gulp based solution as our gulp solution had issue with memory pressure and would cause OOM errors with too large of change sets. PR Close #36726
2020-04-20 16:00:10 -04:00
"cli-progress": "<from-root>",
build: remove rollup packaging from dev-infra (#35647) The dev-infra package currently uses rollup for packaging. This has been done initially as a way to workaround manifest paths being used in the AMD JavaScript output. The actual solution to this problem is setting module names that match the `package.json` name. This ensures that the package can be consumed correctly in Bazel, and through NPM. This allows us to get rid of the rollup bundling, and we don't need to hard-code which dependencies should be external or included. Additionally, tools that are part of `dev-infra` can now specify their external dependencies simply in the `package.json`. To reduce version duplication, and out-of-sync versions, a new genrule has been created that syncs the versions with the top-level project `package.json`. PR Close #35647
2020-03-17 07:58:17 -04:00
"glob": "<from-root>",
feat(dev-infra): create format tool in @angular/dev-infra-private (#36726) Previously we used gulp to run our formatter, currently clang-format, across our repository. This new tool within ng-dev allows us to migrate away from our gulp based solution as our gulp solution had issue with memory pressure and would cause OOM errors with too large of change sets. PR Close #36726
2020-04-20 16:00:10 -04:00
"inquirer": "<from-root>",
build: remove rollup packaging from dev-infra (#35647) The dev-infra package currently uses rollup for packaging. This has been done initially as a way to workaround manifest paths being used in the AMD JavaScript output. The actual solution to this problem is setting module names that match the `package.json` name. This ensures that the package can be consumed correctly in Bazel, and through NPM. This allows us to get rid of the rollup bundling, and we don't need to hard-code which dependencies should be external or included. Additionally, tools that are part of `dev-infra` can now specify their external dependencies simply in the `package.json`. To reduce version duplication, and out-of-sync versions, a new genrule has been created that syncs the versions with the top-level project `package.json`. PR Close #35647
2020-03-17 07:58:17 -04:00
"minimatch": "<from-root>",
feat(dev-infra): create format tool in @angular/dev-infra-private (#36726) Previously we used gulp to run our formatter, currently clang-format, across our repository. This new tool within ng-dev allows us to migrate away from our gulp based solution as our gulp solution had issue with memory pressure and would cause OOM errors with too large of change sets. PR Close #36726
2020-04-20 16:00:10 -04:00
"multimatch": "<from-root>",
build: remove rollup packaging from dev-infra (#35647) The dev-infra package currently uses rollup for packaging. This has been done initially as a way to workaround manifest paths being used in the AMD JavaScript output. The actual solution to this problem is setting module names that match the `package.json` name. This ensures that the package can be consumed correctly in Bazel, and through NPM. This allows us to get rid of the rollup bundling, and we don't need to hard-code which dependencies should be external or included. Additionally, tools that are part of `dev-infra` can now specify their external dependencies simply in the `package.json`. To reduce version duplication, and out-of-sync versions, a new genrule has been created that syncs the versions with the top-level project `package.json`. PR Close #35647
2020-03-17 07:58:17 -04:00
"shelljs": "<from-root>",
feat(dev-infra): create tool to determine conflicts created by a PR (#37051) Creates a tool in ng-dev to determine the PRs which become conflicted by merging a specified PR. Often the question is brought up of how many PRs require a rebase as a result of a change. This script allows to determine this impact. PR Close #37051
2020-05-05 18:37:31 -04:00
"typed-graphqlify": "<from-root>",
build: remove rollup packaging from dev-infra (#35647) The dev-infra package currently uses rollup for packaging. This has been done initially as a way to workaround manifest paths being used in the AMD JavaScript output. The actual solution to this problem is setting module names that match the `package.json` name. This ensures that the package can be consumed correctly in Bazel, and through NPM. This allows us to get rid of the rollup bundling, and we don't need to hard-code which dependencies should be external or included. Additionally, tools that are part of `dev-infra` can now specify their external dependencies simply in the `package.json`. To reduce version duplication, and out-of-sync versions, a new genrule has been created that syncs the versions with the top-level project `package.json`. PR Close #35647
2020-03-17 07:58:17 -04:00
"yaml": "<from-root>",
build(dev-infra): cleanup package dependencies for shared package (#36980) As per our discussion in the dev-infra sync meeting, we don't want to have all dependencies show up as peer dependencies. Instead, we only want to have larger dependencies such as `typescript` or buildifier as peer dependencies. Tslib is also included for the sake of it being generally a peer dependency of all Angular framework packages. The rationale is that Yarn is smart enough to collapse packages if all satisfy a given range. This means that we don't necessarily need to have all dependencies as peer dependencies. The initial idea was to keep all dependencies as peer dependencies so that we have control over duplication of packages as downloading multiple packages w/ different versions impacts local dev, CI and caches. At the same time though, we don't want to bother with setting up peer dependencies all the time. Not every consumer of the shared dev-infra package would like to manually specify `yaml` or `multimatch` etc. in the project `package.json`. Hence we decided to go with a hybrid approach where only more impactful dependencies are peer dependencies, and other smaller ones can be standard depdencies that are usually collapsed by Yarn anyway. Also this commit removes tslib from build targets that don't rely on it. PR Close #36980
2020-05-12 12:48:02 -04:00
"yargs": "<from-root>"
},
"peerDependencies": {
"@bazel/buildifier": "<from-root>",
"clang-format": "<from-root>",
feat(dev-infra): register ts-node when reading configuration (#37196) `ts-node` is now an optional peer dependency of the shared dev-infra package. Whenever a `ng-dev` command runs, and a TypeScript-based configuration file exists, `ts-node` is set up if available. That allows consumers of the package (as the components repo) to more conveniently use a TypeScript-based configuration for dev-infra. Currently, commands would need to be proxied through `ts-node` which rather complicates the setup: ``` NG_DEV_COMMAND="ts-node ./node_modules/@angular/dev-infra-private/cli.js" ``` I'm thinking that it should be best-practice to use TypeScript for writing the configuration files. Given that the tool is used primarily in Angular projects (for which most sources are TypeScript), this should be acceptable. PR Close #37196
2020-05-19 05:08:29 -04:00
"ts-node": "<from-root>",
build(dev-infra): cleanup package dependencies for shared package (#36980) As per our discussion in the dev-infra sync meeting, we don't want to have all dependencies show up as peer dependencies. Instead, we only want to have larger dependencies such as `typescript` or buildifier as peer dependencies. Tslib is also included for the sake of it being generally a peer dependency of all Angular framework packages. The rationale is that Yarn is smart enough to collapse packages if all satisfy a given range. This means that we don't necessarily need to have all dependencies as peer dependencies. The initial idea was to keep all dependencies as peer dependencies so that we have control over duplication of packages as downloading multiple packages w/ different versions impacts local dev, CI and caches. At the same time though, we don't want to bother with setting up peer dependencies all the time. Not every consumer of the shared dev-infra package would like to manually specify `yaml` or `multimatch` etc. in the project `package.json`. Hence we decided to go with a hybrid approach where only more impactful dependencies are peer dependencies, and other smaller ones can be standard depdencies that are usually collapsed by Yarn anyway. Also this commit removes tslib from build targets that don't rely on it. PR Close #36980
2020-05-12 12:48:02 -04:00
"tslib": "<from-root>",
"typescript": "<from-root>"
feat(dev-infra): register ts-node when reading configuration (#37196) `ts-node` is now an optional peer dependency of the shared dev-infra package. Whenever a `ng-dev` command runs, and a TypeScript-based configuration file exists, `ts-node` is set up if available. That allows consumers of the package (as the components repo) to more conveniently use a TypeScript-based configuration for dev-infra. Currently, commands would need to be proxied through `ts-node` which rather complicates the setup: ``` NG_DEV_COMMAND="ts-node ./node_modules/@angular/dev-infra-private/cli.js" ``` I'm thinking that it should be best-practice to use TypeScript for writing the configuration files. Given that the tool is used primarily in Angular projects (for which most sources are TypeScript), this should be acceptable. PR Close #37196
2020-05-19 05:08:29 -04:00
},
"peerDependenciesMeta": {
"ts-node": {
"optional": true
}
build: remove rollup packaging from dev-infra (#35647) The dev-infra package currently uses rollup for packaging. This has been done initially as a way to workaround manifest paths being used in the AMD JavaScript output. The actual solution to this problem is setting module names that match the `package.json` name. This ensures that the package can be consumed correctly in Bazel, and through NPM. This allows us to get rid of the rollup bundling, and we don't need to hard-code which dependencies should be external or included. Additionally, tools that are part of `dev-infra` can now specify their external dependencies simply in the `package.json`. To reduce version duplication, and out-of-sync versions, a new genrule has been created that syncs the versions with the top-level project `package.json`. PR Close #35647
2020-03-17 07:58:17 -04:00
}
}