build: bump @bazel/jasmine from 2.2.1 to 3.0.0

[dependabot]

Bumps @bazel/jasmine from 2.2.1 to 3.0.0.

Release notes

Sourced from @bazel/jasmine's releases.

3.0.0

Following our usual 6-month cadence for major releases, here is 3.0.0 just in time for your winter vacation! As usual, we've done our best to make breaking changes that improve the long-term health of the project and which are easy to adopt. Give us feedback in the #javascript channel on slack.bazel.build

👏🏻 Thanks to our awesome contributors for this release! 👏🏻

@mistic, @lukasholzer, @duarten, @jbedard, @mrmeku , @opelhoward , @Schibum , @mattinsler , @JiaLiPassion , @fredrikredflag , @KrauseStefan , @comius , @lovepocky , @tylerhou and @OlaviSau

To upgrade:

http_archive(
    name = "build_bazel_rules_nodejs",
    sha256 = "6142e9586162b179fdd570a55e50d1332e7d9c030efd853453438d607569721d",
    urls = ["https://github.com/bazelbuild/rules_nodejs/releases/download/3.0.0/rules_nodejs-3.0.0.tar.gz"],
)

and upgrade your @bazel-scoped npm packages (you'll get an error when installing 2.x version packages with rules_nodejs 3.x)

Finally, read the 📚 Migration instructions from 2.x for breaking changes: https://github.com/bazelbuild/rules_nodejs/wiki#migrating-to-30

BREAKING CHANGES

Stricter installs

For both yarn_install and npm_install we now fail if the lockfile is out-of-date, rather than update it. This assumes you'll use the tooling to manually update the lockfile as needed.

yarn_install now passes --frozen_lockfile by default, but you can use yarn_install(frozen_lockfile = False) to go back to the old behavior.

npm_install now has an attribute npm_command that defaults to ci but you can set it to install to go back to the old behavior.

We also flipped the default for strict_visibility on these two rules. This prevents you adding a Bazel dependency on a library that isn't listed as a dependency in package.json. You can set it back to False if you need the old behavior.

--bazel_patch_module_resolver defaults to false

By default, we no longer patch the require() function, instead you should rely on the linker to make node modules resolvable at the standard location if this breaks you, the quickest fix is to flip the flag back on a nodejs_binary/nodejs_test/npm_package_bin with templated_args = ["--bazel_patch_module_resolver"], see bazelbuild/rules_nodejs#2344 as an example. Another fix is to explicitly use our runfiles helper library, see bazelbuild/rules_nodejs#2341 as an example.

karma and ts_devserver rules moved to new package @bazel/concatjs

packages/karma:package.bzl is gone, in your WORKSPACE replace

load("//packages/karma:package.bzl", "npm_bazel_karma_dependencies")
</tr></table>

... (truncated)

Changelog

Sourced from @bazel/jasmine's changelog.

3.0.0 (2020-12-22)

Bug Fixes

• builtin: only pass kwargs to the test, not the .update binary (#2361) (afa095b)

Code Refactoring

• builtin: remove node_modules attribute from nodejs_binary, nodejs_test & ts_library (c2927af)

BREAKING CHANGES

• builtin: We removed the node_modules attribute from nodejs_binary, nodejs_test, jasmine_node_test & ts_library.

If you are using the node_modules attribute, you can simply add the target specified there to the data or deps attribute of the rule instead.

For example,

nodejs_test(
    name = "test",
    data = [
        "test.js",
        "@npm//:node_modules",
    ],
    entry_point = "test.js",
)

or

ts_library(
    name = "lib",
    srcs = glob(["*.ts"]),
    tsconfig = ":tsconfig.json",
    deps = ["@npm//:node_modules"],
)

We also dropped support for filegroup based node_modules target and removed node_modules_filegroup from index.bzl.

If you are using this feature for user-managed deps, you must now a js_library target with external_npm_package set to True instead.

For example,

... (truncated)

Commits

• c2927af refactor(builtin): remove node_modules attribute from nodejs_binary, nodejs_t...
• 0203c06 refactor: make dependencies on --bazel_patch_module_resolver explicit
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}