Sourcemap - names array empty for all files

[slaneyrw]

TypeScript Version: 1.8.34.0
Module System: AMD
ECMAScript Version: ECMAScript 5
VS 2015 Update 3

All of my map files have the names array empty. I would expect that to have been populated.
This has been an issue with VS2015 with all updates

Code

class HomeIndex {

    someVar: number;

    constructor() {
        this.someVar = 0;
    }

    onLoad = () => { 
    };

    dispose() {
    };

}

export = HomeIndex;

Generated map

{
  "version": 3,
  "file": "Index.js",
  "sourceRoot": "",
  "sources": [ "Index.ts" ],
  "names": [],
  "mappings": ";;IAAA;QAII;YAIA,WAAM,GAAG;YACT,CAAC,CAAC;YAJE,IAAI,CAAC,OAAO,GAAG,CAAC,CAAC;QACrB,CAAC;QAKD,2BAAO,GAAP;QACA,CAAC;;QAEL,gBAAC;IAAD,CAAC,AAdD,IAcC;IAED,OAAS,SAAS,CAAC"
}

Expected behavior:
names array should contain values for members and variables
Actual behavior:
names array empty

[mhegazy]

this is not a supported feature at the moment. the compiler does not emit names to the source map output.

[nojvek]

Is this something that is relatively easy to fix as part of sourcemap emit step ?

[yudhistira-arya]

Is this issue still being actively looked at?

[grzegorzjudas]

So I just configured debugging in VSCode and was really amazed by how great it works... until I noticed the variable names that is. Came here after research on why, when I put a breakpoint I see the transpiled variable names instead of the original ones, even though I have the source maps working. I can't use the original names in the debug console either, which breaks the whole experience.

I'd say it's a pretty important, but I have no concept on how complex it is to implement, so I'll just leave it here in hope it'll increase the priority.

[axelcostaspena]

Also without the knowledge about the current implications of fixing this, but the reality is that this breaks 25% of typescript debugging on IntelliJ IDEA, VS Code, etc, whenever you need to evaluate code with imported symbols.

https://youtrack.jetbrains.com/issue/WEB-43973
https://stackoverflow.com/questions/59864978/typescript-undefined-constant-during-debugging-session

[RayzRazko]

This is extremely frustrating. Sometimes it makes it almost impossible to debug the code. I'm surprised this issue is not prioritized.

[FrancescoBorzi]

Confirmed. This is extremely important.

[Yehonal]

I ended-up here from this stackoverflow issue:

https://stackoverflow.com/questions/56669155/debugging-vs-code-with-typescript-shows-transpiled-variable-names-instead-of-rea

I literally cannot debug my typescript node application because exported variables are not recognized by the debugger.

And this issue exists since 2016! How could it be?

That's the evidence:

[CristianPi]

Is there a way to instruct the compiler (with the compiler apis) to emit names or it's just impossible to do with the current state of the compiler?
Can i set some data to an Expression or a PropertyAccess to map that node to an old one , so the compiler can emit the correct names?

Example:

let a = 0;

transform the declaration to ctx.a = 0; or exports.a = 0;

set the source map name for the ctx.a PropertyAccess to a;

[taylorthurlow]

It seems more likely that we're just missing something? It seems absurd that this issue has so few comments, and has been open this long.

[Yehonal]

It seems more likely that we're just missing something? It seems absurd that this issue has so few comments, and has been open this long.

Indeed. Maybe TS people are not get used with code debugging such happens for the other languages 🤷‍♂️

[epikhighs]

If you're willing, there is a "workaround" for being able to debug TS code. If you happen to be using babel and/or webpack, then basically, you have to transpile the code into CJS module format and debugging should be fine. This is how I'm getting debugging to work in my project that uses TS, webpack and babel.

webpack/webpack#3957 (comment)

[taylorthurlow]

Ahhh OK that's it then, it must be because people are using webpack. I haven't done anything significant in JS/TS before, and I'm working on an Electron app, and getting webpack, typescript, and electron working was too complicated for me to wrap my head around, so I got it working without webpack.

Thanks for the insight, I'll probably approach webpack again when it's not more important to be getting this app working.

