swc reuses _variable name when importing different modules with same filename in CommonJS

[cspotcode]

Describe the bug

When a single file imports multiple different files with the same filenames, and swc uses interopRequireDefault, it reuses the same local variable to store both, when it should use a different local variable.

For example when a single file imports ./foo/bar and ./baz/bar, they are both named bar so the local variable used for both is _bar.

Input code

I can reproduce using the JS API:

const swc = require('@swc/wasm');
swc.transformSync(`
  import A from "./foo/a";
  import B from "./bar/a"
`, {
  module: {type: 'commonjs'}
})

The output is:

"use strict";
var _a = _interopRequireDefault(require("./foo/a"));
var _a = _interopRequireDefault(require("./bar/a"));
function _interopRequireDefault(obj) {
    return obj && obj.__esModule ? obj : {
        default: obj
    };
}

Config

N/A

Expected behavior

Since the 2 imported modules are different, the local variable should be different as well. tsc emits code like this:

const a_1 = __importDefault(require("./foo/a"));
const a_2 = __importDefault(require("./bar/a"));

Version
The version of @swc/wasm: 1.2.58

Additional context
Add any other context about the problem here.

[cspotcode]

Does swc today have a mechanism to request unused variable names in top-level scope? Can this be accomplished with the hygiene pass? It looks like hygiene is concerned with finding collisions between identifiers in the input code, whereas imports are stored on hidden variables that do not appear anywhere in the input source.

[kdy1]

You can use private_name! macro to create a such identifier.
hygiene pass will convert it to actual unused identifier at the end.

[cspotcode]

I see, thanks. It looks like the identifiers are being created today with local_name_for_src. Sometimes it is being wrapped in private_ident!; sometimes not. I'll try adding the missing private_ident! calls and see if that fixes it.

[swc-bot]

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.