Alex Eagle

If the migration is painful then we'll still have webpack sass imports indefinitely and we'll end up having to support them under Bazel too (I suppose maybe in a layer...

we should get @kyliau to weigh in, he added multi_sass_binary and knows the most about Angular CLI feature parity

In Aspect's rules, we solve this by just documenting the public interface, and omit docstrings from the private implementation to avoid duplicating them in both places. This works fine when...

node module resolution by default will walk up the filesystem tree to find dependencies. also, some node programs do a `realpath` to resolve symlinks so they hop outside Bazel's sandbox...

FWIW I've started adding this feature in https://docs.aspect.dev

I think the solution is to give up on macros being a "tidy abstraction" for the underlying rule, and just be honest with users that both exist. In Aspect's rulesets,...

Are the "baseline set of tools" things that are only needed by Bazel users? From my understanding of the tools you have in mind, they would be applicable to developers...

It would require buy-in from language spec as well as the three major implementations to commit to supporting it. @laurentlb might be able to provide guidance if you care enough...

I'd rather not use Closure codegen if we want TypeScript types. Clutz is complex, and I don't want to ever introduce it under Bazel, because I don't know of any...

Under Bazel, we have a `ts_proto_library` rule in http://tsetse.info/api/protobufjs/ts_proto_library.html which generates the `.d.ts` files for typechecking. It's very simple to add this as a dependency of a `ts_library`. This uses...