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

50 lines
1.4 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): update package.json and :npm_package (#36434) * Set up dev-infra's :npm_package to also contain benchmarking suite * Add benchmarking deps to dev-infra's package.json * Add a bazel workspace to dev-infra's package.json. This is so that when a project wants to use dev-infra's code and macros, they can just import the macros from their node_modules instead of loading it separately PR Close #36434
2020-04-22 12:56:40 -04:00
"dependencies": {
"fs-extra": "<from-root>",
"node-uuid": "<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
"peerDependencies": {
build(dev-infra): update package.json and :npm_package (#36434) * Set up dev-infra's :npm_package to also contain benchmarking suite * Add benchmarking deps to dev-infra's package.json * Add a bazel workspace to dev-infra's package.json. This is so that when a project wants to use dev-infra's code and macros, they can just import the macros from their node_modules instead of loading it separately PR Close #36434
2020-04-22 12:56:40 -04:00
"@angular/bazel": "^9.0.0",
"@angular/core": "^9.0.0",
"@angular/platform-browser": "^9.0.0",
"@angular/benchpress": "^0.1.0",
"@angular-devkit/build-optimizer": "<from-root>",
"@bazel/protractor": "<from-root>",
"@bazel/terser": "<from-root>",
"@bazel/typescript": "<from-root>",
"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>",
"glob": "<from-root>",
build(dev-infra): update package.json and :npm_package (#36434) * Set up dev-infra's :npm_package to also contain benchmarking suite * Add benchmarking deps to dev-infra's package.json * Add a bazel workspace to dev-infra's package.json. This is so that when a project wants to use dev-infra's code and macros, they can just import the macros from their node_modules instead of loading it separately PR Close #36434
2020-04-22 12:56:40 -04:00
"json5": "<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>",
build(dev-infra): update package.json and :npm_package (#36434) * Set up dev-infra's :npm_package to also contain benchmarking suite * Add benchmarking deps to dev-infra's package.json * Add a bazel workspace to dev-infra's package.json. This is so that when a project wants to use dev-infra's code and macros, they can just import the macros from their node_modules instead of loading it separately PR Close #36434
2020-04-22 12:56:40 -04:00
"node-uuid": "<from-root>",
"protractor": "<from-root>",
"rollup": "<from-root>",
"rollup-plugin-commonjs": "<from-root>",
"rollup-plugin-node-resolve": "<from-root>",
"rollup-plugin-sourcemaps": "<from-root>",
"selenium-webdriver": "<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>",
"typescript": "<from-root>",
"yaml": "<from-root>",
"yargs": "<from-root>",
build(dev-infra): update package.json and :npm_package (#36434) * Set up dev-infra's :npm_package to also contain benchmarking suite * Add benchmarking deps to dev-infra's package.json * Add a bazel workspace to dev-infra's package.json. This is so that when a project wants to use dev-infra's code and macros, they can just import the macros from their node_modules instead of loading it separately PR Close #36434
2020-04-22 12:56:40 -04:00
"tslib": "<from-root>",
"zone.js": "^0.10.3"
},
"bazelWorkspaces": {
"npm_dev_infra": {
"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
}
}