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

61 lines
1.5 KiB
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": {
refactor(dev-infra): cleanup shared package dependencies (#37594) Cleans up the dependencies used in the shared dev-infra package configuration. With the recent benchmarking utilities that have been added, a lot of peer dependencies have been added. We decided that we don't want to list every used dependencies as peer dependency as that could result in unnecessary churn/noise for consumers of the dev-infra package. Additionally, not all parts of the dev-infra package are necessarily used. Due to this, we want to apply the following rules for the package dependencies: 1. If a dependency is only used in a shipped Bazel macro/rule that can be optionally consumed, omit it from `package.json`. Bazel reports the missing dependency on its own, so we want to avoid adding it to the package json file. 2. Otherwise, if the dependency is large and commonly used (like buildifier), add it to the `peerDependencies`. If not, add it to the dependencies that are always brought in. We consider it as acceptable to bring in a few small dependencies that might not be used or not. Making all of those option would complicate the use of the dev-infra package. ds PR Close #37594
2020-06-15 17:03:32 -04:00
"@angular/benchpress": "0.2.0",
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>",
refactor(dev-infra): cleanup shared package dependencies (#37594) Cleans up the dependencies used in the shared dev-infra package configuration. With the recent benchmarking utilities that have been added, a lot of peer dependencies have been added. We decided that we don't want to list every used dependencies as peer dependency as that could result in unnecessary churn/noise for consumers of the dev-infra package. Additionally, not all parts of the dev-infra package are necessarily used. Due to this, we want to apply the following rules for the package dependencies: 1. If a dependency is only used in a shipped Bazel macro/rule that can be optionally consumed, omit it from `package.json`. Bazel reports the missing dependency on its own, so we want to avoid adding it to the package json file. 2. Otherwise, if the dependency is large and commonly used (like buildifier), add it to the `peerDependencies`. If not, add it to the dependencies that are always brought in. We consider it as acceptable to bring in a few small dependencies that might not be used or not. Making all of those option would complicate the use of the dev-infra package. ds PR Close #37594
2020-06-15 17:03:32 -04:00
"brotli": "<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>",
revert: "revert: "build(dev-infra): update package.json and :npm_package (#36434)" (#36798)" (#36800) This reverts commit f5ff2068a48f60c747c2936908e848d301f4dba4. PR Close #36800
2020-05-15 13:26:01 -04:00
"node-uuid": "<from-root>",
feat(dev-infra): expose script for determining merge branches (#37217) The components repo and framework repository follow the same patch branch concept. We should be able to share a script for determining these merge branches. Additonally the logic has been improved compared to the old merge script because we no longer consult `git ls-remote` unless really needed. Currently, `git ls-remote` is always consulted, even though not necessarily needed. This can slow down the merge script and the caretaker process when a couple of PRs are merged (personally saw around ~4 seconds per merge). Additionally, the new logic is more strict and will ensure (in most cases) that no wrong patch/minor branch is determined. Previously, the script just used the lexicographically greatest patch branch. This _could_ be wrong when a new patch branch has been created too early, or by accident. PR Close #37217
2020-05-20 06:50:18 -04:00
"semver": "<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>",
refactor(dev-infra): cleanup shared package dependencies (#37594) Cleans up the dependencies used in the shared dev-infra package configuration. With the recent benchmarking utilities that have been added, a lot of peer dependencies have been added. We decided that we don't want to list every used dependencies as peer dependency as that could result in unnecessary churn/noise for consumers of the dev-infra package. Additionally, not all parts of the dev-infra package are necessarily used. Due to this, we want to apply the following rules for the package dependencies: 1. If a dependency is only used in a shipped Bazel macro/rule that can be optionally consumed, omit it from `package.json`. Bazel reports the missing dependency on its own, so we want to avoid adding it to the package json file. 2. Otherwise, if the dependency is large and commonly used (like buildifier), add it to the `peerDependencies`. If not, add it to the dependencies that are always brought in. We consider it as acceptable to bring in a few small dependencies that might not be used or not. Making all of those option would complicate the use of the dev-infra package. ds PR Close #37594
2020-06-15 17:03:32 -04:00
"tslib": "<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>",
revert: "revert: "build(dev-infra): update package.json and :npm_package (#36434)" (#36798)" (#36800) This reverts commit f5ff2068a48f60c747c2936908e848d301f4dba4. PR Close #36800
2020-05-15 13:26:01 -04:00
"protractor": "<from-root>",
"selenium-webdriver": "<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>",
refactor(dev-infra): cleanup shared package dependencies (#37594) Cleans up the dependencies used in the shared dev-infra package configuration. With the recent benchmarking utilities that have been added, a lot of peer dependencies have been added. We decided that we don't want to list every used dependencies as peer dependency as that could result in unnecessary churn/noise for consumers of the dev-infra package. Additionally, not all parts of the dev-infra package are necessarily used. Due to this, we want to apply the following rules for the package dependencies: 1. If a dependency is only used in a shipped Bazel macro/rule that can be optionally consumed, omit it from `package.json`. Bazel reports the missing dependency on its own, so we want to avoid adding it to the package json file. 2. Otherwise, if the dependency is large and commonly used (like buildifier), add it to the `peerDependencies`. If not, add it to the dependencies that are always brought in. We consider it as acceptable to bring in a few small dependencies that might not be used or not. Making all of those option would complicate the use of the dev-infra package. ds PR Close #37594
2020-06-15 17:03:32 -04:00
"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": {
refactor(dev-infra): cleanup shared package dependencies (#37594) Cleans up the dependencies used in the shared dev-infra package configuration. With the recent benchmarking utilities that have been added, a lot of peer dependencies have been added. We decided that we don't want to list every used dependencies as peer dependency as that could result in unnecessary churn/noise for consumers of the dev-infra package. Additionally, not all parts of the dev-infra package are necessarily used. Due to this, we want to apply the following rules for the package dependencies: 1. If a dependency is only used in a shipped Bazel macro/rule that can be optionally consumed, omit it from `package.json`. Bazel reports the missing dependency on its own, so we want to avoid adding it to the package json file. 2. Otherwise, if the dependency is large and commonly used (like buildifier), add it to the `peerDependencies`. If not, add it to the dependencies that are always brought in. We consider it as acceptable to bring in a few small dependencies that might not be used or not. Making all of those option would complicate the use of the dev-infra package. ds PR Close #37594
2020-06-15 17:03:32 -04:00
"@bazel/buildifier": {
"optional": true
},
"clang-format": {
"optional": true
},
"protractor": {
"optional": true
},
"selenium-webdriver": {
"optional": true
},
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": {
"optional": true
}
revert: "revert: "build(dev-infra): update package.json and :npm_package (#36434)" (#36798)" (#36800) This reverts commit f5ff2068a48f60c747c2936908e848d301f4dba4. PR Close #36800
2020-05-15 13:26:01 -04:00
},
"bazelWorkspaces": {
refactor(dev-infra): small changes and fixes (#36800) Rename bazel workspace from npm_dev_infra to npm_angular_dev_infra_private to make it clear that this package is private to angular. Change driver-utilities module_name to match the new bazel workspace name. Correct a comment by rewording it from "deployed version" to "published version". Fix merge conflicts in tmpl-package.json Make "//packages/bazel/src:esm5.bzl" replacement more generalized so that importing from "//packages/bazel" works. Deleted "dev_infra/*" path from modules/benchmarks tsconfig. Moved //dev-infra/benchmark/browsers to //dev-infra/browsers. PR Close #36800
2020-05-08 15:56:39 -04:00
"npm_angular_dev_infra_private": {
revert: "revert: "build(dev-infra): update package.json and :npm_package (#36434)" (#36798)" (#36800) This reverts commit f5ff2068a48f60c747c2936908e848d301f4dba4. PR Close #36800
2020-05-15 13:26:01 -04:00
"version": "0.0.0-PLACEHOLDER",
"rootPath": "."
}
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
}
}