diff --git a/.bazelci/presubmit.yml b/.bazelci/presubmit.yml index c40163e542..e692a85a52 100644 --- a/.bazelci/presubmit.yml +++ b/.bazelci/presubmit.yml @@ -1,5 +1,5 @@ --- -bazel: 3.6.0 +bazel: 4.0.0 tasks: ubuntu1604: name: ubuntu1604 diff --git a/.bazelrc b/.bazelrc index 5fbbc6bbc2..00ce0e3bcb 100644 --- a/.bazelrc +++ b/.bazelrc @@ -52,3 +52,5 @@ build:docker-sandbox --experimental_docker_image=gcr.io/cloud-marketplace/google # Incompatible flags to run with build --incompatible_no_implicit_file_export build --incompatible_restrict_string_escapes +# TODO(alexeagle): turn on this flag when dependencies allow +# build --incompatible_use_platforms_repo_for_constraints diff --git a/.bazelversion b/.bazelversion index 40c341bdcd..fcdb2e109f 100644 --- a/.bazelversion +++ b/.bazelversion @@ -1 +1 @@ -3.6.0 +4.0.0 diff --git a/CHANGELOG.md b/CHANGELOG.md index 6dad69a43b..41c71a744e 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,3 +1,23 @@ +## [3.2.3](https://github.com/bazelbuild/rules_nodejs/compare/3.2.2...3.2.3) (2021-03-25) + + +### Bug Fixes + +* **builtin:** add transitive typings to runfiles provider produced by js_library ([#2547](https://github.com/bazelbuild/rules_nodejs/issues/2547)) ([41117fa](https://github.com/bazelbuild/rules_nodejs/commit/41117fa)) +* **builtin:** always install source-map-support ([#2538](https://github.com/bazelbuild/rules_nodejs/issues/2538)) ([97b3886](https://github.com/bazelbuild/rules_nodejs/commit/97b3886)), closes [#2520](https://github.com/bazelbuild/rules_nodejs/issues/2520) +* **esbuild:** allow empty string as an input to sourcemap for bazel 2.x support ([#2549](https://github.com/bazelbuild/rules_nodejs/issues/2549)) ([3b3e020](https://github.com/bazelbuild/rules_nodejs/commit/3b3e020)) +* **typescript:** update documentation now that ts_project is recommended ([#2548](https://github.com/bazelbuild/rules_nodejs/issues/2548)) ([a8d8b0f](https://github.com/bazelbuild/rules_nodejs/commit/a8d8b0f)) +* tsconfig validator fails on chained tsconfig references ([#2512](https://github.com/bazelbuild/rules_nodejs/issues/2512)) ([bfd74e5](https://github.com/bazelbuild/rules_nodejs/commit/bfd74e5)) +* **examples:** remove relativeLinkResolution ([#2530](https://github.com/bazelbuild/rules_nodejs/issues/2530)) ([8ef60e5](https://github.com/bazelbuild/rules_nodejs/commit/8ef60e5)) + + +### Features + +* **builtin:** first experimental rules for npm tarballs ([#2544](https://github.com/bazelbuild/rules_nodejs/issues/2544)) ([aa09b57](https://github.com/bazelbuild/rules_nodejs/commit/aa09b57)) +* **esbuild:** add 'sourcemap' option to configure sourcemap generation ([#2528](https://github.com/bazelbuild/rules_nodejs/issues/2528)) ([8d0218c](https://github.com/bazelbuild/rules_nodejs/commit/8d0218c)) + + + ## [3.2.2](https://github.com/bazelbuild/rules_nodejs/compare/3.2.1...3.2.2) (2021-03-08) diff --git a/README.md b/README.md index 9e1eff7b4a..03a0518d83 100644 --- a/README.md +++ b/README.md @@ -12,7 +12,8 @@ so this repo can be thought of as "JavaScript rules for Bazel" as well. (We woul This repository is maintained by volunteers in the Bazel community. Neither Google, nor the Bazel team, provides support for the code. However, this repository is part of the test suite used to vet new Bazel releases. -We follow semantic versioning. Patch releases have bugfixes, minor releases have new features. Only major releases (1.x, 2.x) have breaking changes. +We follow semantic versioning. Patch releases have bugfixes, minor releases have new features. Only major releases (1.x, 2.x) have breaking changes. We support the last two major releases of Bazel, see `SUPPORTED_BAZEL_VERSIONS` in our `/index.bzl` for the list we test against. + We strive to give you an easy upgrade path when we do introduce a breaking change by documenting a migration path. If you use code from an `/internal` path, or the labs package, these are not subject to our support policy and may have breaking changes or removals with no warning or migration path. diff --git a/WORKSPACE b/WORKSPACE index d9964a5466..d8472da8bf 100644 --- a/WORKSPACE +++ b/WORKSPACE @@ -79,6 +79,19 @@ npm_install( package_lock_json = "//packages/node-patches:package-lock.json", ) +load("@build_bazel_rules_nodejs//internal/npm_tarballs:translate_package_lock.bzl", "translate_package_lock") + +# Translate our package.lock file from JSON to Starlark +translate_package_lock( + name = "npm_node_patches_lock", + package_lock = "//packages/node-patches:package-lock.json", +) + +load("@npm_node_patches_lock//:index.bzl", _npm_patches_repositories = "npm_repositories") + +# # Declare an external repository for each npm package fetchable by the lock file +_npm_patches_repositories() + npm_install( name = "angular_deps", package_json = "//packages/angular:package.json", diff --git a/docs/Built-ins.html b/docs/Built-ins.html index ba4faa90ae..868ac116bb 100755 --- a/docs/Built-ins.html +++ b/docs/Built-ins.html @@ -1680,8 +1680,8 @@

