0.33.0

Toolchain support

The Node.js binary is now referenced as a Bazel toolchain, which means it's not tied to the architecture of the host where Bazel is running. This means on a Mac or Windows you can now

• build a docker image on a mac
• use remote build execution

Thanks to @Globegitter for contributing this!

See CHANGELOG.md for detailed release notes

0.32.2

This release fixes interactions with the new managed_directories Bazel feature. It also resolves a long standing worker mode issue with ts_library (rules_typescript#381).

ts_library @types

We improved how ts_library consumes @types npm packages. If you are using bazel managed deps, which is the default for ts_library unless you override the node_modules attribute with a filegroup, bazel will now only include the @types packages that are included in fine grained deps such as @npm//@types/typescript in the a compilation unit. This will also work if you use the medium grained dep @npm//@types or coarse grained deps such as node_modules = "@npm//:node_modules" which both include all @types packages. You can still put whatever values you like in your tsconfig coompileOptions.types array for editor support but ts_library will now ignore this value if you are using bazel managed deps.

Note: this change resolves rules_typescript#381, however, if you opt out of bazel managed deps you may still run into this issue.

npm packages that publish BUILD.bazel or WORKSPACE files

npm packages should contain JavaScript, not TypeScript. For this reason, we expect that package maintainers who use Bazel should not publish the build configuration files, as downstream users are not expected to build the package from sources. However, some packages do contain these files (rxjs does prior to 6.5.0 for example).

If these files appear in the node_modules tree, they change how files in the packages are referenced during the build. Bazel enforces that references are scoped to the "package" containing the file, and a "package" is defined by the presence of a BUILD.bazel file.

When installing dependencies using the yarn_install or npm_install repository rules, we can automatically move these files out of the way by prefixing their filename with underscore (_). See https://bazelbuild.github.io/rules_nodejs/npm_install/npm_install.html for documentation.
However, due to a bug (bazelbuild/bazel#8487) in Bazel, when the node_modules is recreated outside of Bazel, these BUILD.bazel files are reintroduced, and Bazel does not know to re-run the code that moves the files.

We publish a new package @bazel/hide-bazel-files as a workaround. If added as a dependency or transitive dependency in your project, this runs a postinstall step to rename any BUILD.bazel files in the node_modules to _BUILD.bazel.

Breaking Changes

• Now depends on Bazel 0.27 or greater in order to get partial fix for bazelbuild/bazel#8487. Typical usage is to update the @bazel/bazel dependency in your package.json
• BUILD.bazel files are no longer generated inside of the node_modules directory.
  If these files are found in node_modules you will get an error like npm package 'ansi-regex' from @npm yarn_install rule has a Bazel BUILD file 'BUILD.bazel'. Use the @bazel/hide-bazel-files utility to hide these files.
  This means that previously-generated files need to be removed.
  Run rm -rf node_modules and bazel clean --expunge to remove generated BUILD.bazel files in your node_modules.
• Because BUILD.bazel files are no longer generated under node_modules, the node_modules folder is now a single Bazel package so any labels that point to files within bazel managed deps in previous versions, such as @npm//node_modules/zone.js:dist/zone.js, must now be changed to @npm//:node_modules/zone.js/dist/zone.js. The colon position has changed now that node_modules is a single Bazel package.

See CHANGELOG.md for a list of bugs fixed and features added.

0.32.1

chore(release): 0.32.1

0.32.0

chore(release): 0.32.0

0.31.1

• Compatibility changes for future Bazel 0.27.0 release
• jasmine_node_test macro now passes templated_args through to nodejs_test

BREAKING CHANGES:

• @bazel/typescript restricted an API return type which breaks ngc-wrapped like so: TypeError: digests.entries(...) is not a function or its return value is not iterable
  Update to @angular/bazel@8.1.0-next.1 to pick up the fix (when Angular 8.0.1 is released, the fix will be there too)

• -preserve-symlinks-main flag is now set along with --preserve-symlinks flag when node version is 10.2.0 or greater. If using a vendored_node version older than 10.2.0, you must specify the node_version you are using so that this flag is not set. Setting the flag on an older version of node will lead to an error.

• The entry_point attribute of nodejs_binary, nodejs_test and rollup_bundle has been changed to a label from a string.

Updating your BUILD files should be trivial in most cases.

For example:

nodejs_binary(
    name = "example",
    entry_point = "workspace_name/src/main.js",
    ...
)

would become either,

nodejs_binary(
    name = "example",
    entry_point = ":main.js",
    ...
)

or

nodejs_binary(
    name = "example",
    entry_point = "//src:main.js",
    ...
)

if using relative or absolute label syntax respectively.

If the entry_point was referencing a .js file that is the output of a ts_library rule then you now must point the entry_point to the corresponding .ts and the affected rules will use the corresponding .js output.

For example:

ts_library(
    name = "main",
    srcs = ["main.ts"],
)

nodejs_binary(
    name = "bin",
    data = [":main"],
    entry_point = "my_workspace/some_module/main.js",
)

becomes,

ts_library(
    name = "main",
    srcs = ["main.ts"],
)

nodejs_binary(
    name = "bin",
    data = [":main"],
    entry_point = "//my_workspace/some_module:main.ts",
)

For more information and examples see https://bazelbuild.github.io/rules_nodejs/node/node.html#nodejs_binary.entry_point and https://bazelbuild.github.io/rules_nodejs/rollup/rollup_bundle.html#rollup_bundle.entry_point.

0.30.2

New @bazel/create package simplifies the quickstart experience.

Just yarn create @bazel or npm init @bazel to create a Bazel + JavaScript workspace.

Other changes

• We now mirror the @bazel/buildozer package. This is a program and Go library for machine-editing BUILD.bazel files, and we plan to use it to automate migrations when we make breaking changes in the future.
• Fixed an npm_install crash where Bazel reports a target cycle, looks like EXPAND_TEST_SUITES com.google.devtools.build.lib.pkgcache.TestFilter@e17a1
• `@bazel/karma: fix static_files overwrite files specified in dependencies
• @bazel/bazel no longer warns about running from a global install

0.30.1

rel: 0.30.1

0.30.0

BREAKING CHANGES:

• We depend on Bazel 0.26 which has a new "managed directories" feature. This was added specifically to improve the integration with external package managers npm and yarn.

• we now use the same node_modules directory under Bazel as your package manager does when run locally.
  See https://github.com/bazelbuild/rules_nodejs/wiki#migrating-to-rules_nodejs-030 for migration instructions.

• yarn_install & npm_install attribute excluded_packages is now deprecated. Now that yarn_install and npm_install use node_modules in the user's folder by default, this attribute is no longer useful since large packages such as @bazel/bazel will no longer be installed twice.

• yarn_install & npm_install attribute data is no longer needed, unless you've symlink_node_modules = False. This is because Bazel runs the package manager in your project directory so all files are available without explicit declaration.

• npm_install#package_lock_json attribute is now mandatory

0.29.2

Add a terser compile-time constant for Angular

0.29.1

Version bumps for dependencies

Remove the extra yarn_install needed by the web_package rule