fix stack trace filename format for transpiled files

[kirkwaiblinger]

resolves #397

[pi0]

Hi dear @kirkwaiblinger

Do you think you can minimize changes (changes to isESM seem not necessary), also making it an opt-in behavior? (Using slashes is not a bug and is supported in modern Windows APIs, but I understand it might be a wanted behavior to use backslash)

Also, I noticed https://github.com/typescript-eslint/typescript-eslint/pull/11546 is already merged, fixing the original typescript-eslint issue. Do you think it is still worth upstreaming it?

[kirkwaiblinger]

Hi dear @kirkwaiblinger

👋

Do you think you can minimize changes (changes to isESM seem not necessary)..

It is, actually! This is what decides between a file:// URL in the stack trace (for ESM) and an ordinary path (for CJS) - which applies regardless of whether the file is TS or JS. This reminds me, though, I had meant to create test cases to illustrate this, but I forgot. I'll get on that.

...also making it an opt-in behavior? (Using slashes is not a bug and is supported in modern Windows APIs, but I understand it might be a wanted behavior to use backslash)

What would be the value in making this configurable? The most (and only?) important consideration I could think of in deciding how to present the filename would be alignment with node, which uses backslashes on CJS paths (and in particular, a path such that path.resolve(filename) === filename regardless of the platform), and file:// URLS for ESM locations, which is more than just a forwardslash-vs-backslash issue.

Also, I noticed typescript-eslint/typescript-eslint#11546 is already merged, fixing the original typescript-eslint issue. Do you think it is still worth upstreaming it?

Yes.

[kirkwaiblinger]

@pi0 I've updated the tests. If you try out various combinations of reverting the changes to eval.ts and running the tests with windows/non-windows, it should hopefully demonstrate pretty clearly the things I'm trying to point out! 🙂