hammer VS rules_nodejs

NX repositories build slower, drop 1000's of dependencies in your project and has configurations so verbose you need vscode plugins to drive it (also I didn't like that I had to drop in project scaffolding templates to provision new library or application types). I disliked using it so much I went ahead and built this thing https://github.com/sinclairzx81/hammer.

My development workflow is principally based on https://github.com/sinclairzx81/hammer which is esbuild tooling I wrote myself. I think these days, if you're using TS and want the rapid development workflow, anything that is leveraging esbuild or swc under the hood will be a good thing to pick. So Vite ticks the esbuild box.

I use https://github.com/sinclairzx81/hammer. It provides watch / reload workflows for both node and browser development and it scales from single applications into large mono repository projects. It takes one dependency (esbuild) and needs next to no configuration to use.

I gave up on community build tooling and ended up rolling my own tools. https://github.com/sinclairzx81/hammer. It's difficult to find any tooling in the community that does all the things you may need it to. I found by investing the time into developing tools to align to my workflows, I'm free to modify those tools without getting bogged down in ecosystem plugins, or arcane configurations, or whatever else.

If you just want to get going, you can try https://github.com/sinclairzx81/hammer, (disclaimer I wrote this), or https://parceljs.org/ . Both are zero configuration and will allow you to add in frameworks as you need them (rather than relying on the kitchen sink project bootstrappers like create-react-app).

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.

> Is Bazel designed in a way that make it impossible to do JS monorepos well?

Not impossible, but you really need to go all in with it and follow its conventions and practices. See this for the main docs: https://github.com/bazelbuild/rules_nodejs

One thing in particular that doesn't work well in the bazel world is doing your own stuff outside its BUILD.bazel files. If you're used to just npm install and jam some code in your package.json scripts... that doesn't usually work in the bazel world. If you have a lot of logic or tools in your build you'll likely need to go all in and make bazel starlark rules or macros that recreate that logic. Nothing is impossible, but expect to spend time getting up to speed and getting things working the bazel way.

I am using Bazel with rules_nodejs and Webpack. There's an example here.

It is probably possible to build Angular with ts_project(), however you'd need to manually manage the compiler (Angular has its own) and tsconfig (Angular needs special options). ts_library() does a lot of this for you, so I think it would probably be easier to use that than to force yourself onto ts_project(). The canonical Angular example uses ts_library() FWIW: https://github.com/bazelbuild/rules_nodejs/tree/master/examples/angular

https://github.com/bazelbuild/rules_nodejs

Nx is widely used in the Angular community. The Angular team at Google had plans to add Bazel support to the Angular CLI for many years, but the plans didn't materialize. The key folks (e.g., Alex Eagle) working on the effort left Google. Google employees no longer maintain rules_nodejs.