npm_package_bin

USAGE

-npm_package_bin(tool, package, package_bin, data, env, outs, args, output_dir, link_workspace_root,
-                chdir, kwargs)
+npm_package_bin(tool, package, package_bin, data, env, outs, args, stderr, stdout, exit_code_out,
+                output_dir, link_workspace_root, chdir, kwargs)
 

Run an arbitrary npm package binary (e.g. a program under node_modules/.bin/*) under Bazel.

@@ -1786,6 +1786,28 @@

args

Defaults to []

+

stderr

+ +

set to capture the stderr of the binary to a file, which can later be used as an input to another target +subject to the same semantics as outs

+ +

Defaults to None

+ +

stdout

+ +

set to capture the stdout of the binary to a file, which can later be used as an input to another target +subject to the same semantics as outs

+ +

Defaults to None

+ +

exit_code_out

+ +

set to capture the exit code of the binary to a file, which can later be used as an input to another target +subject to the same semantics as outs. Note that setting this will force the binary to exit 0. +If the binary creates outputs and these are declared, they must still be created

+ +

Defaults to None

+

output_dir

set to True if you want the output to be a directory diff --git a/docs/Built-ins.md b/docs/Built-ins.md index 4441111e9b..743733967c 100755 --- a/docs/Built-ins.md +++ b/docs/Built-ins.md @@ -1608,8 +1608,8 @@ used for undocumented legacy features **USAGE**

-npm_package_bin(tool, package, package_bin, data, env, outs, args, output_dir, link_workspace_root,
-                chdir, kwargs)
+npm_package_bin(tool, package, package_bin, data, env, outs, args, stderr, stdout, exit_code_out,
+                output_dir, link_workspace_root, chdir, kwargs)
 
Run an arbitrary npm package binary (e.g. a program under node_modules/.bin/*) under Bazel. @@ -1710,6 +1710,28 @@ See https://docs.bazel.build/versions/master/be/make-variables.html#custom_varia Defaults to `[]` +

stderr

+ +set to capture the stderr of the binary to a file, which can later be used as an input to another target +subject to the same semantics as `outs` + +Defaults to `None` + +

stdout

+ +set to capture the stdout of the binary to a file, which can later be used as an input to another target +subject to the same semantics as `outs` + +Defaults to `None` + +

exit_code_out

+ +set to capture the exit code of the binary to a file, which can later be used as an input to another target +subject to the same semantics as `outs`. Note that setting this will force the binary to exit 0. +If the binary creates outputs and these are declared, they must still be created + +Defaults to `None` +

output_dir

set to True if you want the output to be a directory diff --git a/docs/TypeScript.html b/docs/TypeScript.html index 873fd4a18e..35b58479a4 100755 --- a/docs/TypeScript.html +++ b/docs/TypeScript.html @@ -190,36 +190,63 @@

Alternatives

At a high level, there are three alternatives provided: tsc, ts_project, ts_library. This section describes the trade-offs between these rules.

-

tsc is the raw TypeScript compiler published by the team at Microsoft. -Like any npm package that exposes a binary, rules_nodejs will generate an index.bzl file allowing -you to run tsc.

+

tsc

-

To use it, add the load statement load("@npm//typescript:index.bzl", "tsc") to your BUILD file. -Then call it, using the npm_package_bin documentation.

+

tsc is the TypeScript compiler published by the team at Microsoft. +You can call it without any custom Bazel rules.

-

The only reason to use raw tsc is if you want to compile an opaque directory of .ts files and cannot enumerate them to Bazel. +

To use this option, you do not need to install the @bazel/typescript package.

+ +

The only reason to use raw tsc is if you want to compile a directory of .ts files and cannot enumerate them ahead-of-time in your BUILD file so that Bazel can predict all the output files. (For example if the .ts files are generated by some tool). -This will produce an opaque directory of .js file outputs, which you won’t be able to individually reference. -Any other use case for tsc is better served by using ts_project.

+This will produce an opaque directory of .js file outputs, which you won’t be able to individually reference.

+ +

Any other use case for tsc is better served by using ts_project, see below.

+ +

Like we do for any npm package that exposes a binary, rules_nodejs will see your dependency on +typescript and will generate an index.bzl file allowing you to run tsc. +To use it, add the load statement load("@npm//typescript:index.bzl", "tsc") to your BUILD file. +(Possibly replacing @npm with the name of the repository where you installed dependencies)

+ +

Then call it, using the npm_package_bin documentation.

+ +

Here is an example: +https://github.com/bazelbuild/rules_nodejs/blob/3.2.2/internal/node/test/BUILD.bazel#L491-L507

+ +

ts_project

+ +

ts_project simply runs tsc --project, with Bazel knowing which outputs to expect based on the TypeScript compiler options, +and with interoperability with other TypeScript rules via the DeclarationInfo Provider that transmits the type information.

+ +

It is intended as an easy on-boarding for existing TypeScript code and should be familiar if your background is in frontend ecosystem idioms.

+ +

Any behavior of ts_project should be reproducible outside of Bazel, with a couple of caveats noted in the rule documentation below.

+ +

ts_project is recommended for all new code.

+ +

Exhaustive examples of calling ts_project are in the test suite: +https://github.com/bazelbuild/rules_nodejs/tree/stable/packages/typescript/test/ts_project

+ +

And there are also many uses of it in our

-

ts_project simply runs tsc --project, with Bazel knowing which outputs to expect based on the TypeScript compiler options, and with interoperability with other TypeScript rules via a Bazel Provider (DeclarationInfo) that transmits the type information. -It is intended as an easy on-boarding for existing TypeScript code and should be familiar if your background is in frontend ecosystem idioms. -Any behavior of ts_project should be reproducible outside of Bazel, with a couple of caveats noted in the rule documentation below.

+

ts_library

+ +

ts_library should not be used for new code, and may be deprecated in the future.

ts_library is an open-sourced version of the rule used to compile TS code at Google. -It should be familiar if your background is in Bazel idioms. -It is very complex, involving code generation of the tsconfig.json file, a custom compiler binary, and a lot of extra features. -It is also opinionated, and may not work with existing TypeScript code. For example:

+However there is no support from the team that maintains that internal version. +It is very complex, involving code generation of the tsconfig.json file, a custom compiler binary, and a lot of extra features.

+ +

It is also opinionated, and may not work with existing TypeScript code. For example:

-

On the other hand, ts_library is also fast and optimized. -We keep a running TypeScript compile running as a daemon, using Bazel workers. -This process avoids re-parse and re-JIT of the >1MB typescript.js and keeps cached bound ASTs for input files which saves time. -We also produce JS code which can be loaded faster (using named AMD module format) and which can be consumed by the Closure Compiler (via integration with tsickle).

+

The only reason to use ts_library for new code is if you are bought-in to using a concatjs bundler, which requires the named AMD module format. This may be faster than other tooling, and this format can be consumed by the Closure Compiler (via integration with tsickle). +However it is very challenging to configure and there is little available support for problems you’ll run into.

Installation

@@ -232,175 +259,110 @@

Installation

Watch for any peerDependency warnings - we assume you have already installed the typescript package from npm.

-

Create a BUILD.bazel file in your workspace root. If your tsconfig.json file is in the root, use

- -
exports_files(["tsconfig.json"], visibility = ["//visibility:public"])
-
- -

otherwise create an alias:

- -
alias(
-    name = "tsconfig.json",
-    actual = "//path/to/my:tsconfig.json",
-)
-
+

Typical Usage

-

Make sure to remove the --noEmit compiler option from your tsconfig.json. This is not compatible with the ts_library rule.

+

The ts_project rule invokes the TypeScript compiler on one compilation unit, +or “library” (generally one directory of source files). In TypeScript terms, this is one “Project” +which can use “Project References” to break up a large application.

-

User-managed npm dependencies

+

Create a BUILD file next to your sources:

-

We recommend you use Bazel managed dependencies, but if you would like -Bazel to also install a node_modules in your workspace you can also -point the node_repositories repository rule in your WORKSPACE file to -your package.json.

+
load("@npm//@bazel/typescript:index.bzl", "ts_project")
 
-
node_repositories(package_json = ["//:package.json"])
-
+ts_project( + name = "my_code", + # glob is a quick way to select all the code, + # but has performance penalty in that Bazel must evaluate it. + srcs = glob(["*.ts"]), + deps = ["//path/to/other:library"], +) +
+ +

Here, //path/to/other:library is another target in your repo that produces TypeScript typings (for example, another ts_project rule). +Be sure to set the rootDirs in your tsconfig.json as noted below, so that TypeScript can find the .d.ts files produced by that other target.

+ +

To use third-party libraries from npm, first install them (likely using npm_install or yarn_install rules) then add those to the deps as well:

+ +
ts_project(
+    name = "my_code",
+    srcs = glob(["*.ts"]),
+    deps = [
+      "@npm//@types/node",
+      "@npm//@types/foo",
+      "@npm//somelib",
+      "//path/to/other:library",
+    ],
+)
+
-

You can then run yarn in your workspace with:

+

You can also use the @npm//@types grouping target which will include all +packages in the @types scope as dependencies.

-
$ bazel run @nodejs//:yarn_node_repositories
-
+

To build a ts_library target run:

-

To use your workspace node_modules folder as a dependency in ts_library and -other rules, add the following to your root BUILD.bazel file:

- -
js_library(
-    name = "node_modules",
-    srcs = glob(
-        include = [
-          "node_modules/**/*.js",
-          "node_modules/**/*.d.ts",
-          "node_modules/**/*.json",
-          "node_modules/.bin/*",
-        ],
-        exclude = [
-          # Files under test & docs may contain file names that
-          # are not legal Bazel labels (e.g.,
-          # node_modules/ecstatic/test/public/中文/檔案.html)
-          "node_modules/**/test/**",
-          "node_modules/**/docs/**",
-          # Files with spaces in the name are not legal Bazel labels
-          "node_modules/**/* */**",
-          "node_modules/**/* *",
-        ],
-    ),
-    # Provide ExternalNpmPackageInfo which is used by downstream rules
-    # that use these npm dependencies
-    external_npm_package = True,
-)
+

