hel VS rules_nodejs

Toolchain-independent sdk-based module federation hel-micro

helux is a zhuang't that encourages service injection and supports responsive changes to react. Its predecessor is concent (a high-performance state management framework for Vue-like development experience), but concent itself needs to be compatible with class and function to maintain a consistent syntax, and for its setup function, internal The amount of code is too large. After compression, there are more than 70 more than KB, and the API is exposed too much, which leads to a sharp increase in learning difficulty. It was originally designed as a lightweight react data flow solution that encourages service injection, supports responsive changes, and supports dependency collection.

It is highly recommended to try hel micro(https://github.com/tnfe/hel) in turbo，cause hel-micro is a runtime module federation SDK which is unrelated to tool chain, so any tool system can access module federation technology in seconds .

The module federation can play an even more powerful role in the construction of super-large js projects, and the module deployment efficiency and sharing efficiency of giant applications will be easily solved. At the same time, it is matched with micro-container related frameworks (such as wujie, rame), etc., to ensure your isolation operation requirements. Escort, welcome to star hel-micro, understand and use it.

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.