fix(deps): update @bazel/typescript and Node.js rules to v2 #614
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
^1.7.0
->^2.0.0
Release Notes
bazelbuild/rules_nodejs
v2.0.0
Compare Source
It's been about 7 months since we released 1.0 and we'd like to be on a twice-yearly major release cadence.
We've been working hard to make cleanups to our APIs, so following our semantic versioning policy it is time for these breaking changes to roll out to you. We have done our best to make it convenient for you to upgrade.
To upgrade, edit your
WORKSPACE
:and update all your @bazel-scoped npm packages.
Where possible, we have added notes about additional code changes you need to make in the 2.0 upgrade wiki. These should make it quicker for you to get upgraded.
Branching
We have decided to stop using a branch named
master
. Our new branching strategy is:1.x
is code from releases prior to 2.0stable
will have 2.x releasesWe are sorry that
master
was our default for so long. This caused a bunch of confusion because examples were updated with 2.0 breaking changes, but those releases were not tagged as "latest" yet.We look forward to support from GitHub to redirect all links with
master
to the new default branch, at which time we'll remove the branch and update Pull Requests that target it.New features
Cypress integration testing
There is a new custom
cypress_web_test
rule in the@bazel/cypress
package.See the example added in https://github.com/bazelbuild/rules_nodejs/tree/2.0.0/examples/cypress
Thanks to @mrmeku for this awesome contribution!
React and Vue examples
React users should start from https://github.com/bazelbuild/rules_nodejs/blob/2.0.0/docs/examples.md#react as there are multiple ways you can build your React app under Bazel. The rules_nodejs team expects to invest more here soon.
A very basic Vue example is available as well. Thanks to @Smokrow for getting this started.
generated_file_test rule
Typically under Bazel you should leave the outputs in the
bazel-out
folder and reference them there.However there are some cases where you really need to check generated files into your repo, for example:
want code reviewer to see the change in the generated file, like a golden file for tests that assert on the generated content
strange-shaped bootstrap problems where you can't run Bazel before referencing the output
See the docs for
generated_file_test
Relatedly, @longlho added an example for using Jest with snapshot files
stdout/stderr/exit code capture
When running a tool to produce outputs, you typically use the
npm_package_bin
rule, or an auto-generated rule provided from an npm package in theindex.bzl
file.You can now use
stdout = "some_label"
orstderr = "other_label"
and the stdout and stderr of the program will be redirected into the file you specify. You can then depend on these in another downstream rule. Similarly you can capture the exit code withexit_code_out = "some_label"
, in this case the action will return zero (success) and you can depend on the exit code from another target.This is useful for interacting with a tool that only produces output on stdout rather than provide a
--outfile
-style flag to let you control the path.It can also be useful to redirect spammy writes so they don't clog the Bazel log, or transform the outputs with another tool.
Thanks to @mattem for contributing this!
TypeScript (ts_project)
ts_project now has additional attributes to match TypeScript. Use
out_dir
to specify where JS is written (allows you to write multiple .js outputs for each .ts input, for example different module formats). Usedeclaration_dir
to specify output.d.ts
locations androot_dir
to specify a subdirectory of the source package.There is a new output_group for "types" so you can depend on just the .d.ts outputs, see https://github.com/bazelbuild/rules_nodejs/blob/2.0.0/packages/typescript/test/ts_project/output_group/BUILD.bazel
It also correctly handles
.json
inputs, adding them to the appropriate output sets along with emitted.js
files.See https://github.com/bazelbuild/rules_nodejs/tree/2.0.0/packages/typescript/test/ts_project/json
Thanks to @longlho and @mistic for contributing these!
Breaking changes
Loading custom rules from npm packages
Generated rules have always been loaded from the package directly. For example you load Babel like this:
However custom rules like
ts_library
have been loaded from a non-standard repository like@npm_bazel_typescript
. Not only was this inconsistent, it caused problems:install_bazel_dependencies
call inWORKSPACE
, which happens for all builds whether they depend on JS outputs or not. So in a monorepo, backend engineers are waiting for npm installs.@npm
, you had to override attributes like thecompiler
onts_library
. This made it annoying to have more than one yarn_install/npm_install.Instead here is the new behavior:
npm_install(name="my_deps")
in yourWORKSPACE
then you should always load from it,load("@​my_deps//@​bazel/typescript:index.bzl)"
- see the 2.0 wiki for a command that automates thisinstall_bazel_dependencies
throws a warning since it's no longer needed.package.bzl
and use labels like@build_bazel_rules_nodejs//packages/pkg
. See the exampleBuilt-ins
rules_nodejs now requires Bazel 2.1 or greater. This adds support for
.bazelignore
in external repositories. As a result, thehide_build_files
attribute was removed frompkg_npm
, andalways_hide_bazel_files
was removed from yarn_install and npm_install. These are no longer needed since 1.3.0. The@bazel/hide-build-files
package is now deprecated and no longer published.The
install_source_map_support
attribute is removed fromnodejs_binary
.source-map-support
is vendored in at/third_party/github.com/source-map-support
so it can always be installed. Simply remove any usage of that attribute.jasmine
is now a peerDependency of@bazel/jasmine
. This lets you pick your own Jasmine version. Fix it withyarn add -D jasmine jasmine-core
jasmine_node_test
no longer has thecoverage
attribute. We plan to publish updated docs for runningbazel coverage
on any arbitrary node program; follow user docs for bazel coverage usage bazel-contrib/rules_nodejs#1885Rollup
The peerDependency range on Rollup is now >=2.3.0 as Rollup introduced an API to parse the command line which we want to depend on.
Importing from the workspace root
We used to assume that your workspace name (defined with
workspace(name="foo")
in/WORKSPACE[.bazel]
) matches the name of a package you publish to npm. Therefore that workspace name was always importable, likeimport from 'foo/path/to/thing'
This is now opt-in. Simply put an
pkg_npm
rule in your root/BUILD[.bazel]
file withpackage_name = "foo"
to declare that the root directory is an npm package named "foo".Any nodejs_binary/nodejs_test processes with the linker enabled (--nobazel_patch_module_resolver is set) that were relying on standard node_module resolution to resolve manfest file paths such as
my_workspace/path/to/output/file.js
must now use the runfiles helper such as.Previously:
With runfiles helper:
Linking
Similar to the
npm link
workflow, we run a programbefore node that creates symlinks to packages you depend on.
This is now enabled for all programs. If this breaks you, you can escape from this feature for now with a flag on
nodejs_binary
,nodejs_test
, ornpm_package_bin
:templated_args = ["--nobazel_run_linker"]
We also run a
--require
script to patch the node environment to understand Bazel's symlink layout. If this breaks you, you can usetemplated_args = ["--nobazel_node_patches"]
to escape from that feature.Angular
For most applications, we no longer recommend depending on the
@angular/bazel
package. The only rule needed from it wasng_module
which you can replace with the faster equivalentts_library(use_angular_plugin=True)
However if you publish Angular components to npm you may still want to use the
ng_package
rule. We have updated our examples to show this.If you use Angular's old "View Engine" compiler/runtime, you'll have to stay on version 9.0.5 to keep Bazel compatibility.
More updates for Angular + Bazel users are described in this blog post
For Rules Authors
This section is only relevant if you maintain your own custom Bazel rule implementation (not macros)
If you use the generated nodejs_binary or nodejs_test rules in the npm
workspace, for example @npm//typescript/bin:tsc, your custom rule must now link the
node_modules directory into that process. To do this, you may need to change from
ctx.actions.run
to ourrun_node
helper, as this sets up the action to run the linker program first.See bazel-contrib/rules_nodejs@007a8f6#diff-e4cc9aaa33fff1541c61f173d77fe8d0
We removed the
provide_declarations()
factory function for DeclarationInfo. Usedeclaration_info()
instead.Added JSModuleInfo provider as the common provider for passing & consuming javascript sources and related files such as .js.map, .json, etc.
For 1.0 we added JSNamedModuleInfo and JSEcmaScriptModuleInfo which were provided by ts_library and consumed by rules that needed to differentiate between the two default flavors of ts_library outputs (named-UMD & esm). We left out JSModuleInfo as its use case was unclear at the time.
For 2.0 we're adding JSModuleInfo as generic javascript provided for the rules_nodejs ecosystem. It is not currently opinionated about the module format of the sources or the language level. Consumers of JSModuleInfo should be aware of what module format & language level is being produced if necessary.
The following rules provide JSModuleInfo:
The following rules consume JSModuleInfo:
Changelog
See https://github.com/bazelbuild/rules_nodejs/blob/2.0.0/CHANGELOG.md for pointers to commits and pull requests in this release.
Renovate configuration
📅 Schedule: At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻️ Rebasing: Renovate will not automatically rebase this PR, because other commits have been found.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by WhiteSource Renovate. View repository job log here.