bazel build //path/to/package:target

-# Create a tsc_wrapped compiler rule to use in the ts_library -# compiler attribute when using user-managed dependencies -nodejs_binary( - name = "@bazel/typescript/tsc_wrapped", - entry_point = "@npm//:node_modules/@bazel/typescript/internal/tsc_wrapped/tsc_wrapped.js", - # Point bazel to your node_modules to find the entry point - data = ["//:node_modules"], -) -
+

Note that the tsconfig.json file used for compilation should be the same one +your editor references, or extends from it, to keep consistent settings for the TypeScript compiler.

-

See the dependencies docs for more information on managing npm dependencies with Bazel.

+

Anything you do with TypeScript is possible with ts_project, including json imports, type-checking only, +transpile only, outdir, rootdir, and so on. +See many examples in our test cases: +https://github.com/bazelbuild/rules_nodejs/tree/stable/packages/typescript/test/ts_project

-

Customizing the TypeScript compiler binary

+

ts_config

-

An example use case is needing to increase the NodeJS heap size used for compilations.

+

USAGE

-

Similar to above, you declare your own binary for running tsc_wrapped, e.g.:

+
+ts_config(name, deps, src)
+
-
nodejs_binary(
-    name = "tsc_wrapped_bin",
-    entry_point = "@npm//:node_modules/@bazel/typescript/internal/tsc_wrapped/tsc_wrapped.js",
-    templated_args = [
-        "--node_options=--max-old-space-size=2048",
-    ],
-    data = [
-        "@npm//protobufjs",
-        "@npm//source-map-support",
-        "@npm//tsutils",
-        "@npm//typescript",
-        "@npm//@bazel/typescript",
-    ],
-)
-
+

