Rules_nodejs: Add a production bundler rule

Created on 30 Nov 2017  路  7Comments  路  Source: bazelbuild/rules_nodejs

Hey! I'm interested in merging more functionality from https://github.com/dropbox/rules_node into this set of rules.

One nice thing from Dropbox's rules is that we support building either arbitrary JS bundles with node_build and webpack in particular with webpack_build.

For context, we wanted to use bazelbuild/rules_nodejs to build the frontend of our livegrep fork with webpack, but ended up using our open source rules instead because there's no out-of-the-box support for running webpack builds in rules_nodejs (source).

Would it make sense to add those kinds of rules to rules_nodejs? One of the concerns is obviously that developers would have to take care to make their node builds hermetic, and webpack in particular has its own set of pitfalls (e.g. you have to disable symlink following).

Most helpful comment

In search of an officially supported webpack_build rule I see where rollup has made it's way into the repo. However I'm wondering if the OP's question relating to webpack specifically will be addressed?
Are there plans to support webpack ?

All 7 comments

We should definitely have canonical bundling rules. I was just discussing with @filipesilva this morning that we should start looking into a webpack bundling rule.

I'm not sure if rules_nodejs is the right home for all of these rules, for a few reasons:

  • governance: maybe a different team maintains some subset of the rules, or maybe some tool maintainer (eg. webpack) decides to own their own Bazel rules
  • this repo is currently distributed as a WORKSPACE dependency, but I'd prefer most node rules be delivered with NPM so they can be versioned along with the library they expose or depend on (but maybe subdirectories in this repo can be separate npm packages)

On the other hand, as you point out it's easy to write bazel code but hard to make it hermetic, so having a repo with a high quality bar can be a good signal for which rules were reviewed with this in mind. I would be very happy to have you as a collaborator here!

Regardless of where the rules live, I think we should deploy node-based rules for tool foobar at @bazel/foobar. That's a nice analogy for typescript typings - foobar can ship with .d.ts files, but if it only ships .js files, we use @types/foobar as the side-channel. The same way, foobar can ship with BUILD files, but if it doesn't then we use @bazel/foobar as the side-channel.

What are your most recent thoughts on this? Can we expect webpack_build to be part of these set of rules in the near future?

Hi @raliste
@thelgevold has a prototype for a rollup_bundle rule, which I think we could land soon. I imagine the sequence should be:
1) decide what to do about versioning. Right now, rules_nodejs is versioned by the WORKSPACE file which means we can't express things like peerDependencies. If we made a webpack rule, you might desire it to call the version of webpack you install locally. For that, we'd need separate distributions of bazel rules (eg. @bazel/rollup for the rollup_bundle rule)
2) decide whether rules_nodejs is the right repo for all first-party rules (I'm pretty sure but it merits discussion)
3) design review of the rollup_bundle prototype and check in the bits with documentation
4) help the community write bazel rules for more tools.

@gregmagolan is working right now on the rollup_bundle rule. Let's re-purpose this issue to track that (since the OP was for some bundler) and have a separate issue for a webpack bundling rule.

rollup_bundle is now merged and has some basic docs. will be in the next release, or use a commit reference like in alexeagle/angular-bazel-example

In search of an officially supported webpack_build rule I see where rollup has made it's way into the repo. However I'm wondering if the OP's question relating to webpack specifically will be addressed?
Are there plans to support webpack ?

Was this page helpful?
0 / 5 - 0 ratings