Consider loading all public starlark API from @npm workspace #1149
Comments
alexeagle
added
cleanup
|
This would also solve the issue users are having if they have multiple npm workspaces. Some users with monorepos want to manage multiple package.json files and have multiple yarn_installs. They have may an Currently, they need to override the ts_library defaults in a defaults.bzl for each app so that they point to the appropriate npm workspace. If the users load ts_library directly from the npm repo for the app such as The same general pattern applies to other rule such as karma which as |
|
We should also consider making the WORKSPACE load locations for dependency setup such as, consistent with |
|
This is now mostly done, all the nested workspaces under packages/ are removed. The only remaining task to maybe do is rename the dependencies functions like |
|
@gregmagolan and I decided the names aren't wrong or misleading, just long and has some historical baggage. so not worth the churn. This is all done ! |
This function is no longer needed since bazel-contrib#1149 was finished. However, @angular/bazel relies on it, as might other third-party packages we know nothing about. The conservative rollout is to warn on usage for now, then remove the feature in 3.0 This change also removes our own usage of the function except for angular_view_engine. We also stop writing it in new workspaces created with @bazel/create
This function is no longer needed since bazel-contrib#1149 was finished. However, @angular/bazel relies on it, as might other third-party packages we know nothing about. The conservative rollout is to warn on usage for now, then remove the feature in 3.0 This change also removes our own usage of the function except for angular_view_engine. We also stop writing it in new workspaces created with @bazel/create
This function is no longer needed since #1149 was finished. However, @angular/bazel relies on it, as might other third-party packages we know nothing about. The conservative rollout is to warn on usage for now, then remove the feature in 3.0 This change also removes our own usage of the function except for angular_view_engine. We also stop writing it in new workspaces created with @bazel/create
In the https://hackmd.angular.io/f8OBi9KMTNKButSWsh1gCA?view proposal we suggest loading npm package rules for simple packages from
eg
@npm//less:index.bzlThis raises the question, why not be consistent with the non-simple case? Maybe
ts_libraryshould be loaded from@npm//@bazel/typescript:index.bzlIn this case we would still keep
@npm_bazel_typescriptworkspace but most users would not need to know about it. Anyone buliding from sources uses@npm_bazel_typescript//:index.from_src.bzlwhich would stay, but we would delete@npm_bazel_typescript//:index.bzlto be sure the public API is only loaded from one spot.The text was updated successfully, but these errors were encountered: