a name for this target

Label of the tsconfig.json file to use for the compilation.
To support "chaining" of more than one extended config, this label could be a target that
provides TsConfigInfo such as ts_config.

By default, if a "tsconfig.json" file is in the same folder with the ts_project rule, it is used.

Instead of a label, you can pass a dictionary matching the JSON schema.

See docs/tsconfig.md for detailed information.

List of labels of TypeScript source files to be provided to the compiler.

If absent, the default is set as follows:

• Include all TypeScript files in the package, recursively.
• If allow_js is set, include all JavaScript files in the package as well.
• If resolve_json_module is set, include all JSON files in the package,
  but exclude package.json, package-lock.json, and tsconfig*.json.

List of strings of additional command-line arguments to pass to tsc.
See https://www.typescriptlang.org/docs/handbook/compiler-options.html#compiler-options
Typically useful arguments for debugging are --listFiles and --listEmittedFiles.

Files needed at runtime by binaries or tests that transitively depend on this target.
See https://bazel.build/reference/be/common-definitions#typical-attributes

List of targets that produce TypeScript typings (.d.ts files)

If this list contains linked npm packages, npm package store targets or other targets that provide
JsInfo, NpmPackageStoreInfo providers are gathered from JsInfo. This is done directly from
the npm_package_store_deps field of these. For linked npm package targets, the underlying
npm_package_store target(s) that back the links is used. Gathered NpmPackageStoreInfo
providers are propagated to the direct dependencies of downstream linked npm_package targets.

NB: Linked npm package targets that are "dev" dependencies do not forward their underlying
npm_package_store target(s) through npm_package_store_deps and will therefore not be
propagated to the direct dependencies of downstream linked npm_package targets. npm packages
that come in from npm_translate_lock are considered "dev" dependencies if they are have
dev: true set in the pnpm lock file. This should be all packages that are only listed as
"devDependencies" in all package.json files within the pnpm workspace. This behavior is
intentional to mimic how devDependencies work in published npm packages.

Files which are needed by a downstream build step such as a bundler.

These files are not included as inputs to any actions spawned by ts_project.
They are not transpiled, and are not visible to the type-checker.
Instead, these files appear among the outputs of this target.

A typical use is when your TypeScript code has an import that TS itself doesn't understand
such as

import './my.scss'

and the type-checker allows this because you have an "ambient" global type declaration like

declare module '*.scss' { ... }

A bundler like webpack will expect to be able to resolve the ./my.scss import to a file
and doesn't care about the typing declaration. A bundler runs as a build step,
so it does not see files included in the data attribute.

Note that data is used for files that are resolved by some binary, including a test
target. Behind the scenes, data populates Bazel's Runfiles object in DefaultInfo,
while this attribute populates the transitive_sources of the JsInfo.

Label of the tsconfig file referenced in the extends section of tsconfig
To support "chaining" of more than one extended config, this label could be a target that
provdes TsConfigInfo such as ts_config.

Whether TypeScript will read .js and .jsx files.
When used with declaration, TypeScript will generate .d.ts files from .js files.

Whether to type-check asynchronously as a separate bazel action from transpilation.

Any transpiling with tsc will only contain the ts_project(tsconfig) dependencies, while type-checking
actions will also include the ts_project(deps) dependencies.

Requires https://devblogs.microsoft.com/typescript/announcing-typescript-5-6/#the---nocheck-option6
Requires https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-5.html#isolated-declarations

Whether the declaration bit is set in the tsconfig.
Instructs Bazel to expect a .d.ts output for each .ts source.

Whether the sourceMap bit is set in the tsconfig.
Instructs Bazel to expect a .js.map output for each .ts source.

Whether the declarationMap bit is set in the tsconfig.
Instructs Bazel to expect a .d.ts.map output for each .ts source.

Boolean; specifies whether TypeScript will read .json files.
If set to True or False and tsconfig is a dict, resolveJsonModule is set in the generated config file.
If set to None and tsconfig is a dict, resolveJsonModule is unset in the generated config and typescript
default or extended tsconfig value will be load bearing.

Whether the jsx value is set to "preserve" in the tsconfig.
Instructs Bazel to expect a .jsx or .jsx.map output for each .tsx source.

Whether the composite bit is set in the tsconfig.
Instructs Bazel to expect a .tsbuildinfo output and a .d.ts output for each .ts source.

Whether the incremental bit is set in the tsconfig.
Instructs Bazel to expect a .tsbuildinfo output.

Whether the noEmit bit is set in the tsconfig.
Instructs Bazel not to expect any outputs.

Whether the emitDeclarationOnly bit is set in the tsconfig.
Instructs Bazel not to expect .js or .js.map outputs for .ts sources.

A custom transpiler tool to run that produces the JavaScript outputs instead of tsc.

Under --@aspect_rules_ts//ts:default_to_tsc_transpiler, the default is to use tsc to produce
.js outputs in the same action that does the type-checking to produce .d.ts outputs.
This is the simplest configuration, however tsc is slower than alternatives.
It also means developers must wait for the type-checking in the developer loop.

