docs/Concatjs.md

<!-- *********************
  DO NOT EDIT THIS FILE
  It is a generated build output from Stardoc.
  Instead you must edit the .bzl file where the rules are declared,
  or possibly a markdown file next to the .bzl file
 ********************* -->

# @bazel/concatjs

Concatjs is a JavaScript bundler, in a trivial sense: the UNIX `cat` command is a basic implementation:

```bash
$ cat one.js two.js > bundle.js
```

Clearly self-evident is that this bundler is super-fast and simple.
A performant implementation adds some in-memory caching, and for developer ergonomics you add a simple IIFE wrapper
around each file so that the Chrome DevTools shows the files in the tree as if they had been independently loaded.

However at its core, concatjs requires a big tradeoff of a migration cost to buy-in, to get this incredible performance.
The path of the JavaScript files is lost in the bundling process, so they must contain their module ID internally.

[Named AMD/UMD modules](https://requirejs.org/docs/whyamd.html#namedmodules) and `goog.module` are the two JS module formats that are compatible with concatjs.
Most packages do not ship with this format, so in order to use concatjs tooling, you have to shim your code and dependencies. See the [Compatibility](#compatibility) section below.

This is at the core of how Google does JavaScript development.
So Bazel rules that originated in Google's codebase have affordances for concatjs.
For example `ts_library` produces named AMD modules in its "devmode" output, and
`karma_web_test` expects to bundle inputs using concatjs.

## Compatibility

### First-party code

First-party code has to be authored as named AMD/UMD modules.
This is also historically referred to as "RequireJS" modules since that's the
JS loader that is typically used with them.

If you write TypeScript, you can do this following their [documentation](https://www.typescriptlang.org/docs/handbook/modules.html).

There is an example in this repository: we have an `index.ts` file that wants
to be used with require.js `require("@bazel/concatjs")`.
So it
[declares
that module name](https://github.com/bazelbuild/rules_nodejs/blob/bd53eb524ea3bd56b46b7a5f2eff700443e281ec/packages/concatjs/index.ts#L1)
using the TS triple-slash syntax:

```typescript
///<amd-module name="@bazel/concatjs"/>
```

it is [also compiled with](https://github.com/bazelbuild/rules_nodejs/blob/bd53eb524ea3bd56b46b7a5f2eff700443e281ec/packages/concatjs/BUILD.bazel#L28)
the `"compilerOptions": { "module": "umd" }` TypeScript setting.

### Third-party code

To make it easier to produce a UMD version of a third-party npm package, we automatically generate a target that uses Browserify to build one, using the `main` entry from the package's `package.json`.
In most cases this will make the package loadable under concatjs.
This target has a `__umd` suffix. For example, if your library is at `@npm//foo` then the UMD target is `@npm//foo:foo__umd`.

An example where this fixes a users issue: <https://github.com/bazelbuild/rules_nodejs/issues/2317#issuecomment-735921318>

In some cases, the generated UMD bundle is not sufficient, and in others it fails to build because it requires some special Browserify configuration.
You can always write your own shim that grabs a symbol from a package you use, and exposes it in an AMD/require.js-compatible way.
For example, even though RxJS ships with a UMD bundle, it contains multiple entry points and uses anonymous modules, not named modules. So our Angular/concatjs example has a `rxjs_shims.js` file that exposes some RxJS operators, then at <https://github.com/bazelbuild/rules_nodejs/blob/2.3.1/examples/angular/src/BUILD.bazel#L65-L71> this is combined in a `filegroup` with the `rxjs.umd.js` file. Now we use this filegroup target when depending on RxJS in a `concatjs_*` rule.

Ultimately by using concatjs, you're signing up for at least a superficial understanding of these shims and may need to update them when you change your dependencies.

## Serving JS in development mode under Bazel

There are two choices for development mode:

1. Use the `concatjs_devserver` rule to bring up our simple, fast development server.
   This is intentionally very simple, to help you get started quickly. However,
   since there are many development servers available, we do not want to mirror
   their features in yet another server we maintain.
2. Teach your real frontend server to serve files from Bazel's output directory.
   This is not yet documented. Choose this option if you have an existing server
   used in development mode, or if your requirements exceed what the
   `concatjs_devserver` supports. Be careful that your development round-trip stays
   fast (should be under two seconds).

To use `concatjs_devserver`, you simply `load` the rule, and call it with `deps` that
point to your `ts_library` target(s):

```python
load("@npm//@bazel/concatjs:index.bzl", "concatjs_devserver", "ts_library")

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

concatjs_devserver(
    name = "devserver",
    # We'll collect all the devmode JS sources from these TypeScript libraries
    deps = [":app"],
    # This is the path we'll request from the browser, see index.html
    serving_path = "/bundle.js",
    # The devserver can serve our static files too
    static_files = ["index.html"],
)
```

The `index.html` should be the same one you use for production, and it should
load the JavaScript bundle from the path indicated in `serving_path`.

If you don't have an index.html file, a simple one will be generated by the
`concatjs_devserver`.

See `examples/app` in this repository for a working example. To run the
devserver, we recommend you use [ibazel]:

```sh
$ ibazel run examples/app:devserver
```

`ibazel` will keep the devserver program running, and provides a LiveReload
server so the browser refreshes the application automatically when each build
finishes.

[ibazel]: https://github.com/bazelbuild/bazel-watcher

## Testing with Karma

The `karma_web_test` rule runs karma tests with Bazel.

It depends on rules_webtesting, so you need to add this to your `WORKSPACE`
if you use the web testing rules in `@bazel/concatjs`:

```python
# Fetch transitive Bazel dependencies of karma_web_test
http_archive(
    name = "io_bazel_rules_webtesting",
    sha256 = "e9abb7658b6a129740c0b3ef6f5a2370864e102a5ba5ffca2cea565829ed825a",
    urls = ["https://github.com/bazelbuild/rules_webtesting/releases/download/0.3.5/rules_webtesting.tar.gz"],
)

# Set up web testing, choose browsers we can test on
load("@io_bazel_rules_webtesting//web:repositories.bzl", "web_test_repositories")

web_test_repositories()

load("@io_bazel_rules_webtesting//web/versioned:browsers-0.3.3.bzl", "browser_repositories")

browser_repositories(
    chromium = True,
    firefox = True,
)
```

## Known issues with running Chromium for macOS/Windows in Bazel

For macOS and Windows, Chromium comes with files that contain spaces in their file names. This breaks runfile tree
creation within Bazel due to a bug. There are various workarounds that allow for Chromium on these platforms:

* Instruct Bazel to automatically disable runfile tree creation if not needed. [More details here](https://github.com/bazelbuild/bazel/issues/4327#issuecomment-922106293)
* Instruct Bazel to use an alternative experimental approach for creating runfile trees. [More details here](https://github.com/bazelbuild/bazel/issues/4327#issuecomment-627422865)

## Installing with user-managed dependencies

If you didn't use the `yarn_install` or `npm_install` rule to create an `npm` workspace, you'll have to declare a rule in your root `BUILD.bazel` file to execute karma:

```python
# Create a karma rule to use in karma_web_test_suite karma
# attribute when using user-managed dependencies
nodejs_binary(
    name = "karma/karma",
    entry_point = "//:node_modules/karma/bin/karma",
    # Point bazel to your node_modules to find the entry point
    data = ["//:node_modules"],
)
```


## concatjs_devserver

**USAGE**

<pre>
concatjs_devserver(<a href="#concatjs_devserver-name">name</a>, <a href="#concatjs_devserver-additional_root_paths">additional_root_paths</a>, <a href="#concatjs_devserver-bootstrap">bootstrap</a>, <a href="#concatjs_devserver-deps">deps</a>, <a href="#concatjs_devserver-devserver">devserver</a>, <a href="#concatjs_devserver-devserver_host">devserver_host</a>,
                   <a href="#concatjs_devserver-entry_module">entry_module</a>, <a href="#concatjs_devserver-port">port</a>, <a href="#concatjs_devserver-scripts">scripts</a>, <a href="#concatjs_devserver-serving_path">serving_path</a>, <a href="#concatjs_devserver-static_files">static_files</a>)
</pre>

concatjs_devserver is a simple development server intended for a quick "getting started" experience.

Additional documentation [here](https://github.com/alexeagle/angular-bazel-example/wiki/Running-a-devserver-under-Bazel)


**ATTRIBUTES**


<h4 id="concatjs_devserver-name">name</h4>

(*<a href="https://bazel.build/docs/build-ref.html#name">Name</a>, mandatory*): A unique name for this target.


<h4 id="concatjs_devserver-additional_root_paths">additional_root_paths</h4>

(*List of strings*): Additional root paths to serve `static_files` from.
            Paths should include the workspace name such as `["__main__/resources"]`

Defaults to `[]`

<h4 id="concatjs_devserver-bootstrap">bootstrap</h4>

(*<a href="https://bazel.build/docs/build-ref.html#labels">List of labels</a>*): Scripts to include in the JS bundle before the module loader (require.js)

Defaults to `[]`

<h4 id="concatjs_devserver-deps">deps</h4>

(*<a href="https://bazel.build/docs/build-ref.html#labels">List of labels</a>*): Targets that produce JavaScript, such as `ts_library`

Defaults to `[]`

<h4 id="concatjs_devserver-devserver">devserver</h4>

(*<a href="https://bazel.build/docs/build-ref.html#labels">Label</a>*): Go based devserver executable.

            With cross-platform RBE for OSX & Windows ctx.executable.devserver will be linux as --cpu and
            --host_cpu must be overridden to k8. However, we still want to be able to run the devserver on the host
            machine so we need to include the host devserver binary, which is ctx.executable.devserver_host, in the
            runfiles. For non-RBE and for RBE with a linux host, ctx.executable.devserver & ctx.executable.devserver_host
            will be the same binary.

            Defaults to precompiled go binary setup by @bazel/typescript npm package

Defaults to `@npm//@bazel/concatjs/devserver:devserver`

<h4 id="concatjs_devserver-devserver_host">devserver_host</h4>

(*<a href="https://bazel.build/docs/build-ref.html#labels">Label</a>*): Go based devserver executable for the host platform.
            Defaults to precompiled go binary setup by @bazel/typescript npm package

Defaults to `@npm//@bazel/concatjs/devserver:devserver`

<h4 id="concatjs_devserver-entry_module">entry_module</h4>

(*String*): The `entry_module` should be the AMD module name of the entry module such as `"__main__/src/index".`
            `concatjs_devserver` concats the following snippet after the bundle to load the application:
            `require(["entry_module"]);`

Defaults to `""`

<h4 id="concatjs_devserver-port">port</h4>

(*Integer*): The port that the devserver will listen on.

Defaults to `5432`

<h4 id="concatjs_devserver-scripts">scripts</h4>

(*<a href="https://bazel.build/docs/build-ref.html#labels">List of labels</a>*): User scripts to include in the JS bundle before the application sources

Defaults to `[]`

<h4 id="concatjs_devserver-serving_path">serving_path</h4>

(*String*): The path you can request from the client HTML which serves the JavaScript bundle.
            If you don't specify one, the JavaScript can be loaded at /_/ts_scripts.js

Defaults to `"/_/ts_scripts.js"`

<h4 id="concatjs_devserver-static_files">static_files</h4>

(*<a href="https://bazel.build/docs/build-ref.html#labels">List of labels</a>*): Arbitrary files which to be served, such as index.html.
            They are served relative to the package where this rule is declared.

Defaults to `[]`


## ts_library

**USAGE**

<pre>
ts_library(<a href="#ts_library-name">name</a>, <a href="#ts_library-angular_assets">angular_assets</a>, <a href="#ts_library-compiler">compiler</a>, <a href="#ts_library-data">data</a>, <a href="#ts_library-deps">deps</a>, <a href="#ts_library-devmode_module">devmode_module</a>, <a href="#ts_library-devmode_target">devmode_target</a>,
           <a href="#ts_library-expected_diagnostics">expected_diagnostics</a>, <a href="#ts_library-generate_externs">generate_externs</a>, <a href="#ts_library-internal_testing_type_check_dependencies">internal_testing_type_check_dependencies</a>,
           <a href="#ts_library-link_workspace_root">link_workspace_root</a>, <a href="#ts_library-module_name">module_name</a>, <a href="#ts_library-module_root">module_root</a>, <a href="#ts_library-package_name">package_name</a>, <a href="#ts_library-package_path">package_path</a>, <a href="#ts_library-prodmode_module">prodmode_module</a>,
           <a href="#ts_library-prodmode_target">prodmode_target</a>, <a href="#ts_library-runtime">runtime</a>, <a href="#ts_library-runtime_deps">runtime_deps</a>, <a href="#ts_library-srcs">srcs</a>, <a href="#ts_library-supports_workers">supports_workers</a>, <a href="#ts_library-tsconfig">tsconfig</a>, <a href="#ts_library-tsickle_typed">tsickle_typed</a>,
           <a href="#ts_library-use_angular_plugin">use_angular_plugin</a>)
</pre>

type-check and compile 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.

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

## Serving TypeScript for development

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

## Accessing JavaScript outputs

The default output of the `ts_library` rule is the `.d.ts` files.
This is for a couple reasons:

- help ensure that downstream rules which access default outputs will not require
  a cascading re-build when only the implementation changes but not the types
- make you think about whether you want the `devmode` (named `UMD`) or `prodmode` outputs

You can access the JS output by adding a `filegroup` rule after the `ts_library`,
for example

```python
ts_library(
    name = "compile",
    srcs = ["thing.ts"],
)

filegroup(
    name = "thing.js",
    srcs = ["compile"],
    # Change to es6_sources to get the 'prodmode' JS
    output_group = "es5_sources",
)

my_rule(
    name = "uses_js",
    deps = ["thing.js"],
)
```



**ATTRIBUTES**


<h4 id="ts_library-name">name</h4>

(*<a href="https://bazel.build/docs/build-ref.html#name">Name</a>, mandatory*): A unique name for this target.


<h4 id="ts_library-angular_assets">angular_assets</h4>

(*<a href="https://bazel.build/docs/build-ref.html#labels">List of labels</a>*): Additional files the Angular compiler will need to read as inputs.
            Includes .css and .html files

Defaults to `[]`

<h4 id="ts_library-compiler">compiler</h4>

(*<a href="https://bazel.build/docs/build-ref.html#labels">Label</a>*): Sets a different TypeScript compiler binary to use for this library.
For example, we use the vanilla TypeScript tsc.js for bootstrapping,
and Angular compilations can replace this with `ngc`.

The default ts_library compiler depends on the `//@bazel/typescript`
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.:

```python
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](https://github.com/angular/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 `@npm//@bazel/concatjs/internal:tsc_wrapped_bin`

<h4 id="ts_library-data">data</h4>

(*<a href="https://bazel.build/docs/build-ref.html#labels">List of labels</a>*)

Defaults to `[]`

<h4 id="ts_library-deps">deps</h4>

(*<a href="https://bazel.build/docs/build-ref.html#labels">List of labels</a>*): Compile-time dependencies, typically other ts_library targets

Defaults to `[]`

<h4 id="ts_library-devmode_module">devmode_module</h4>

(*String*): Set the typescript `module` compiler option for devmode output.

This value will override the `module` option in the user supplied tsconfig.

Defaults to `"umd"`

<h4 id="ts_library-devmode_target">devmode_target</h4>

(*String*): Set the typescript `target` compiler option for devmode output.

This value will override the `target` option in the user supplied tsconfig.

Defaults to `"es2015"`

<h4 id="ts_library-expected_diagnostics">expected_diagnostics</h4>

(*List of strings*)

Defaults to `[]`

<h4 id="ts_library-generate_externs">generate_externs</h4>

(*Boolean*)

Defaults to `True`

<h4 id="ts_library-internal_testing_type_check_dependencies">internal_testing_type_check_dependencies</h4>

(*Boolean*): Testing only, whether to type check inputs that aren't srcs.

Defaults to `False`

<h4 id="ts_library-link_workspace_root">link_workspace_root</h4>

(*Boolean*): Link the workspace root to the bin_dir to support absolute requires like 'my_wksp/path/to/file'.

If source files need to be required then they can be copied to the bin_dir with copy_to_bin.

Defaults to `False`

<h4 id="ts_library-module_name">module_name</h4>

(*String*)

Defaults to `""`

<h4 id="ts_library-module_root">module_root</h4>

(*String*)

Defaults to `""`

<h4 id="ts_library-package_name">package_name</h4>

(*String*): The package name that the linker will link this ts_library output as.

If package_path is set, the linker will link this package under <package_path>/node_modules/<package_name>.
If package_path is not set the this will be the root node_modules of the workspace.

Defaults to `""`

<h4 id="ts_library-package_path">package_path</h4>

(*String*): The package path in the workspace that the linker will link this ts_library output to.

If package_path is set, the linker will link this package under <package_path>/node_modules/<package_name>.
If package_path is not set the this will be the root node_modules of the workspace.

Defaults to `""`

<h4 id="ts_library-prodmode_module">prodmode_module</h4>

(*String*): Set the typescript `module` compiler option for prodmode output.

This value will override the `module` option in the user supplied tsconfig.

Defaults to `"esnext"`

<h4 id="ts_library-prodmode_target">prodmode_target</h4>

(*String*): Set the typescript `target` compiler option for prodmode output.

This value will override the `target` option in the user supplied tsconfig.

Defaults to `"es2015"`

<h4 id="ts_library-runtime">runtime</h4>

(*String*)

Defaults to `"browser"`

<h4 id="ts_library-runtime_deps">runtime_deps</h4>

(*<a href="https://bazel.build/docs/build-ref.html#labels">List of labels</a>*)  The dependencies of this attribute must provide: JsInfo


Defaults to `[]`

<h4 id="ts_library-srcs">srcs</h4>

(*<a href="https://bazel.build/docs/build-ref.html#labels">List of labels</a>, mandatory*): The TypeScript source files to compile.


<h4 id="ts_library-supports_workers">supports_workers</h4>

(*Boolean*): Intended for internal use only.

Allows you to disable the Bazel Worker strategy for this library.
Typically used together with the "compiler" setting when using a
non-worker aware compiler binary.

Defaults to `True`

<h4 id="ts_library-tsconfig">tsconfig</h4>

(*<a href="https://bazel.build/docs/build-ref.html#labels">Label</a>*): A tsconfig.json file containing settings for TypeScript compilation.
Note that some properties in the tsconfig are governed by Bazel and will be
overridden, such as `target` and `module`.

The default value is set to `//:tsconfig.json` by a macro. This means you must
either:

- Have your `tsconfig.json` file in the workspace root directory
- Use an alias in the root BUILD.bazel file to point to the location of tsconfig:
    `alias(name="tsconfig.json", actual="//path/to:tsconfig-something.json")`
    and also make the tsconfig.json file visible to other Bazel packages:
    `exports_files(["tsconfig.json"], visibility = ["//visibility:public"])`
- Give an explicit `tsconfig` attribute to all `ts_library` targets

Defaults to `None`

<h4 id="ts_library-tsickle_typed">tsickle_typed</h4>

(*Boolean*): If using tsickle, instruct it to translate types to ClosureJS format

Defaults to `True`

<h4 id="ts_library-use_angular_plugin">use_angular_plugin</h4>

(*Boolean*): Run the Angular ngtsc compiler under ts_library

Defaults to `False`


## karma_web_test

**USAGE**

<pre>
karma_web_test(<a href="#karma_web_test-srcs">srcs</a>, <a href="#karma_web_test-deps">deps</a>, <a href="#karma_web_test-data">data</a>, <a href="#karma_web_test-configuration_env_vars">configuration_env_vars</a>, <a href="#karma_web_test-bootstrap">bootstrap</a>, <a href="#karma_web_test-runtime_deps">runtime_deps</a>, <a href="#karma_web_test-static_files">static_files</a>,
               <a href="#karma_web_test-config_file">config_file</a>, <a href="#karma_web_test-tags">tags</a>, <a href="#karma_web_test-peer_deps">peer_deps</a>, <a href="#karma_web_test-kwargs">kwargs</a>)
</pre>

Runs unit tests in a browser with Karma.

When executed under `bazel test`, this uses a headless browser for speed.
This is also because `bazel test` allows multiple targets to be tested together,
and we don't want to open a Chrome window on your machine for each one. Also,
under `bazel test` the test will execute and immediately terminate.

Running under `ibazel test` gives you a "watch mode" for your tests. The rule is
optimized for this case - the test runner server will stay running and just
re-serve the up-to-date JavaScript source bundle.

To debug a single test target, run it with `bazel run` instead. This will open a
browser window on your computer. Also you can use any other browser by opening
the URL printed when the test starts up. The test will remain running until you
cancel the `bazel run` command.

This rule will use your system Chrome by default. In the default case, your
environment must specify CHROME_BIN so that the rule will know which Chrome binary to run.
Other `browsers` and `customLaunchers` may be set using the a base Karma configuration
specified in the `config_file` attribute.

By default we open a headless Chrome. To use a real Chrome browser window, you can pass
`--define DISPLAY=true` to Bazel, along with `configuration_env_vars = ["DISPLAY"]` on
`karma_web_test`.


**PARAMETERS**


<h4 id="karma_web_test-srcs">srcs</h4>

A list of JavaScript test files

Defaults to `[]`

<h4 id="karma_web_test-deps">deps</h4>

Other targets which produce JavaScript such as `ts_library`

Defaults to `[]`

<h4 id="karma_web_test-data">data</h4>

Runtime dependencies

Defaults to `[]`

<h4 id="karma_web_test-configuration_env_vars">configuration_env_vars</h4>

Pass these configuration environment variables to the resulting binary.
Chooses a subset of the configuration environment variables (taken from ctx.var), which also
includes anything specified via the --define flag.
Note, this can lead to different outputs produced by this rule.

Defaults to `[]`

<h4 id="karma_web_test-bootstrap">bootstrap</h4>

JavaScript files to include *before* the module loader (require.js).
For example, you can include Reflect,js for TypeScript decorator metadata reflection,
or UMD bundles for third-party libraries.

Defaults to `[]`

<h4 id="karma_web_test-runtime_deps">runtime_deps</h4>

Dependencies which should be loaded after the module loader but before the srcs and deps.
These should be a list of targets which produce JavaScript such as `ts_library`.
The files will be loaded in the same order they are declared by that rule.

Defaults to `[]`

<h4 id="karma_web_test-static_files">static_files</h4>

Arbitrary files which are available to be served on request.
Files are served at:
`/base/&lt;WORKSPACE_NAME&gt;/&lt;path-to-file&gt;`, e.g.
`/base/npm_bazel_typescript/examples/testing/static_script.js`

Defaults to `[]`

<h4 id="karma_web_test-config_file">config_file</h4>

User supplied Karma configuration file. Bazel will override
certain attributes of this configuration file. Attributes that are
overridden will be outputted to the test log.

Defaults to `None`

<h4 id="karma_web_test-tags">tags</h4>

Standard Bazel tags, this macro adds tags for ibazel support

Defaults to `[]`

<h4 id="karma_web_test-peer_deps">peer_deps</h4>

list of peer npm deps required by karma_web_test

Defaults to `["@npm//karma", "@npm//karma-chrome-launcher", "@npm//karma-firefox-launcher", "@npm//karma-jasmine", "@npm//karma-requirejs", "@npm//karma-sourcemap-loader", "@npm//requirejs"]`

<h4 id="karma_web_test-kwargs">kwargs</h4>

Passed through to `karma_web_test`




## karma_web_test_suite

**USAGE**

<pre>
karma_web_test_suite(<a href="#karma_web_test_suite-name">name</a>, <a href="#karma_web_test_suite-browsers">browsers</a>, <a href="#karma_web_test_suite-web_test_data">web_test_data</a>, <a href="#karma_web_test_suite-wrapped_test_tags">wrapped_test_tags</a>, <a href="#karma_web_test_suite-kwargs">kwargs</a>)
</pre>

Defines a test_suite of web_test targets that wrap a karma_web_test target.

This macro accepts all parameters in karma_web_test and adds additional parameters
for the suite. See karma_web_test docs for all karma_web_test.

The wrapping macro is `web_test_suite` which comes from rules_websting:
https://github.com/bazelbuild/rules_webtesting/blob/master/web/web.bzl.


**PARAMETERS**


<h4 id="karma_web_test_suite-name">name</h4>

The base name of the test



<h4 id="karma_web_test_suite-browsers">browsers</h4>

A sequence of labels specifying the browsers to use.

Defaults to `None`

<h4 id="karma_web_test_suite-web_test_data">web_test_data</h4>

Data dependencies for the wrapper web_test targets.

Defaults to `[]`

<h4 id="karma_web_test_suite-wrapped_test_tags">wrapped_test_tags</h4>

A list of test tag strings to use for the wrapped
karma_web_test target.

Defaults to `["manual", "noci"]`

<h4 id="karma_web_test_suite-kwargs">kwargs</h4>

Arguments for the wrapped karma_web_test target.