Function arguments do not match local inspect options

[brianmhunt]

It seems that in some circumstances function arguments use the global variable names. For example:

// one file
const r: number = 1

// another file
function x (r: number) {
  // r transpiles as `function (r2) { ... }`
}

I presume the reproduction/cause is trivial here, but I can elaborate if needed.

This exhibits as a problem when debugging. Specifically, if one tries to access r or add breakpoints/logpoint based on r it'll use the global, rather than the local function argument. This is not the expected/desirable behaviour. The workaround is for developers to look into the Scope => Local in DevTools to see what the variable actually is named, which is not obvious/intuitive and adds cycles.

It would be better if the transpiled output honoured the function argument names. For example:

// Given:
function x (r) { console.log(r) }

// Current
function x (r2) { console.log(r2) }

// Desirable example
function x (params) { const { r } = params; console.log(r) }

There are other options e.g.

1. a globals object so the global is accessed as g.r
2. a prefix g_r for the global

Thank you, esbuild is looking amazing!

[brianmhunt]

@evanw I wonder if this is resolved with #1296.

When I get a chance I'll check it out and if it is I'll close this issue, but if you feel it's definitely resolved please feel free to close this.

[privatenumber]

Sounds like your request is actually about the transpiled code, but if you're using source-maps, then yes #1296 fixes it:

• REPL

• Source Map Visualization (Hover over r2)

[brianmhunt]

Thanks @privatenumber I didn't know about that replication system. We're seeing bugs in the sourcemap name and that looks like the perfect place to replicate (and then I'll report here / in a new issue).

[brianmhunt]

This continues to be an issue:

@brianmhunt ➜ (main) $ npx esbuild --version
0.15.10

(Noting that noting in 0.15.11 and 0.15.12 related to this)

@evanw in case the issue was unclear before here's what it looks like in practice:

[privatenumber]

I think what you're describing is more of a limitation with Chrome's console not being able to map variables to the ones in the source map:

privatenumber/tsx#98 (comment)

[evanw]

I'm closing this issue because this is a known limitation of source maps, and I don't want to expand esbuild's scope to try to add hacks like this to the generated code to try to improve debugger support. The source maps that esbuild generates now include names mappings, so arguably this is something that the debugger could now implement itself if they chose to do this.

[brianmhunt]

Thanks @evanw .

For ease of reference / future readers, this has been a bug/omission in Chromium for what looks to be around 7 years, but looks to be down to only one blocker. [1]

There doesn't seem to be an issue for Bugzilla / Mozilla, that I could find. [2]

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=327092
[2] https://bugzilla.mozilla.org/buglist.cgi?quicksearch=names+sourcemap yields no results.