Allows a tsconfig.json file to extend another file.

-

then refer to that target in the compiler attribute of your ts_library rule.

+

Normally, you just give a single tsconfig.json file as the tsconfig attribute +of a ts_library or ts_project rule. However, if your tsconfig.json uses the extends +feature from TypeScript, then the Bazel implementation needs to know about that +extended configuration file as well, to pass them both to the TypeScript compiler.

-

Note that nodejs_binary targets generated by npm_install/yarn_install can include data dependencies -on packages which aren’t declared as dependencies. For example, if you use tsickle to generate Closure Compiler-compatible JS, then it needs to be a data dependency of tsc_wrapped so that it can be loaded at runtime.

+

ATTRIBUTES

-

Usage

+

name

-

Compiling TypeScript: ts_library

+

(Name, mandatory): A unique name for this target.

-

The ts_library rule invokes the TypeScript compiler on one compilation unit, -or “library” (generally one directory of source files).

+

deps

-

Create a BUILD file next to your sources:

+

(List of labels): Additional tsconfig.json files referenced via extends

-
package(default_visibility=["//visibility:public"])
-load("@npm//@bazel/typescript:index.bzl", "ts_library")
+

Defaults to []

-ts_library( - name = "my_code", - srcs = glob(["*.ts"]), - deps = ["//path/to/other:library"], -) -
+

