This is the canonical ruleset for using Bazel with TypeScript, based on https://github.com/aspect-build/rules_js.
Many companies are successfully building with rules_ts. If you're getting value from the project, please let us know! Just comment on our Adoption Discussion.
rules_ts is just a part of what Aspect provides:
Follow instructions from the release you wish to use: https://github.com/aspect-build/rules_ts/releases
There are a number of examples in the examples/ folder and larger examples in the bazel-examples repository using rules_ts such as jest, react, angular.
If you'd like an example added, you can fund a Feature Request.
See the API documentation in the docs/ folder.
The most common use is with the ts_project macro which invokes a
transpiler you configure to transform source files like .ts files into outputs such as .js and .js.map,
and the tsc CLI to type-check
the program and produce .d.ts files.
Many organizations set default values, so it's common to write a macro to wrap ts_project, then
ensure that your developers load your macro rather than loading from @aspect_rules_ts directly.
Aspect provides a TypeScript BUILD file generator as part of the Aspect CLI.
Run aspect configure to create or update BUILD.bazel files as you edit TypeScript sources.
See https://docs.aspect.build/cli/commands/aspect_configure.
If you know how to write Bazel rules, you might find that ts_project doesn't do what you want.
One way to customize it is to peel off one layer of indirection, by calling the ts_project_rule
directly. This bypasses our default setting logic, and also the validation program which checks that
ts_project attributes are well-formed.
You can also write a custom rule from scratch. We expose helper functions from /ts/private in this repo. Be aware that these are not a public API, so you may have to account for breaking changes which aren't subject to our usual semver policy.
This ruleset collects limited usage data via tools_telemetry, which is reported to Aspect Build Inc and governed by our privacy policy.
3.8.9 +1.1mo2026-05-04 | |
3.8.8 +16d2026-04-01 | |
3.8.7 +9d2026-03-15 | |
3.8.6 +9d2026-03-06 | |
3.8.5 +17d2026-02-24 | |
3.8.4 +23d2026-02-07 | |
3.8.2 +<1h2026-01-14 | |
3.8.3 +29d2026-01-14 | |
3.8.1 +4d2025-12-16 | |
3.8.0 +1.2mo2025-12-11 | |
3.7.1 +2.6mo2025-11-05 | |
3.6.2 +9h2025-07-09 | |
3.5.3 +25d2025-04-28 | |
3.5.2 +19d2025-04-03 | |
3.5.1 +1.2mo2025-03-14 | |
3.5.0 +25d2025-02-05 | |
3.3.2 +1.0mo2024-12-06 | |
3.3.1 +25d2024-11-05 | |
3.2.1 +8d2024-10-10 | |
3.2.0 +1.1mo2024-10-01 | |
3.0.0 +6d2024-08-15 | |
3.0.0-rc2 +2.2mo2024-08-09 | |
3.0.0-rc1 +<1h2024-06-04 | |
2.4.2 +12d2024-06-04 | |
3.0.0-rc0 +20h2024-05-22 | |
3.0.0-alpha.1 +<1h2024-05-21 | |
2.4.1 +3d2024-05-21 | |
2.4.0 +7d2024-05-17 | |
3.0.0-alpha.0 +9d2024-05-10 | |
2.3.0 +2.1mo2024-04-30 | |
2.2.0 +1.1mo2024-02-27 | |
2.1.1 +2.3mo2024-01-25 | |
2.1.0 +6d2023-11-17 | |
2.0.1 +2.1mo2023-11-10 | |
2.0.0 +2d2023-09-07 | |
2.0.0-rc1 +5d2023-09-05 | |
2.0.0-rc0 +2d2023-08-31 | |
2.0.0-beta1 +18d2023-08-29 | |
2.0.0-beta0 +1.2mo2023-08-10 | |
1.4.4 +1d2023-07-01 | |
1.4.3 +21d2023-06-30 | |
1.4.2 +<1h2023-06-08 | |
1.4.1 +1.0mo2023-06-08 | |
1.4.0 +1.5mo2023-05-08 | |
1.3.3 +16d2023-03-24 | |
1.3.2 +5d2023-03-07 | |
1.3.1 +18d2023-03-02 | |
1.3.0 +3d2023-02-12 | |
1.2.4 +5d2023-02-08 | |
1.2.3 +14h2023-02-02 | |
1.2.1 +7d2023-02-02 | |
1.2.0 +6d2023-01-25 | |
1.1.0 +15d2023-01-19 | |
1.0.5 +25d2023-01-04 | |
1.0.4 +12h2022-12-09 | |
1.0.3 +15d2022-12-09 | |
1.0.2 +3d2022-11-24 | |
1.0.1 +3d2022-11-20 | |
1.0.0 +4d2022-11-17 | |
1.0.0-rc7 +7d2022-11-12 | |
1.0.0-rc52022-11-04 |