rollup
wrapper macro for rollup rule
Macros and Functions
rollup
Runs the rollup bundler under Bazel
For further information about rollup, see https://rollupjs.org/
Example usage (generated):
load("@aspect_rules_rollup//rollup:defs.bzl", "rollup")
rollup(
# A unique name for this target.
name = "",
# Label pointing to the linked node_modules target where the `rollup` is linked, e.g
node_modules = None,
)
name
Required.
A unique name for this target.
node_modules
Required.
Label pointing to the linked node_modules target where the rollup
is linked, e.g. //:node_modules
.
rollup
must be linked into the node_modules supplied.
entry_point
Optional. Default: None
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(
name = "bundle",
node_modules = "//:node_modules",
entry_point = "index.js",
)
rollup(
name = "bundle",
node_modules = "//:node_modules",
entry_points = {
"index.js": "bundle"
}
)
If rollup
is used on a ts_library
, the rollup
rule handles selecting the correct outputs from ts_library
.
In this case, entry_point
can be specified as the .ts
file and rollup
will handle the mapping to the .mjs
output file.
For example:
ts_library(
name = "foo",
srcs = [
"foo.ts",
"index.ts",
],
)
rollup(
name = "bundle",
node_modules = "//:node_modules",
deps = [ "foo" ],
entry_point = "index.ts",
)
entry_points
Optional. Default: {}
The bundle's entry points (e.g. your main.js or app.js or index.js).
Passed to the --input
option 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.
srcs
Optional. Default: []
Non-entry point JavaScript source files from the workspace.
You must not repeat file(s) passed to entry_point/entry_points.
deps
Optional. Default: []
Other libraries that are required by the code, or by the rollup.config.js.
args
Optional. Default: []
Command line arguments to pass to Rollup. Can be used to override config file settings.
These argument passed on the command line before arguments that are added by the rule.
Run bazel
with --subcommands
to see what Rollup CLI command line was invoked.
See the Rollup CLI docs for a complete list of supported arguments.
config_file
Optional. Default: "@aspect_rules_rollup//rollup:rollup.config"
A rollup.config.js
file
Passed to the --config
option, see the config doc
If not set, a default basic Rollup config is used.
format
Optional. Default: "esm"
Specifies the format of the generated bundle. One of the following:
amd
: Asynchronous Module Definition, used with module loaders like RequireJScjs
: CommonJS, suitable for Node and other bundlersesm
: Keep the bundle as an ES module file, suitable for other bundlers and inclusion as a<script type=module>
tag in modern browsersiife
: A self-executing function, suitable for inclusion as a<script>
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 onesystem
: Native format of the SystemJS loader
output_dir
Optional. Default: False
Whether to produce a directory output.
We will use the --output.dir
option 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.
silent
Optional. Default: False
Whether to execute the rollup binary with the --silent flag, defaults to False.
Using --silent can cause rollup to ignore errors/warnings 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.
silent_on_success
Optional. Default: False
Even stronger than --silent, defaults to False.
Since the build still emits some texted, even when passed --silent, this uses the same flag as npm_package_bin to supress all output on success.
sourcemap
Optional. Default: "inline"
Whether to produce sourcemaps.
Passed to the --sourcemap
option in Rollup
data
Optional. Default: []
Runtime dependencies to include in binaries/tests that depend on this target.
The transitive npm dependencies, transitive sources, default outputs and runfiles of targets in the data
attribute
are added to the runfiles of this target. They should appear in the '*.runfiles' area of any executable which has
a runtime dependency on this target.
If this list contains linked npm packages, npm package store targets or other targets that provide
JsInfo
, NpmPackageStoreInfo
providers are gathered from JsInfo
. This is done directly from
the npm_package_store_deps
field of these. For linked npm package targets, the underlying
npm_package_store
target(s) that back the links is used. Gathered NpmPackageStoreInfo
providers are propagated to the direct dependencies of downstream linked npm_package
targets.
NB: Linked npm package targets that are "dev" dependencies do not forward their underlying
npm_package_store
target(s) through npm_package_store_deps
and will therefore not be
propagated to the direct dependencies of downstream linked npm_package
targets. npm packages
that come in from npm_translate_lock
are considered "dev" dependencies if they are have
dev: true
set in the pnpm lock file. This should be all packages that are only listed as
"devDependencies" in all package.json
files within the pnpm workspace. This behavior is
intentional to mimic how devDependencies
work in published npm packages.
kwargs
Optional.
Other common arguments such as tags
and visibility