Interaction with bazel (where and how?) #5047
martaver
started this conversation in
Feature Requests
Replies: 1 comment
-
I'm also interested in this, NX has some unmatched js tooling, it would be great if it was possible to add it to bazel projects. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
In light of @vsavkin's recent blog post cementing the doom of a bazel-driven NX, I've been pondering the possibility of harmoniously using NX alongside bazel.
NX's DX and monorepo management tools are second to none...
But you see, from where I stand (and I could be wrong about this) it looks like bazel does a lot of things well for prod builds that NX doesn't (and probably shouldn't). Of particular note are bazel's containerisation and kubernetes rules. In contrast, NX is kind of difficult when working with containers - either you end up installing all node_modules for each image, or you sacrifice hermeticity by copying pre-built artifacts into images.
And of course add to that the immensity of tools and cross-language capabilities that bazel brings to the table. As painful as parts of it are, it seems that bazel isn't really a tool you're ever going to 'out-grow'.
At least that's what got me thinking... what if NX could be considered just another build tool, like webpack, responsible for its own (node/js/ts) part of the monorepo, and bazel for the most part took a back seat and just acted as a remote control?
To this end, I created an NX repo with a react app and shared lib and decorated it with some basic bazel rules.
I reference NX with a
nodejs_binary
and use agenrule
to run nx build for the app and lib, to limited success.The app's build fails, unable to resolve the dependency on lib. Clearly, in a sandboxed environment there are some challenges - either you include the full source code of the lib, and allow webpack to re-build & bundle it, or I should find a way to allow webpack to resolve the lib's outputs in bazel-out.
The overall build is also far slower in bazel than running with pure NX... (it takes approx 30s to fail the bazel build, vs < 10s for the successful nx build). I suspect this is due to something bazel is doing with node_modules.
At any rate, before going any deeper down the rabbit hole, I thought I would reach out for some advice and opinions from the pros, since the NX team already has had some experience with bazel and its peculiarities.
Is there any fantasy to this concept?
Where would you hand over control to bazel and vice versa? E.g. would you run one NX build for the whole repo, or use a BUILD file in each app/lib?
How would you handle deps between libs and apps?
How could bazel best encapsulate NX? A persistent worker maybe?
How could NX's distributed caching interact with bazel's? If at all?
I'd love it if we got some solid discussion and opinions on this. It'd be great if NX and bazel weren't mutually exclusive choices.
Beta Was this translation helpful? Give feedback.
All reactions