TypeScript 4.7 source map file extension mismatch

[unional]

Bug Report

🔎 Search Terms

source map, extension

🕗 Version & Regression Information

TypeScript 4.7.2

⏯ Playground Link

Not a Playground link, but the repro is here: https://github.com/unional/tersify/tree/webpack

To repro it, run yarn bundle and open the demo.html in browser.

You can see that the source-map-loader able to get the unpartial/ts/index.ts file, but not the files it referenced (./required.js, ./unpartial.js).

This is because the files are actually in TS. i.e. required.ts and unpartial.ts.

I'm not sure if this is a TypeScript 4.7 bug or source-map-loader needs to be updated to support this.
But given it was working prior to TypeScript 4.7 and JS in general,
it is likely that the sourcemap generated by TypeScript 4.7 needs some adjustments.

💻 Code

The referenced code unpartial is here: https://github.com/unional/unpartial
It is build with sourceMap: true in tsconfig.json

Since this is related to how the code is build and consumed, I don't have a minimal repro for this.
But the library I chose to demo this are simple enough that should be simple enough.

🙁 Actual behavior

Unable to consume the source map generated by TypeScript library using TS 4.7

🙂 Expected behavior

Should work, as shown in this branch: https://github.com/unional/tersify/tree/webpack-old

[arendjr]

This seems to be another unintended consequence of the fact that TypeScript does not rewrite extensions to source files for you. #49083 is asking for a change in this behavior.

[rbuckton]

@unional the branch you mention above (https://github.com/unional/tersify/tree/webpack) does not seem to be available as I get a 404 when trying to visit the link, so I'm not 100% clear on the context.

This is a longstanding TypeScript behavior. We do not rewrite the extensions you use in your import and export declarations, so if your module reference uses a .js extension, we emit that verbatim. We also disallow module references that have a .ts extensions, since that won't be the correct extension at runtime.

Are you certain this is related to TS 4.7? From what I can tell you also recently changed your module references from an extensionless form to include the .js extension just over two weeks ago (per unional/unpartial@c77f694).

[unional]

Hi, I have restored the branch.

Yes this TS 4.7 related and yes, it is related to the .js extension.

In TS 4.7, in order to support moduleReolution: NodeNext, the .js extension has to be added to the import path, which seems to break the source map.

This is likely caused by the source map is referencing the actual file path (.ts) instead of the output file path (.js).

[rbuckton]

Source maps are supposed to reference the source file path: https://sourcemaps.info/spec.html#h.mofvlxcwqzej. The "file" entry (if present) references the generated output, but the "sources" array should always reference the original source file path.

I'm not clear on what you are saying is broken here. It's possible that source-map-loader does not understand the TypeScript behavior. I don't believe this is specific to 4.7, as we have supported the ability to append a .js extension for years now, though that might have been the trigger for you to switch to using the .js extension in your project.

[unional]

I'm not clear on what you are saying is broken here

Please follow the steps and description above:

To repro it, run yarn bundle and open the demo.html in browser.

You can see that the source-map-loader able to get the unpartial/ts/index.ts file, but not the files it referenced (./required.js, ./unpartial.js).

The bottom line is, the source-map generated by TypeScript works in one way, does not in another.
TypeScript transpile code to JavaScript. and that's we get distributed, along with its source map.

When consuming a package, written in TypeScript or not, the source map should work. The fact that it was written in TypeScript should be out of the picture.

[rbuckton]

I've just revisited this issue and I do not see anything that TypeScript is doing wrong here. The source maps we emit are correct, and looking the bundled outputs in both the Chrome dev tools and Edge dev tools correctly show the original .ts source files regardless as to the extensions used in the import declarations. Up until recently, TypeScript's policy has been for imports to reflect the extensions you would consume at runtime, though we're relaxing that slightly in the upcoming 5.7 release. Even with that forthcoming change, the generated output and source map we are emitting for unpartial appear to be correct.

If there was a bug here, I expect it was either in source-map-loader, webpack, or the in-browser developer tools. As this is bundled output, it is likely that something in the bundler may have been failing to reference the correct source path for those files in the source map's "sources", or may have failed to include source text in the source map's "sourcesContents".

I am closing this issue as I cannot reproduce it and there does not appear to be any further action that can be taken.