[RFC] integration with bazel.build

[alexeagle]

Bazel (https://bazel.build) is an incremental, full-stack build and test tool from Google. It is polyglot and works with most languages. I think there's an opportunity for Bazel and SWC to benefit each other.

SWC is a natural fit with Bazel. Bazel does best when it orchestrates the work of many short-lived compiler processes.
NodeJS is not a good runtime for such tools, because it is an interpreter, and is only fast after the code has been running for a while and is Just-In-Time optimized.
SWC is fast from the beginning since it is compiled to optimized machine code.
This makes it a particularly better choice under Bazel for tools like tsc or babel, which have to have clumsy workarounds to run in a "watch-mode" for performance.

At the same, Bazel is a good fit for SWC too. It has still-developing features like a bundler,
but you might want to use something else as a bundler, like esbuild.
Bazel's agnostic unix-pipeline-style composition of tools allows you to mix-and-match the best parts of
the JS ecosystem, regardless what language they run on.
With Bazel, you won't need to figure out SWC's plugin infrastructure.
You can have SWC do what it's good at, and not even have it involved with the rest.

I already wrote the Bazel plugin (called "rules") https://github.com/aspect-build/rules_swc and am rolling out to some clients, so there's not a lot of work to do here 😁

[alexeagle]

Some things that would make Bazel integration better:

1. we could add documentation on the swc site or Bazel nodejs site that describes how Bazel is one option for orchestrating a large-scale, multi-language build and test. Help users discover this combination and know how to get most value from it.

2. allow the node binding file to be supplied directly, rather than assume it was installed via the trick of @swc/core depending on a bunch of platform-specific npm packages. Bazel's "toolchain" concept allows users to specify where they want this to come from, including building the Rust sources locally. We suggest that if an environment variable is passed like SWC_BINDING then this is used as the path to the .node binding file to require. That's currently used in our plugin: https://github.com/aspect-build/rules_swc/blob/main/swc/private/swc_core.patch

3. Supply a pure-Rust posix process API. Bazel always spawns a subprocess when running a plugin. Currently we have to fetch a Node.js interpreter and take the perf hit of running one for each swc invocation. If we make a separate process for each .ts input file then that's a lot of wasted memory used to run V8 wrappers around swc. This could be a full-featured replacement for the javascript CLI like Reimplement CLI in rust #1589 but that's not strictly needed here. As long as there's some way for us to execute the rust bindings for compiling a .ts file as a process, it's sufficient.

4. On releases, include SHA 256/384/512 integrity hashes for each .node file. Bazel's downloader uses those to manage its cache, and without publishing them it seems like we need to download all the files to calculate shasum's in our script that mirrors available releases into Bazel. Slow workaround is https://github.com/aspect-build/rules_swc/blob/main/scripts/mirror_releases.sh#L22-L23

@gregmagolan has some other observations around the command-line API, in particular that only a single file or a single directory can be transpiled

[kwonoj]

I personally would like to support this. I'd frame this as somewhat meta like supporting integration with build tools in general where its characteristics meets well with what SWC can do best. Each individual support may require some discussions if we'd like to support & how, but most of the items in existing list seems non-breaking, good to have changes.

[kdy1]

I'm with this. I don't know well about Bazel, but the changes you mentioned will not harm swc users badly.

[kwonoj]

Yes, indeed.

1. this is doc change, and I think bazel side doc mentioning best practices for swc would be good (otherwise swc have to describe general bazel concepts in its docs)
2. probably ok? as long as we have proper contract (env name, etcs) for this.
3. this would require some challenges, as having rust-only cli means potentially we need to build swc/cli contains swc/core as non node bindings. I feel this may worth separate discussions about how.
4. this should be harmless and anyone will gain if someone want to verify binaries for other purpose.

So the potential work would not be huge I guess.

[alexeagle]

Next one that makes Bazel usage harder: the output paths with --out-dir are deeply nested and hard to use.
#3028

[alexeagle]

@kwonoj ☝🏻