honeymoose
/
angular-cn
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
angular-cn/packages/bazel/test/ng_package/example-with-ts-library/package.json

14 lines
393 B
JSON
Raw Normal View History

feat(bazel): support ts_library targets as entry-points for ng_package (#32610) Within an Angular package, it can happen that there are entry-points which do not contain features that belong into an `@NgModule` or need metadata files to be generated. For example: the `cdk`, `cdk/testing` and `cdk/coercion` entry-points. Besides other entry-points in the `cdk` package, those entry-points do not need metadata to be generated and no not use the `ng_module` rule. Currently the "ng_package" rule properly picks up such entry-points and builds bundles, does downleveling etc. The only thing it misses is that no `package.json` files are generated for the entry-point. This means that consumers will not be able to use these entry-points built with "ts_library" (except accessing the individual bundlings explicitly). The "ng_package" rule should follow the full APF specification for such entry-points. Partially building bundles and doing the downleveling is confusing and a breaking issue. The motifivation of supporting this (besides making the rule behavior consistent; the incomplete output is not acceptable), is that using the "ng_module" rule does not make sense to be used for non-Angular entry-points. Especially since it depends on Angular packages to be specified as Bazel action inputs just to compile vanilla TypeScript with `@angular/compiler-cli`. PR Close #32610
2019-09-11 16:21:34 -04:00
{
"name": "example",
"version": "0.0.0-PLACEHOLDER",
"main": "./bundles/example.umd.js",
"fesm5": "./fesm5/example.js",
"fesm2015": "./fesm2015/example.js",
"esm5": "./esm5/index.js",
"esm2015": "./esm2015/index.js",
"typings": "./index.d.ts",
"module": "./fesm5/example.js",
"es2015": "./fesm2015/example.js",
"schematics": "Custom property that should be preserved."
}