Check for visibiliy, don't just assume reexports should be used.

To save a query, I used a heuristic to choose between rules if more than one provided a given path.  Global taze revealed some cases where the heuristic was wrong.

PiperOrigin-RevId: 239827591
1 file changed
tree: 2a4ee979e8646f8b9334b9d80ee33fceec3dcab6
  1. .bazelci/
  2. .github/
  3. .vscode/
  4. devserver/
  5. docs/
  6. examples/
  7. internal/
  8. third_party/
  9. ts_auto_deps/
  10. .bazelignore
  11. .bazelrc
  12. .gitignore
  13. AUTHORS
  14. BUILD.bazel
  15. CODE_OF_CONDUCT.md
  16. CODEOWNERS
  17. CONTRIBUTING.md
  18. CONTRIBUTORS
  19. defs.bzl
  20. LICENSE
  21. package.bzl
  22. package.json
  23. protractor.conf.js
  24. README.md
  25. version.bzl
  26. WORKSPACE
  27. yarn.lock
README.md

build_bazel_rules_typescript

Looking for documentation for TypeScript bazel rules that used to be here? See https://npmjs.com/package/@bazel/typescript

This repo contains a mirror of some Google-internal bits that support TypeScript development under Bazel.

It contains these utilities:

  • ts_devserver: a Go library and binary that runs a fast local web server which concatenates JavaScript on-the-fly. It requires inputs in a named module format (module ids must be contained in the file, not inferred from the file's path).
  • ts_auto_deps: a Go library and binary which generates BUILD.bazel files from TypeScript sources.
  • tsc_wrapped: a TypeScript program which wraps the TypeScript compiler, hosting it under a Bazel worker.
  • tsetse: a collection of third-party “strictness” checks which we add to the TypeScript compiler.
  • internal/common/*.bzl: some Starlark utility code for running the ts_library rule.

There are no user-facing bits in this repo. These utilities are consumed in https://github.com/bazelbuild/rules_nodejs/tree/master/packages/typescript

Please file issues for ts_library rule and other Bazel rules in that repo.