ts-node: Sourcemap failing when filename has spaces or is otherwise affected by URL percent-encoding

EDIT changed the title to describe the problem discovered after investigation. Old title was “Invalid line number using "transpileOnly": true” - @cspotcode

Expected Behavior

Error stacktrace should show the exact, correct line number when using "transpileOnly".

Actual Behavior

It doesn’t, the line number is off by around 8, although I imagine this changes.

Understandably, it is the same line or close to the line that appears in the compiled JS file, except that the file ends in .ts

(node:8464) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'ok' of undefined
    at Function.handle (src\api\routes\commands\POST index.ts:85:19)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
    at src\api\index.ts:305:21

The file can be seen here: https://github.com/edqx/swagclan/blob/ee46636fcb42ce5c82c596861bab5b8ab963605b/src/api/routes/commands/POST index.ts#L77

And here is the compiled file: https://gist.github.com/edqx/8bbc01d58ee0f759b09984920cd15bc3

I’m unable to create a minimal reproduction, currently I’m only looking for advice if this issue has been stumbled upon before, through searching the issues, I found #1055 but that issue has since been closed and did not fix my issue. I will, however, try to create one if really required, although I hope I have provided enough information as it is.

Specifications

ts-node v9.1.1 node v14.13.0 compiler v4.2.4

tsconfig.json, if you’re using one:

{
  "compilerOptions": {
    "target": "ES2020",
    "module": "commonjs",
    "outDir": "./dist",
    "strict": true,
    "noImplicitAny": false,
    "esModuleInterop": true,
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true,
    "paths": {
      "src/*": ["./src/*"]
    }
  },
  "ts-node": {
    "transpileOnly": true
  }
}

Operating system and version: Windows 10.0.19041 Build 19041

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 15

Most upvoted comments

I figured it out. Final conclusion:

This is not related to --transpile-only; it happens with or without --transpile-only

This is already fixed on our main branch by #1160, even though the fix was not intentional. This may seem confusing but remember it is not related to transpile-only. #1160 changed the way we append sourceMappingURL, which also affected our non-transpile-only codepath.

Since the fix in #1160 was accidental, I’ve also implemented #1330 to make our internal logic understand percent-encoded sourceMappingURLs.

This fix will be released in v10 which I hope to release this weekend. In the meantime you can install directly from git: npm install TypeStrong/ts-node#main

I’m going to close this issue since all necessary work has been completed. Thank you again @edqx for your assistance locating the underlying issue.

cspotcode on May 22, 2021

In the 4.1.1 release https://github.com/Microsoft/TypeScript/issues?utf8=✓&q=is%3Aissue+milestone%3A"TypeScript+4.1.1"+is%3Aclosed+

They implemented https://github.com/microsoft/TypeScript/issues/40951

It percent-encodes the sourceMappingURL

cspotcode on May 22, 2021

Thanks, this is very helpful. This bit looks interesting:

//# sourceMappingURL=POdata:application/json;charset=utf-8;base64,eyJ2ZXJzaW9uIjozLCJmaWxlIjoiQzovVXNlcnMvRWR3YXJkL

ts-node needs to manipulate the //# sourceMappingURL comments at the end of each compiled file. Perhaps, in this case, something went wrong with that manipulation.

For example, spaces in a URL are encoded as %20. The difference between %20 and is 2 characters, the same length as PO. I wonder if that’s the culprit. Maybe we assumed a space, when it was actually %20, and so we didn’t manipulate the string correctly.

I’m working on another task at the moment so I’ll come back to this later. But I think you may have found the root cause.

cspotcode on May 22, 2021

Thanks for the reply again, I have only looked at the project earlier today and if I’m completely honest, I had completely forgotten about this issue as I didn’t really encounter it aside from my manual “trying to break it” by adding a random line that would error. You’re right that I failed to make my reproductions have the same error.

In regards to the trick that you use in your tests (adding the whitespace at the start of the file), you’re right that the stacktrace remained at line 85 while the actual error should have occurred on line 344.

I’ll start debugging through the package itself now and get back on my results.

As I began this while you posted your next 2 comments, I haven’t looked into the sourcemap with the filenames since it seems as though that makes no difference, and I can confirm that ts-node is indeed compiling the correct file and running said compiled file.

edqx on May 22, 2021