src

-

If your ts_library target has npm dependencies you can specify these -with fine grained npm dependency targets created by the yarn_install or -npm_install rules:

+

(Label, mandatory): The tsconfig.json file passed to the TypeScript compiler

-
ts_library(
-    name = "my_code",
-    srcs = glob(["*.ts"]),
-    deps = [
-      "@npm//@types/node",
-      "@npm//@types/foo",
-      "@npm//foo",
-      "//path/to/other:library",
-    ],
-)
-
+

ts_library

-

You can also use the @npm//@types target which will include all -packages in the @types scope as dependencies.

+

USAGE

-

If you are using user-managed npm dependencies, you can pass your //:node_modules -target defined in your root BUILD.bazel file to the deps of ts_library. -You’ll also need to override the compiler attribute if you do this -as the Bazel-managed deps and user-managed cannot be used together -in the same rule.

+
+ts_library(name, angular_assets, compiler, data, deps, devmode_module, devmode_target,
+           expected_diagnostics, generate_externs, internal_testing_type_check_dependencies,
+           link_workspace_root, module_name, module_root, prodmode_module, prodmode_target, runtime,
+           runtime_deps, srcs, supports_workers, tsconfig, tsickle_typed, use_angular_plugin)
+
-
ts_library(
-    name = "my_code",
-    srcs = glob(["*.ts"]),
-    deps = [
-        "//path/to/other:library",
-        "//:node_modules",
-    ],
-    compiler = "//:@bazel/typescript/tsc_wrapped",
-)
-
+

type-check and compile a set of TypeScript sources to JavaScript.

-

To build a ts_library target run:

+

It produces declarations files (.d.ts) which are used for compiling downstream +TypeScript targets and JavaScript for the browser and Closure compiler.

-

bazel build //path/to/package:target

+

By default, ts_library uses the tsconfig.json file in the workspace root +directory. See the notes about the tsconfig attribute below.

-

The resulting .d.ts file paths will be printed. Additionally, the .js -outputs from TypeScript will be written to disk, next to the .d.ts files 1.

+

Serving TypeScript for development

-

Note that the tsconfig.json file used for compilation should be the same one -your editor references, to keep consistent settings for the TypeScript compiler. -By default, ts_library uses the tsconfig.json file in the workspace root -directory. See the notes about the tsconfig attribute in the ts_library API docs.

- -
-