Without --@aspect_rules_ts//ts:default_to_tsc_transpiler, an explicit value must be set.
This may be the string "tsc" to explicitly choose tsc, just like the default above.

It may also be any rule or macro with this signature: (name, srcs, **kwargs)

If JavaScript outputs are configured to not be emitted the custom transpiler will not be used, such as
when no_emit = True or emit_declaration_only = True.

See docs/transpiler.md for more details.

A custom transpiler tool to run that produces the TypeScript declaration outputs instead of tsc.

It may be any rule or macro with this signature: (name, srcs, **kwargs)

If TypeScript declaration outputs are configured to not be emitted the custom declaration transpiler will
not be used, such as when no_emit = True or declaration = False.

See docs/transpiler.md for more details.

The user-specified value of tsBuildInfoFile from the tsconfig.
Helps Bazel to predict the path where the .tsbuildinfo output is written.

Whether to generate a trace file for TypeScript compiler performance analysis.
When enabled, creates a trace directory containing performance tracing information that can be
loaded in chrome://tracing. Use the --@aspect_rules_ts//ts:generate_tsc_trace flag to enable this by default.

Label of the TypeScript compiler binary to run.
This allows you to use a custom API-compatible compiler in place of the regular tsc such as a custom js_binary or Angular's ngc.
compatible with it such as Angular's ngc.

See examples of use in examples/custom_compiler

Label of a custom TypeScript compiler binary which understands Bazel's persistent worker protocol.

Whether to check that the dependencies are valid and the tsconfig JSON settings match the attributes on this target.
Set this to False to skip running our validator, in case you have a legitimate reason for these to differ,
e.g. you have a setting enabled just for the editor but you want different behavior when Bazel runs tsc.

Label of the tsconfig validator to run when validate = True.

String specifying a subdirectory under the bazel-out folder where generated declaration
outputs are written. Equivalent to the TypeScript --declarationDir option.
By default declarations are written to the out_dir.

String specifying a subdirectory under the bazel-out folder where outputs are written.
Equivalent to the TypeScript --outDir option.

Note that Bazel always requires outputs be written under a subdirectory matching the input package,
so if your rule appears in path/to/my/package/BUILD.bazel and out_dir = "foo" then the .js files
will appear in bazel-out/[arch]/bin/path/to/my/package/foo/*.js.

By default the out_dir is the package's folder under bazel-out.

String specifying a subdirectory under the input package which should be consider the
root directory of all the input files.
Equivalent to the TypeScript --rootDir option.
By default it is '.', meaning the source directory where the BUILD file lives.

Whether the "Persistent Worker" protocol is enabled.
This uses a custom tsc compiler to make rebuilds faster.
Note that this causes some known correctness bugs, see
https://docs.aspect.build/rules/aspect_rules_ts/docs/troubleshooting.
We do not intend to fix these bugs.

Worker mode can be enabled for all ts_projects in a build with the global
--@aspect_rules_ts//ts:supports_workers flag.
To enable worker mode for all builds in the workspace, add
build --@aspect_rules_ts//ts:supports_workers to the .bazelrc.

This is a "tri-state" attribute, accepting values [-1, 0, 1]. The behavior is:

• -1: use the value of the global --@aspect_rules_ts//ts:supports_workers flag.
• 0: Override the global flag, disabling workers for this target.
• 1: Override the global flag, enabling workers for this target.

passed through to underlying ts_project_rule, eg. visibility, tags

name of resulting ts_proto_library target

Label pointing to the linked node_modules target where @bufbuild/protoc-gen-es is linked, e.g. //:node_modules.
Since the generated code depends on @bufbuild/protobuf, this package must also be linked.
If gen_connect_es = True then @bufbuild/proto-gen-connect-es should be linked as well.
If gen_connect_query = True then @bufbuild/proto-gen-connect-query should be linked as well.

the proto_library target that contains the .proto files to generate code for.

dict of protoc_gen_es options.
See https://github.com/bufbuild/protobuf-es/tree/main/packages/protoc-gen-es#plugin-options

[deprecated] whether protoc_gen_connect_es should generate grpc services, and therefore *_connect.{js,d.ts} should be written.

whether protoc_gen_connect_query should generate TanStack Query clients, and therefore *_connectquery.{js,d.ts} should be written.

mapping from source proto file to the named RPC services that file contains.
Needed to predict which files will be generated by gen_connect_query.
See https://github.com/connectrpc/connect-query-es/tree/main/examples/react/basic/src/gen

For example, given a.proto which contains a service Foo and b.proto that contains a service Bar,
the mapping would be {"a.proto": ["Foo"], "b.proto": ["Bar"]}

whether to copy the resulting .d.ts files back to the source tree, for the editor to locate them.

the .proto files that are being generated. Repeats the srcs of the proto_library target.
This is used only to determine a default for files_to_copy.

which files from the protoc output to copy. By default, performs a replacement on proto_srcs with the typical output filenames.

additional named arguments to the ts_proto_library rule