[epikhighs]

@taylorthurlow strictly speaking, webpack might not be necessary -- all it does it orchestrate the underlying tools for you -- so you might be able to use babel with TS directly, but you'd have to order it so that it the TS compiler first transforms TS to JS, then babel transpiles the JS to CJS format. Then, if you're in a node.js app then you can use CJS directly. Or if you're in the "browser/UI" world, then you'd need something to load the CJS into the browser.

[taylorthurlow]

@epikhighs I'll investigate that option too, thanks for the tip.

[vanpana]

Still no update to this? It's so painful to debug TS code.

[BenMoses]

Alos having this issue. I am unable to implement Webpack into my project to work around this bug. This seems like it shouldn't be too complicated to fix / implement, am I being too naive?

[Christilut]

Same problem here. Very hard to use the debug console.

As a (painful) workaround, you can see what actual variable names you should use in the debugger, eg instead of Foo.bar() it might be _Foo.Foo.bar()

[pavel-luhin]

Notice same issue. Global config variables almost always undefined in debugger, and cannot ‘Evaluate Expression’ in WebStorm IDE.

[bingtimren]

Same issue. This makes debugging with IDE awful. Wish there's a solution to this.

[vkria-sftsrv]

Same issue. It causes ReferenceError: <var> is not defined in WebStorm in Evaluate Expression window...

[georgyfarniev]

@RyanCavanaugh @weswigham @alan-agius4 hello, is there any plans to include this issue in the roadmap? I also find it extremely frustrating.

At least, can you give me a brief insight how difficult will it be to solve in case if I will try to create PR for this issue?

Wish you to have a nice weekend.

[scpedicini]

2022, any updates on this? Best practices in terms of getting this working without being forced to use webpack in webstorm? I use parcel, is it possible to get this working using that bundler?

[imfycc]

亲，您的邮件我收到了，感谢您的来信。

[spyro2000]

It's been 7 years now.

SEVEN.
YEARS.

And it's still not possible to debug/evaluate an imported function in typescript. I just can't believe this has never been fixed. It's just broken. :(

[segevfiner]

I think esbuild does output the names array, you can try using it instead of tsc, or use it via tsup.

[espenja]

I hit this issue today, and got it working by using tsup/esbuild
Importantly, treeshake had to be set to false, or variables would all be undefined again.

Here's the tsup config I ended up with:

defineConfig({
  outDir: DIST_FOLDER,
  entry: glob
    .sync("src/functions/*/index.ts", {
      cwd: path.resolve(__dirname, "../"),
      absolute: true
    })
    .map(globbify),
  keepNames: true,
  sourcemap: true,
  minify: false,
  format: "cjs",
  target: "node20",
  platform: "node",
}

[pflannery]

I have this issue too. Im using version 5.4.5. It only happens to me when compiling from esm to cjs.

Esm named imports get wrapped into a generated object (here) which then causes issues with debugging the original source code.

Example:

// esm
import { workspace } from 'vscode'
const codeLensEnabled = vscode.workspace.getConfiguration().get('editor.codeLens')

// translates to 
const vscode_1 = require("vscode"); // debuggers can't resolve the generated name
const codeLensEnabled = vscode_1.workspace.getConfiguration().get('editor.codeLens')

One workaround is to use import * as {alias}

e.g.

// esm
import * as vscode from 'vscode'
const codeLensEnabled = vscode.workspace.getConfiguration().get('editor.codeLens');

// translates to
//....emit helper code omitted here....
const vscode = __importStar(require("vscode")); // debuggers work with this
const codeLensEnabled = vscode.workspace.getConfiguration().get('editor.codeLens');

But this isn't ideal and limits esm import features.

It would be great if typescript could output a left-hand object destructor (when the target supports destructoring)

const { workspace } = require("vscode");
const codeLensEnabled = workspace.getConfiguration().get('editor.codeLens')

It's either that or typescript will need to add the original names[] and their associated mappings: "..." in to the source map.
I'm guessing the source map update would most likely need to be put somewhere here?

Going to take someone with good experience of the typescript source code to fix this.