Bazel and Javascript Ecosystem

[LavaToaster]

👋 I'm attempting to make sense around the target bazel audience. Is it only for well established companies with resources/funding and those with an enthusiast vision for a hermetic build system, or does it want to push for greater change in the larger ecosystem and increase adoption of a hermetic build system?

For established companies, It makes sense to me when I look at it for the purpose of standardising the build and ci systems with numerous different language requirements, then connecting it all up for end to end visibility when something changes. They also have the resources to deal with issues that arise with build system incompatabilities.

For startups and personal projects, it doesn't really add up for me. At least not under my own experience with primarly with rules_js.

Why spend the effort to set up Bazel and your js framework of choice, which depending your understanding of how it wants to be built, may take a few hours or days/weeks depending on your skill level. When the alternatives in javascript simply don't require as much work, and everything gets "cleanly" wrapped being a simplified cli utility?

Looking at life without bazel. Practically every tool—not only those linked to monorepo—comes with generators or templates to get you up and running in pretty much 5 minutes. For example let's say I want a next.js application and an nx monorepo? The home page of nx.dev front and center shows a command you can copy, and when ran asks you a few questions and you're good to go - The basic repository structure and files have been setup. You could search the docs on NX for NextJS, or if you google nx and nextjs, the first result is a link back to the nx site (https://nx.dev/packages/next), the page shows in clearly defined areas how to set up the plugin, how to generate the app and how to run it.

Condensed it looks like:

$ pnpx create-nx-workspace
$ pnpm add —dev @nrwl/next 
$ pnpm nx g @nrwl/next:app my-new-app 

Only 3 terminal commands and hey presto you have a complete repository setup and you're ready to rumble. You're only one command away from running the application in development mode pnpm nx serve my-new-app.

If you constrast the above to how you would do it with bazel. You would check if there's an example online, maybe in the aspect-build/bazel-examples repo. If you can't find one you'll need to break down the framework you've chosen and understand what the CLI is doing behind the scenes. As this is super important information to feed into bazel. Some frameworks like SveleKit which are easy outside of a bazel environment, are super tough to work in a bazel environment. Then separately configure the building side of the application from the dev server side of it, and anything else in between. Depending on your flavour of bazel purity perhaps you try extracting responsibility of certain aspects from the framework to give to bazel, for example compiling ts to js or representing static assets as different bazel packages.

It just feels like everything feels needs a do it yourself attitude, and because of that it takes significantly longer and you fight what feels like a losing battle against the javascript ecosystem along the way.

I don't really know where to go from here. I don't mind dealing with these problems at work, but I don't like dealing with them out of work. I do want consistency on tooling I use in and out of the workplace where possible though and I get that it's certainly my own perogative to just not use bazel for personal projects. I'm writing this whole spiel because I want to push for better.

So...

How do we go about improving this experience?

How can we make the DX as good as if not better than what javascript ecosystem currently has? Is that even achievable or a goal that we as a community should have?

Is it acceptable to constantly fight and patch the ecosystem?

• Bazel itself is being pedantic about correctness vs expected behaviour when encountering package.json's that work under node but can't be read under bazel json.decode is too strict; fails on duplicate keys bazelbuild/bazel#15605

  This isn't even something fixable in userland without writing our own json parser in starlark.

• Sure hoist=false is "correct", but it's non trivial to identify and sort out issues that occur from it.

• In general package authors will see bazel in the wrong as it works for 99% of their users just how they intend. If they have no desire to support bazel that means another workaround and patch that needs to be maintained. As well as someone with bazel experience having a deep understanding of that package. (Granted I think this mostly applies to the modern frameworks)

Is this just a matter of time and these frustrations are just par for the course of being an early adopter of bazel within the rules_js ecosystem? (I appreciate that rules_nodejs has been around for a while, but I'm specifically speaking around the idea that most of the problems bazel had with JS go away with rules_js but not completely)

... End of post/rant/whatever this was. I hope you're having a fantastic day

TL;DR How can we improve the developer experience of working with bazel?

Slack thread: https://bazelbuild.slack.com/archives/CEZUUKQ6P/p1676079172276869

[enigmatix]

Thus neatly describes issues we have with Javascript and Bazel at our company. We don’t have a dedicated Bazel engineer, and the surface area you need to be across to make it work is definitely prohibitive for a mid-sized company (we’re 180 people with ~80 engineers). Not adding anything, just replying so I selfishly get notified of responses :D