Bogus "duplicate identifier" when checking JS code

[wlinna]

TypeScript Version: >= 3.9
The problem doesn't occur when compiling with 3.8.* or 3.9.0-beta, but all other versions of 3.9, 4.0 and 4.1 reproduce the issue.

Search Terms: duplicate identifier

Code

a.js

/** @type {import('./types').Config} */
const data = JSON.parse('');
data.uploads = {};


module.exports = data;

types.d.ts

export interface Config {
    uploads: {
    }
}

tsconfig.json

{
    "compilerOptions": {
        "noEmit": true,
        "allowJs": true,
        "checkJs": true
    },
    "include": [ "*.js", "*.ts" ]
}

Run tsc

Expected behavior: Code compiles without errors

Actual behavior:

a.js:3:1 - error TS2300: Duplicate identifier 'uploads'.

 data.uploads = {};
  ~~~~~~~~~~~~

  types.d.ts:2:5
         uploads: {
          ~~~~~~~
    'uploads' was also declared here.


Found 1 error.

Workarounds:
Specifying type of module.exports like the following:
a.js

/** @type {import('./types').Config} */
const data = JSON.parse('');
data.uploads = {};

/** @type {import('./types').Config} */
module.exports = data;

Exporting data differently:
module.exports = { data };

Changing the file extension of a.js to ts (however, this not an option for us, we are only using tsc for type checking)

[kazarmy]

I've encountered the same problem in different code:

TypeScript Version: 4.2.0-dev.20201126

/**
 * @type {import('eslint').Linter.Config<import('eslint/rules').ESLintRules>}
 */
const config = {
  rules: {
    'strict': 2,
  },
};
// ...
config.rules.strict = /** @type {typeof config.rules.strict} */ ([2, 'global']);
/** @type {typeof config} */
module.exports = config;

(Code from #41593 with a workaround from there and the addition of the last 2 lines)

What I've found is that instead of using /** @type {typeof config} */, I could use /** @type {any} */ or /** @type {never} */ and the type checking would still work, meaning:

1. The inferred type for module.exports is correct.
2. Type propagation still happens across module boundaries.

The additional comment isn't much, but it appears to be totally undocumented, so I'm worried that this workaround will no longer work in future TypeScript versions.