LSlstamour·Dec 22, 2018
For more examples of how to use Bazel with TypeScript or JavaScript, have a look at the code samples I shared in this somewhat unrelated GitHub issue: https://github.com/bazelbuild/rules_typescript/issues/344 (near the bottom I post a few more realistic ones as I experimented with getting webpack working, etc.)
It’s a possibility that some of this post (the TypeScript-Rollup chaining) might have been inspired by this issue (maybe), but as I note in various places there, it’s been tricky to get these three separate projects to work together — rules_nodejs was recently updated to better work with npm with an escape hatch if your node or compiler code cannot be rewritten to allow Bazel to manage your npm modules - but while rules_typescript was rewritten to support rules_nodejs, the otherwise excellent rules_closure is not updated to support
Read the rest
such npm modules.
With few dependencies, and with caching of individual modules, your builds can go lightning fast so you don’t need the watch mode that webpack promotes so heavily. However, ibazel lets you watch your codebase for changes and rebuilds, it just doesn’t inject into your browser and host a web server for you the way webpack does.
I’d say at this point Bazel deserves your experimentation, but until it supports all common JS build tools and scenarios, including linting and IDE integration (there’s some but currently it’s all maintained by groups at Google and not the IDE companies themselves the way other build tools are integrated),so it’ll be a hard sell for most companies to adopt it wholesale, unless, like Dropbox and others, you have a diverse set of programming languages and targets that have shared dependencies that, when changed, you want to trigger partial rebuilds of multiple projects. But the dependencies have to be supported by the rules you’re using and right now, there are some limits to what first-party rules support.
The tools are at a state where a couple people on your team will need to learn Starlark, the Python-like language used in lower-level .bzl files (which can define rules and macros that the BUILD.bazel files that can then refer to) and especially the internals of Bazel including reading source code, a lot of it. This is because the debugger tools are there but not fully bug-free yet, they don’t provide the rich debugging experience you’ve grown to expect with other languages. It’s kind of like debugging and writing Go code early on — you knew once you found the right syntax that it would be obvious but until then it was a lot of experimentation and copying other examples. It’s obvious the teams at Google are pushing Bazel’s development hard, but the Angular team right now is most visible in trying to make things easier for third-party, non-Google development workflows using Bazel. And I’m sure the project will be one to watch in 2019.