"The inferred type of X cannot be named without a reference to Y" (TS2742)

[tinganho]

npm_link_package labels in data and deps attributes in ts_project is causing typescript to issue portability errors.

Here is a reproduction and more info in the README:
https://github.com/tinganho/transitive-deps-bug

[jbedard]

This might be an issue with symlinks and not only rules_ts? See microsoft/TypeScript#29808 (comment)

[gregmagolan]

Yup. Looks like this is a Typescript + symlinked node_modules structure issue and not specific to rules_js or Bazel.

Issue in TypeScript repo is very active: microsoft/TypeScript#47663

@mrmeku has a repro outside of Bazel with pnpm, which also uses a symlinked node_modules structure like rules_js: https://github.com/mrmeku/portable_types_repro (from microsoft/TypeScript#47663 (comment))

[gregmagolan]

One of the work-arounds in microsoft/TypeScript#47663 is to import type {} from "transitive": microsoft/TypeScript#47663 (comment).

I was able to get this reproduction to work by doing that for the transitive closure with this change:

$ git diff
diff --git a/packages/a/BUILD.bazel b/packages/a/BUILD.bazel
index 0744ca1..9be754c 100644
--- a/packages/a/BUILD.bazel
+++ b/packages/a/BUILD.bazel
@@ -5,5 +5,8 @@ package(default_visibility = ["//visibility:public"])
 ts_test(
     name = "a",
     srcs = ["foo.ts"],
-    deps = ["//packages/b:b"]
+    deps = [
+        "//packages/b:b",
+        "//packages/c:c",
+    ]
 )
\ No newline at end of file
diff --git a/packages/a/foo.ts b/packages/a/foo.ts
index faf0838..c227a19 100644
--- a/packages/a/foo.ts
+++ b/packages/a/foo.ts
@@ -1,4 +1,6 @@
 import { Foo } from '@myorg/b/bar';
+import type {} from '@myorg/b/bar';
+import type {} from '@myorg/c/qux';
 
 export interface Offline {
     pluginRegistry: Foo | undefined;
diff --git a/packages/b/bar.ts b/packages/b/bar.ts
index 44d3558..d8e7756 100644
--- a/packages/b/bar.ts
+++ b/packages/b/bar.ts
@@ -1,4 +1,5 @@
 import { Bar } from '@myorg/c/qux';
+import type {} from '@myorg/c/qux';
 
 export interface Foo {
     bar: Bar[];

[gregmagolan]

Until the underlying problem with Typescript and the symlinked node_modules structure is fixed, a work-around will be needed.

[tinganho]

Seems like indeed it is a TypeScript bug. Described more in here:

You get this error any time the declaration emitter can't synthesize a workable specifier for a module which it needs to name a type from. For example, if it appears that the only legal path is ../../other_module/foo via some file that's in <>/whatever, then that's not likely to work because the disk layout of the produced artifacts don't really have implicit dependencies on what peer directories of the output directory have.
The logic to synthesize these specifiers starts with the easy route of "Has this already been imported?", in which case re-use is easy and fine. Immediately past that lie many dragons and it's easy to get into a novel corner case where there is a speakable name to a module but TS just can't figure it out. Adding the import yourself is the easiest way to resolve the situation.

microsoft/TypeScript#48212 (comment)

I think the issue boils down to: transitive deps being resolved to outside the project?

[tinganho]

@gregmagolan I had closer look at the the minimum reproducible project today. I noticed the symlink structure is not exactly described in PNPM:

Note, that under node_modules/.aspect_rules_js/@myorg+b@0.0.0/node_modules/@myorg the symlink c is not pointing to ../../@myorg+c@0.0.0/node_modules/@myorg/c as in PNPM docs:

The project is under sandbox/darwin-sandbox/3 but the symlink target is outside of the project subtree?

Note the c package is stored node_modules/.aspect_rules_js/@myorg+c@0.0.0/node_modules/@myorg/c, which the b package doesn't symlink to?

[tinganho]

I'm thinking if the symlink target is being kept in the project's subtree. It might fix the issue?