1. 6

  2. 2

    I write and maintain a lot of internal Bazel rules, and something I don’t see mentioned a lot is how the “providers” mechanism actually gives you a typed build system for your custom rules. For example, you can return a WizzBang provider from your Wizzy rule, and write another rule that only accepts WizzBang inputs, instead of only operating at the file level (and rules can return multiple types of providers, including built in ones).

    1. 1

      Webpack does a lot of great stuff, but I have not had good luck finding clear explanations of how to extend the internals - there’s a lot of plumbing together random loaders off the internet and hoping.

      Custom providers (combined with the existing support for typescript etc) sounds like it would be a great way out of the webpack configuration morass I’m currently in. Might have to take a deeper dive sometime.

      I found https://docs.bazel.build/versions/master/skylark/rules.html#providers fairly quickly, but not a good high-level explanation of how you might use it for anything but the most simple cases.

      1. 1

        The key concepts are providers (just named key/value containers) returned from custom rules, depsets, DefaultInfo provider, and runfiles (a PITA, but read about them and defaultinfo, particularly from ctx documentation).