Closed cjjob closed 4 months ago
I assume it is because types are not being explicitly declared and depend on the underlying .ts
files. When one ts_project
(a) depends on another (b), the types from (b) must be fully exposed in the .d.ts
file since the original .ts
is gone (not in the sandbox when (a) is compiled).
This is what --isolatedDeclarations will prevent by forcing your .ts
to be written such that .d.ts
have all the type information without the underlying .ts
implementation.
Can you verify this? I thought this was documented better so maybe we just need to update that troubleshooting page with more info.
Sorry for the slow response. As far as I can tell, the flag you mentioned does not exist anymore but I presume (please correct me if wrong!) that --isolatedModules
is either the same flag renamed, or the closest surviving option in terms of intended behaviour.
I tried two things.
tsconfig.json
to set this attribute to true
.tsc.sh
script as a command line arg (using the args
attribute of ts_project
rule).Unfortunately, neither worked. Though, we have successfully sidestepped this issue compiling using the swc
rule from aspect_rules_swc
(after auto-converting our tsconfig.json
file an .swcrc
config).
That flag is new and will be in the next typescript release I believe. I mention it because it disallows code that normally causes the issue you're having, IIUC.
SWC only transpiles to .js, the type-checking or dts transpiling wouldn't be effected. So either something else changed to fix it for you, or nothing is causing tsc to run at all.
Hmm, I'm pretty certain that no other code changes took place, but, regrettably, don't have the bandwidth to dig further :(
I will close this as I've been unable to demonstrate to you that there is a genuine issue (ideally would have provided you with a minimal case to reproduce the issue). Thank you for time and comments!
What happened?
Summary
We are observing that a package compiles correctly with
tsc
but fails to build withbazel build path/to:target
, where the target is defined using thets_project()
rule. We believe this could be a bug as the documentation suggests "code that works withtsc
should work withts_project
with a few caveats", and we do not appear to satisfy the caveat conditions (although, I have limited TypeScript knowledge so this might not be a bug).There are different TypeScript compilation errors, for example:
error TS2339: Property 'autoEat' does not exist on type 'Bot'.
222 this.bot.autoEat.options.priority = "foodPoints";
error TS7006: Parameter 'item' implicitly has an 'any' type.
433 bot.on("autoeat_started", (item, offhand) => {
The full distinct list of errors we see are
TS2339
,TS2345
,TS7006
.Debugging steps
We got the exact command that
bazel
is failing on during thebuild
. For reference it is:cd /root/.cache/bazel/_bazel_root/98709fea43daaa81054092f92e9928bc/sandbox/processwrapper-sandbox/4301/execroot/_main && exec env - BAZEL_BINDIR=bazel-out/k8-fastbuild/bin TMPDIR=/tmp /root/.cache/bazel/_bazel_root/install/c8ddc30f81d03fbb6c764cadbda081c8/process-wrapper '--timeout=0' '--kill_delay=15' '--stats=/root/.cache/bazel/_bazel_root/98709fea43daaa81054092f92e9928bc/sandbox/processwrapper-sandbox/4301/stats.out' bazel-out/k8-opt-exec-ST-13d3ddad9198/bin/external/aspect_rules_ts~~ext~npm_typescript/tsc.sh --skipLibCheck --project agents/minecraft/tsconfig.json --outDir agents/minecraft/dist --rootDir agents/minecraft --declarationDir agents/minecraft/dist
We have then dug into some potential issues.
tsconfig.json
We think this can be ruled out because if we run the following two commands to get the respective
tsc
andbazel
transpilation configs the resulting files summarising config settings are identical:tsc
only:tsc --skipLibCheck --project agents/minecraft/tsconfig.json --outDir agents/minecraft/dist --rootDir agents/minecraft --declarationDir agents/minecraft/dist --showConfig >> tsc.txt
bazel build
's subcommand:BAZEL_BINDIR=bazel-out/k8-fastbuild/bin bazel-out/k8-opt-exec-ST-13d3ddad9198/bin/external/aspect_rules_ts~~ext~npm_typescript/tsc.sh --skipLibCheck --project agents/minecraft/tsconfig.json --outDir agents/minecraft/dist --rootDir agents/minecraft --declarationDir agents/minecraft/dist --showConfig >> tsc_bazel.txt
Versions
We have verified that tool versions match:
tsc
is version5.4.5
, verified with:tsc --version
BAZEL_BINDIR=bazel-out/k8-fastbuild/bin bazel-out/k8-opt-exec-ST-13d3ddad9198/bin/external/aspect_rules_ts~~ext~npm_typescript/tsc.sh --version
node
is version 18.18.2, verfied with:node --version
MODULE.bazel
installs this version explicity:node = use_extension("@rules_nodejs//nodejs:extensions.bzl", "node", dev_dependency = True)
node.toolchain(node_version = "18.18.2",)
BAZEL_BINDIR
Where things begin to go wrong is with
BAZEL_BINDIR
.If we switch the
BAZEL_BINDIR
everything will compile. SoBAZEL_BINDIR=.
):BAZEL_BINDIR=. bazel-out/k8-opt-exec-ST-13d3ddad9198/bin/external/aspect_rules_ts~~ext~npm_typescript/tsc.sh --skipLibCheck --project agents/minecraft/tsconfig.json --outDir agents/minecraft/dist --rootDir agents/minecraft --declarationDir agents/minecraft/dist
bazel build
:BAZEL_BINDIR=bazel-out/k8-fastbuild/bin bazel-out/k8-opt-exec-ST-13d3ddad9198/bin/external/aspect_rules_ts~~ext~npm_typescript/tsc.sh --skipLibCheck --project agents/minecraft/tsconfig.json --outDir agents/minecraft/dist --rootDir agents/minecraft --declarationDir agents/minecraft/dist
So, given the error seems to suggest that TypeScript can't find the types, maybe it's an issue with Bazel installing the packages?
Version
Development (host) and target OS/architectures:
Output of
bazel --version
:bazel 7.1.1
Version of the Aspect rules, or other relevant rules from your
WORKSPACE
orMODULE.bazel
file: We are usingMODULE.bazel
. Below is the contents with only JS/TS components retained.Language(s) and/or frameworks involved: TypeScript/JavaScript
How to reproduce
No response
Any other information?
Missing module imports
When we built with
bazel build path/to:target
we also originally had some errors relating to missing modules that did not happen with thetsc
compilation. We resolved by adding the packages to ourdependencies
inpackage.json
but it's worth noting that this was necessary in the first instance.