Hacker News Reader

Comment by qbasic_forever | Hacker News Reader

Wow remote caching like Bazel is wild to see in a bundler. It's nice to see someone realize that JS bundling is more or less like compiling and linking in the native code world and we just need to accept it and optimize the hell out of it.

View on HN

speaking of which, is it reasonable to use Bazel instead of webpack?

Bazel is just the infrastructure to run webpack. You'd need to do some work to make webpack's state be cacheable (I dunno what options and such it has for this, maybe it's already there as an option). But if you're looking at Bazel for JS work you probably just want to use the existing and maintained rules for it: https://github.com/bazelbuild/rules_nodejs It's been a while since I last looked at it but I don't think it has any caching for webpack.

I have used bazel (with remote caching) to cache the output of webpack before.

Webpack was driving the typescript compilation and had some plugins/extra codegen steps to run too. I tried to move as much as possible to bazel but I quickly found out the JS ecosystem likes to produce massive balls of muds. Very hard to break down and separate the various steps.

With rules_nodejs you can transform your source with whatever node-based packages you’d like. But be prepared to be more or less entirely on your own to figure out how to make it all work.

Oh and if you create many smaller packages (as is best practice in bazel to get good cache efficiency and parallel builds) be prepared for nonexistent editor/IDE support.

Does it make sense to cache something that takes 1.7 seconds though?

Yes. The nice thing about Bazel is that it'll also be able to do the same caching and cache invalidation across your build graph, so for a decently sized project the savings can be much bigger. I think [0] gives a decent overview.

[0]: https://blog.aspect.dev/rules-ts-benchmarks

Reply on news.ycombinator.com