1 The -declarationDir -compiler option will be silently overwritten if present.

-
+

ts_library is typically served by the concatjs_devserver rule, documented in the @bazel/concatjs package.

Accessing JavaScript outputs

@@ -434,90 +396,6 @@

Accessing JavaScript outputs

) -

Serving TypeScript for development

- -

This is now documented in the @bazel/concatjs package.

- -

Writing TypeScript code for Bazel

- -

Bazel’s TypeScript compiler has your workspace path mapped, so you can import -from an absolute path starting from your workspace.

- -

/WORKSPACE:

-
workspace(name = "myworkspace")
-
- -

/some/long/path/to/deeply/nested/subdirectory.ts:

-
import {thing} from 'myworkspace/place';
-
- -

will import from /place.ts.

- -

Since this is an extension to the vanilla TypeScript compiler, editors which use the TypeScript language services to provide code completion and inline type checking will not be able to resolve the modules. In the above example, adding

-
"paths": {
-    "myworkspace/*": ["*"]
-}
-
-

to tsconfig.json will fix the imports for the common case of using absolute paths. -See path mapping for more details on the paths syntax.

- -

Similarly, you can use path mapping to teach the editor how to resolve imports -from ts_library rules which set the module_name attribute.

- -

Notes

- -

If you’d like a “watch mode”, try ibazel.

- -

At some point, we plan to release a tool similar to gazelle to generate the -BUILD files from your source code.

- -

ts_config

- -

USAGE

- -
-ts_config(name, deps, src)
-
- -

Allows a tsconfig.json file to extend another file.

- -

Normally, you just give a single tsconfig.json file as the tsconfig attribute -of a ts_library or ts_project rule. However, if your tsconfig.json uses the extends -feature from TypeScript, then the Bazel implementation needs to know about that -extended configuration file as well, to pass them both to the TypeScript compiler.

- -

ATTRIBUTES

- -

name

- -

(Name, mandatory): A unique name for this target.

- -

deps

- -

(List of labels): Additional tsconfig.json files referenced via extends

- -

Defaults to []

- -

src

- -

(Label, mandatory): The tsconfig.json file passed to the TypeScript compiler

- -

ts_library

- -

USAGE

- -
-ts_library(name, angular_assets, compiler, data, deps, devmode_module, devmode_target,
-           expected_diagnostics, generate_externs, internal_testing_type_check_dependencies,
-           link_workspace_root, module_name, module_root, prodmode_module, prodmode_target, runtime,
-           runtime_deps, srcs, supports_workers, tsconfig, tsickle_typed, use_angular_plugin)
-
- -

ts_library type-checks and compiles a set of TypeScript sources to JavaScript.

- -

It produces declarations files (.d.ts) which are used for compiling downstream -TypeScript targets and JavaScript for the browser and Closure compiler.

-

ATTRIBUTES

name

@@ -541,6 +419,33 @@

compiler

target which is setup for projects that use bazel managed npm deps and install the @bazel/typescript npm package.

+

You can also use a custom compiler to increase the NodeJS heap size used for compilations.

+ +

To do this, declare your own binary for running tsc_wrapped, e.g.:

+ +
nodejs_binary(
+    name = "tsc_wrapped_bin",
+    entry_point = "@npm//:node_modules/@bazel/typescript/internal/tsc_wrapped/tsc_wrapped.js",
+    templated_args = [
+        "--node_options=--max-old-space-size=2048",
+    ],
+    data = [
+        "@npm//protobufjs",
+        "@npm//source-map-support",
+        "@npm//tsutils",
+        "@npm//typescript",
+        "@npm//@bazel/typescript",
+    ],
+)
+
+ +

then refer to that target in the compiler attribute.

+ +

Note that nodejs_binary targets generated by npm_install/yarn_install can include data dependencies +on packages which aren’t declared as dependencies. +For example, if you use tsickle to generate Closure Compiler-compatible JS, +then it needs to be a data dependency of tsc_wrapped so that it can be loaded at runtime.

+

Defaults to @build_bazel_rules_typescript//internal:tsc_wrapped_bin

data

@@ -662,7 +567,9 @@

tsconfig

@@ -680,7 +587,7 @@

use_angular_plugin

Defaults to False

-

ts_project

+

ts_project

USAGE

@@ -1030,25 +937,20 @@

kwargs