Compilation fails with TS6059 under Windows 10 but passes under Windows 11 or Linux about typescript

[jakebailey]

Ah, forgot you gave a case. I had to hack angular to accept a build >5.5.0, but it works!

[jakebailey]

Are you sure it's that specific PR? Or is it an estimate? That error code doesn't feel related and that PR probably wouldn't have affected anything but auto imports.

https://www.npmjs.com/package/every-ts may help you narrow it down between those two nightly builds.

[brodziakm]

I'm not sure, no - sorry if that wasn't clear. I'm certain that it started failing in the nightly 5.4.0-dev.20231222, and it was an educated guess based on the two merge commits that preceded that nightly build (but I could have been thrown off by point-of-reference conversion or misunderstanding the nightly build process.

I'll take a look at every-ts and see if I can help to identify the exact change more accurately.

[brodziakm]

In the meantime, I did discover one more piece of evidence that might be significant or help understand this problem.

I enabled trace resolution and captured the output under different environments and can see that the issue seems to appear after a failed trace resolution, which only happens on Windows 10 when using TypeScript 5.4.0-dev.20231222 or later. This comes up part way through the build.

Under Ubuntu using TypeScript 5.4.3, we get a successful build and this significant part of the trace:

...
'baseUrl' option is set to '/mnt/c/Source/spectrum/libs/spaces', using this value to resolve non-relative module name '@spectrum/spaces/rgb'.
'paths' option is specified, looking for a pattern to match module name '@spectrum/spaces/rgb'.
Module name '@spectrum/spaces/rgb', matched pattern '@spectrum/spaces/rgb'.
Trying substitution '/mnt/c/Source/spectrum/dist/lib/spaces/rgb/index.d.ts', candidate module location: '/mnt/c/Source/spectrum/dist/lib/spaces/rgb/index.d.ts'.
File '/mnt/c/Source/spectrum/dist/lib/spaces/rgb/index.d.ts' exists - use it as a name resolution result.
======== Module name '@spectrum/spaces/rgb' was successfully resolved to '/mnt/c/Source/spectrum/dist/lib/spaces/rgb/index.d.ts'. ========
...

Under Windows 10 using TypeScript 5.3.3 we get a successful build and this significant part of the trace:

...
'baseUrl' option is set to 'C:/Source/spectrum/libs/spaces', using this value to resolve non-relative module name '@spectrum/spaces/rgb'.
'paths' option is specified, looking for a pattern to match module name '@spectrum/spaces/rgb'.
Module name '@spectrum/spaces/rgb', matched pattern '@spectrum/spaces/rgb'.
Trying substitution 'C:\Source\spectrum\dist\lib\spaces\rgb\index.d.ts', candidate module location: 'C:\Source\spectrum\dist\lib\spaces\rgb\index.d.ts'.
File 'C:/Source/spectrum/dist/lib/spaces/rgb/index.d.ts' exists - use it as a name resolution result.
======== Module name '@spectrum/spaces/rgb' was successfully resolved to 'C:/Source/spectrum/dist/lib/spaces/rgb/index.d.ts'. ========
...

And, in the equivalent part of the trace under Windows 10, which presumably relates to the first point of build failure based on a comparison of the trace output, we get:

...
'baseUrl' option is set to 'C:/Source/spectrum/libs/spaces', using this value to resolve non-relative module name 'rgb/src'.
'paths' option is specified, looking for a pattern to match module name 'rgb/src'.
'baseUrl' option is set to 'C:/Source/spectrum/libs/spaces', using this value to resolve non-relative module name 'rgb/src'.
Resolving module name 'rgb/src' relative to base url 'C:/Source/spectrum/libs/spaces' - 'C:/Source/spectrum/libs/spaces/rgb/src'.
Loading module as file / folder, candidate module location 'C:/Source/spectrum/libs/spaces/rgb/src', target file types: TypeScript, JavaScript, Declaration, JSON.
File 'C:/Source/spectrum/libs/spaces/rgb/src.ts' does not exist.
File 'C:/Source/spectrum/libs/spaces/rgb/src.tsx' does not exist.
File 'C:/Source/spectrum/libs/spaces/rgb/src.d.ts' does not exist.
File 'C:/Source/spectrum/libs/spaces/rgb/src.js' does not exist.
File 'C:/Source/spectrum/libs/spaces/rgb/src.jsx' does not exist.
File 'C:/Source/spectrum/libs/spaces/rgb/src/package.json' does not exist according to earlier cached lookups.
File 'C:/Source/spectrum/libs/spaces/rgb/src/index.ts' exists - use it as a name resolution result.
======== Module name 'rgb/src' was successfully resolved to 'C:/Source/spectrum/libs/spaces/rgb/src/index.ts'. ========
...

