[Bug]: ts_projects fail on Windows (with standalone strategy) without converting all targets to (composite) project references
#664
Labels
bug
Something isn't working
Comments
|
Example patch that illustrates updating tsconfigs and target definitions to support a successful build of the example: diff --git a/examples/ts_project_dep/a/BUILD.bazel b/examples/ts_project_dep/a/BUILD.bazel
index 1a9e604..0efef93 100644
--- a/examples/ts_project_dep/a/BUILD.bazel
+++ b/examples/ts_project_dep/a/BUILD.bazel
@@ -4,5 +4,7 @@ ts_project(
name = "ts",
srcs = ["a.ts"],
declaration = True,
+ composite = True,
+ incremental = True,
visibility = ["//visibility:public"],
)
diff --git a/examples/ts_project_dep/a/tsconfig.json b/examples/ts_project_dep/a/tsconfig.json
index ced1d5e..c73fe33 100644
--- a/examples/ts_project_dep/a/tsconfig.json
+++ b/examples/ts_project_dep/a/tsconfig.json
@@ -1,6 +1,8 @@
{
"compilerOptions": {
- "declaration": true
+ "declaration": true,
+ "composite": true,
+ "incremental": true
},
// Workaround https://github.com/microsoft/TypeScript/issues/59036
"exclude": []
diff --git a/examples/ts_project_dep/b/tsconfig.json b/examples/ts_project_dep/b/tsconfig.json
index 6cc3296..eb7a86c 100644
--- a/examples/ts_project_dep/b/tsconfig.json
+++ b/examples/ts_project_dep/b/tsconfig.json
@@ -1,4 +1,7 @@
{
// Workaround https://github.com/microsoft/TypeScript/issues/59036
- "exclude": []
+ "exclude": [],
+ "references": [
+ { "path": "../a" }
+ ],
} |
|
Referencing also the unresolved (but stale/closed) issue for sandbox support on windows: bazelbuild/bazel#5136 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What happened?
I'm trying to use
ts_projectwith granular typescript libraries in our monorepo, which works fine on Linux, but fails on Windows due to lack of sandboxing support (I think). It looks like in general ts_project rules are compiling (or attempting to compile) typescript sources outside of the declaredsrcsfor the target, since the depedency source*.tsfiles are available on the path and not just the compiled.d.ts/*.jsfiles. This means we get a "'rootDir' is expected to contain all source files." error when depending on any otherts_project, and/or 2) we get a "EPERM: operation not permitted" error when we compile a dependency in a child directory once and then again in the dependency itselfhttps://github.com/bazelbuild/rules_nodejs/wiki/Debugging-problems-with-ts_project/#ts6059-file-is-not-under-rootdir suggests that this indeed likely related to a standalone spawn strategy, where we have unrelated ts files to the target getting included into the compilation implicitly, but it's unclear what the solve would be on Windows, in the absence of a sandbox spawn strategy.
Version
Development (host) and target OS/architectures: Windows 10 x86_64
Output of
bazel --version: "bazel 7.1.1"Version of the Aspect rules, or other relevant rules from your
WORKSPACEorMODULE.bazelfile: da284adLanguage(s) and/or frameworks involved: rules_ts examples
How to reproduce
Yields:
Turning on
explainFilesindicates the inclusion into the compilation sincea.tsis around and is imported byb.ts:Any other information?
I'm using a user .bazelrc option to move the startup path close to root because of path length limits (but I reproduced with this disabled as well):
I can workaround this by converting all
ts_projectrules that are dependencies into composite typescript projects, and then add references to the tsconfigs for dependent projects (similar to how it's described and performed in https://github.com/aspect-build/rules_ts/blob/main/examples/project_references/README.md), but it's clunky and requires a specialized tsconfig (either tsconfig.json or inline tsconfig in the target definition which is a little more ergonomic, especially if I have multiple ts_project targets per packageIt feels like I have to be doing something wrong, especially since that README suggests it shouldn't be necessary, but maybe this is just a fundamental limitation in standalone/local mode?
The text was updated successfully, but these errors were encountered: