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

[brodziakm]

🔎 Search Terms

"TS6059", "Windows 10"

🕗 Version & Regression Information

• This changed between versions 5.4.0-dev.20231221 and 5.4.0-dev.20231222
• This changed in commit or PR Add auto-import for the package.json imports field

⏯ Playground Link

No response

💻 Code

No response

🙁 Actual behavior

When compiling under Ubuntu Linux (containerised or via WSL), or on Windows 11: compilation of all modules is successful.

When compiling under Windows 10: compilation fails with TS6059 errors.

🙂 Expected behavior

Compilation is successful on all operating systems.

Additional information about the issue

We discovered this problem on a large existing Angular codebase a few days after updating to Angular 17.3 along with TypeScript 5.4.3. We didn't discover this immediately because our CI processes run in Linux, and the build passes quite happily under this OS.

To narrow down the issue I have tried retaining Angular 17.3 but downgrading to Typescript 5.3.3, and the build passes on Windows 10. I then tried various nightly builds and found that:

• The build is successful when using TypeScript 5.4.0-dev.20231221
• The build fails when using 5.4.0-dev.20231222

We subsequently tried building on a Windows 11 workstation (it passes), and via a WSL Ubuntu terminal (it also passes).

This leads me to believe that the changes under #55015 might have had an unexpected impact, particularly with regards to case insensitive paths specifically on Windows 10. I don't believe that Angular 17.3 has caused the problem because the problem does not exist when compiling under different versions of TypeScript.

I have been unable to narrow down a minimal reproduction of the problem because, other than the different operating system, it isn't clear what the specific problem is in the code.

For what it's worth, the Angular project is broken down into multiple libraries, and each library has multiple secondary entry points. We see one of the library secondary entry point builds fail with TS6059, but only under Windows 10. Some upstream libraries and library secondary entry points build correctly.

[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?

[jakebailey]

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