* file names changed from our actual source but the structure is equivalent

This seems to come up about 50k lines through the trace output, and prior to this point the trace output is largely similar with minor differences only.

[jakebailey]

If you're confident about the two nightly versions then you're probably right about the PR, as that's the only change between them. Funky: 93e6b9d...fbcdb8c

[brodziakm]

I gave every-ts a shot, and encountered problems when using the built version of typescript beneath ng-packagr. That aside, I am confident that the problem was introduced in 5.4.0-dev.20231222

The changeset in question touches the compiler core endsWith / startsWith in relation to case sensitivity which seems to be used for path matching, so I'd hazard a guess that something in this area might have had an impact. But, why this would be a problem in Windows 10 but is apparently fine under Windows 11 is beyond my understanding.

[brodziakm]

One more thing that I just found is that the emitted .d.ts has changed and this seems to cause the problem.

Using TypeScript nightly 5.4.0-dev.20231221 produces this which compiles successfully (this is one sample file, names changed from our codebase but illustrating the structure):

import { ColorSegment } from './rgb-segment';
export declare const RgbConverter: {
    readonly encoding: Map<ColorSegment<import("@spectrum/spaces/rgb").ColorSpace>, string>;
};
//# sourceMappingURL=rgb-converter.d.ts.map

After updating to use TypeScript nightly 5.4.0-dev.20231222 we get this which does not compile:

import { ColorSegment } from './rgb-segment';
export declare const RgbConverter: {
    readonly encoding: Map<ColorSegment<import("rgb/src").ColorSpace>, string>;
};
//# sourceMappingURL=rgb-converter.d.ts.map

It seems that these imports in the generated declaration files relate to defaulting generics. This may not be the full picture, but again, it might help to identify the problem.

[brodziakm]

If it helps, I have prepared a Git repository that reproduces the problem.

Repository: https://github.com/brodziakm/typescript-57926

Instructions are in the README.md, but, I'll include here for completeness:

Successful build under TypeScript nightly 5.4.0-dev.20231221

To reproduce the successful build (on Windows 10):

1. npm install (it is pre-configured to use 5.4.0-dev.20231221)
2. npm run build
3. Observe successful output
4. Look at dist/lib/spaces/rgb/rgb-converter.d.ts and see that it contains this line:
   readonly entries: Map<ColorSpace<import("@spectrum/spaces/rgb").Notation>, string>;

Failed build under TypeScript nightly 5.4.0-dev.20231222

To reproduce the failed build (on Windows 10):

1. Update package.json so that it uses TypeScript 5.4.0-dev.20231222
2. npm install
3. npm run build
4. Observe TS6059 error relating to notation.ts
5. Look at dist/lib/spaces/rgb/rgb-converter.d.ts and see that it contains this line:
   readonly entries: Map<ColorSpace<import("rgb/src/notation").Notation>, string>;

Note that this seems to work just fine under a Linux-based OS (but I have not tested exhaustively).

Explainer

In working through the issue I haven't (yet) been able to narrow the problem down in isolation. So, the included example is structured using Angular's 'ng-packagr', which generates Angular library bundles, including secondary entry points, from a structured folder layout.

The provided structure illustrates one particular library that encounters a build-time problem in one of the secondary entry points.

The 'ng-packagr' invocation leverages tsconfig.lib.json when building, and this configuration defines the appropriate library paths. These paths should be used in the generated declarations. The tsconfig.json in the same folder is configured so that the paths map to the source folders (which is a typical and convenient configuration for working in the IDE). This may or may not be significant.

[fatcerberus]

Possibly related: #57956

[jakebailey]

@brodziakm Can you try the build on #57973 (comment) to see if it fixes your issue?

[brodziakm]

Wonderful! Thank you!