Rollup rules for Bazel
The Rollup rules run the Rollup.JS bundler with Bazel.
Installation
Add the @bazel/rollup npm package to your devDependencies in package.json.
Installing with self-managed dependencies
If you didn’t use the yarn_install or npm_install rule, you’ll have to declare a rule in your root BUILD.bazel file to execute rollup:
# Create a rollup rule to use in rollup_bundle#rollup_bin
# attribute when using self-managed dependencies
nodejs_binary(
name = "rollup_bin",
entry_point = "//:node_modules/rollup/bin/rollup",
# Point bazel to your node_modules to find the entry point
node_modules = ["//:node_modules"],
)Usage
The rollup_bundle rule is used to invoke Rollup.js on some inputs.
The API docs appear below.
Typical example:
load("@npm//@bazel/rollup:index.bzl", "rollup_bundle")
rollup_bundle(
name = "bundle",
srcs = ["dependency.js"],
entry_point = "input.js",
config_file = "rollup.config.js",
)Note that the command-line options set by Bazel override what appears in the rollup config file.
This means that typically a single rollup.config.js can contain settings for your whole repo,
and multiple rollup_bundle rules can share the configuration.
Thus, setting options that Bazel controls will have no effect, e.g.
module.exports = {
output: { file: 'this_is_ignored.js' },
}Output types
You must determine ahead of time whether Rollup needs to produce a directory output.
This is the case if you have dynamic imports which cause code-splitting, or if you
provide multiple entry points. Use the output_dir attribute to specify that you want a
directory output.
Rollup’s CLI has the same behavior, forcing you to pick --output.file or --output.dir.
To get multiple output formats, wrap the rule with a macro or list comprehension, e.g.
[
rollup_bundle(
name = "bundle.%s" % format,
entry_point = "foo.js",
format = format,
)
for format in [
"cjs",
"umd",
]
]This will produce one output per requested format.
Stamping
You can stamp the current version control info into the output by writing some code in your rollup config. See the stamping documentation.
By passing the --stamp option to Bazel, two additional input files will be readable by Rollup.
- The variable
bazel_version_filewill point to the path of Bazel’s “volatile-status.txt” file which contains statuses that change frequently; such changes do not cause a re-build of the rollup_bundle. - The variable
bazel_info_filewill point to the path of Bazel’s “stable-status.txt” file which contains statuses that stay the same; any changed values will cause rollup_bundle to rebuild.
Both bazel_version_file and bazel_info_file will be undefined if the build is run without --stamp.
Note that under
--stamp, only the bundling is re-built, but not all the compilation steps. This avoids a slow cascading re-build of a whole tree of actions.
To use these files, just write JS code in the rollup.config.js that reads one of the status files and parses the lines. Each line is a space-separated key/value pair.
// Parse the stamp file produced by Bazel from the version control system
let version = '<unknown>';
if (bazel_info_file) {
const versionTag = require('fs')
.readFileSync(bazel_info_file, {encoding: 'utf-8'})
.split('\n')
.find(s => s.startsWith('STABLE_GIT_COMMIT'));
if (versionTag) {
version = 'v' + versionTag.split(' ')[1].trim();
}
}Debug and Opt builds
When you use --compilation_mode=dbg, Bazel produces a distinct output-tree in bazel-out/[arch]-dbg/bin.
Code in your rollup.config.js can look in the environment to detect if a Debug build is being performed,
and include extra developer information in the bundle that you wouldn’t normally ship to production.
Similarly, --compilation_mode=opt is Bazel’s signal to perform extra optimizations.
You could use this value to perform extra production-only optimizations.
For example you could define a constant for enabling Debug:
const DEBUG = process.env['COMPILATION_MODE'] === 'dbg';rollup_bundle
Runs the Rollup.js CLI under Bazel.
rollup_bundle(name, args, config_file, deps, entry_point, entry_points, format, link_workspace_root, node_context_data, output_dir, rollup_bin, rollup_worker_bin, silent, sourcemap, srcs, supports_workers)
ATTRIBUTES
| Name | Description | Type | Mandatory | Default |
|---|---|---|---|---|
| name | A unique name for this target. | Name | required | |
| args |
Command line arguments to pass to rollup. Can be used to override config file settings.
These argument passed on the command line before all arguments that are always added by the
rule such as --output.dir or --output.file, --format, --config and --preserveSymlinks and
also those that are optionally added by the rule such as --sourcemap.
See rollup CLI docs https://rollupjs.org/guide/en/#command-line-flags for complete list of supported arguments.
|
List of strings | optional | [] |
| config_file | A rollup.config.js file Passed to the --config See https://rollupjs.org/guide/en/#configuration-files If not set, a default basic Rollup config is used. | Label | optional | @npm//@bazel/rollup:rollup.config.js |
| deps | Other libraries that are required by the code, or by the rollup.config.js | List of labels | optional | [] |
| entry_point |
The bundle's entry point (e.g. your main.js or app.js or index.js).
This is just a shortcut for the entry_points attribute with a single output chunk named the same as the rule.
For example, these are equivalent:
rollup_bundle is used on a ts_library, the rollup_bundle rule handles selecting the correct outputs from ts_library.
In this case, entry_point can be specified as the .ts file and rollup_bundle will handle the mapping to the .mjs output file.
For example:
|
Label | optional | None |
| entry_points |
The bundle's entry points (e.g. your main.js or app.js or index.js).
Passed to the [--input option](https://github.com/rollup/rollup/blob/master/docs/999-big-list-of-options.md#input) in Rollup.
Keys in this dictionary are labels pointing to .js entry point files.
Values are the name to be given to the corresponding output chunk.
Either this attribute or entry_point must be specified, but not both.
|
Dictionary: Label -> String | optional | {} |
| format |
"Specifies the format of the generated bundle. One of the following:
- amd: Asynchronous Module Definition, used with module loaders like RequireJS
- cjs: CommonJS, suitable for Node and other bundlers
- esm: Keep the bundle as an ES module file, suitable for other bundlers and inclusion as a tag in modern browsers
- iife: A self-executing function, suitable for inclusion as a tag. (If you want to create a bundle for your application, you probably want to use this.)
- umd: Universal Module Definition, works as amd, cjs and iife all in one
- system: Native format of the SystemJS loader
|
String | optional | "esm" |
| link_workspace_root | Link the workspace root to the bin_dir to support absolute requires like 'my_wksp/path/to/file'. If source files need to be required then they can be copied to the bin_dir with copy_to_bin. | Boolean | optional | False |
| node_context_data |
Provides info about the build context, such as stamping.
By default it reads from the bazel command line, such as the --stamp argument.
Use this to override values for this target, such as enabling or disabling stamping.
You can use the node_context_data rule in @build_bazel_rules_nodejs//internal/node:context.bzl
to create a NodeContextInfo.
The dependencies of this attribute must provide: NodeContextInfo
|
Label | optional | @build_bazel_rules_nodejs//internal:node_context_data |
| output_dir |
Whether to produce a directory output.
We will use the [--output.dir option](https://github.com/rollup/rollup/blob/master/docs/999-big-list-of-options.md#outputdir) in rollup
rather than --output.file.
If the program produces multiple chunks, you must specify this attribute.
Otherwise, the outputs are assumed to be a single file.
|
Boolean | optional | False |
| rollup_bin | Target that executes the rollup binary | Label | optional | @npm//rollup/bin:rollup |
| rollup_worker_bin | Internal use only | Label | optional | @npm//@bazel/bin:rollup-worker |
| silent | Whether to execute the rollup binary with the --silent flag, defaults to False. Using --silent can cause rollup to [ignore errors/warnings](https://github.com/rollup/rollup/blob/master/docs/999-big-list-of-options.md#onwarn) which are only surfaced via logging. Since bazel expects printing nothing on success, setting silent to True is a more Bazel-idiomatic experience, however could cause rollup to drop important warnings. | Boolean | optional | False |
| sourcemap |
Whether to produce sourcemaps.
Passed to the [--sourcemap option](https://github.com/rollup/rollup/blob/master/docs/999-big-list-of-options.md#outputsourcemap") in Rollup
|
String | optional | "inline" |
| srcs | Non-entry point JavaScript source files from the workspace. You must not repeat file(s) passed to entry_point/entry_points. | List of labels | optional | [] |
| supports_workers | Experimental! Use only with caution. Allows you to enable the Bazel Worker strategy for this library. When enabled, this rule invokes the "rollup_worker_bin" worker aware binary rather than "rollup_bin". | Boolean | optional | False |