Missing CommonJS import Intellisense after changing file extension from .js to .ts

[kamil-pogorzelski-allegro]

🔎 Search Terms

CommonJS import, require Intellisense, migrating from js to ts

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about require calls in ts files

⏯ Playground Link

https://github.com/kamil-pogorzelski-allegro/missing-intellisense-common-js

💻 Code

// a.js file
module.exports.exportedValue = 'something';

// b.js file
const { exportedValue } = require('./a');
//          ^ type: 'something'    ^ can follow this path to a.js file

//b.js renamed to b.ts
const { exportedValue } = require('./a');
//          ^ type: any            ^ cannot follow this path to a.js file

// tsconfig.json
{
  "compilerOptions": {
    "allowJs": true,
    "types": ["node"],
    "noEmit": true,
  }
}

🙁 Actual behavior

After renaming b.js to b.ts all type information about imported value vanishes, also path passed to require is no longer treated as an filepath

🙂 Expected behavior

No changes in type information / Intellisense for imported value.

Additional information about the issue

I'm maintaining CommonJS package with Node scripts written in pure JS. I've been trying to improve type safety and ergonomics on top of allowJs option by migrating to Typescript and run the scripts with tsx. I was surprised that changing file extension to ts actually reduces the type information as const ... = require(...) imports stop being treated as imports.

I'd like to avoid having to change the import syntax - since type information is available in js files then why it's not available in ts files. On top of that I'd want to avoid struggling with transpilation of import syntax and keep TS as strictly type linter.

I've checked if this is editor or TS issue by adding "typescript.tsserver.log": "verbose" option in VSCode settings and turns out that server returns empty suggestions list when invoking autocomplete action in editor.

[RyanCavanaugh]

TypeScript files only recognize import id = require("./a"); and unfortunately can't use destructuring in that form. Only JS inference presupposes that require means the CJS require function.

[fatcerberus]

Only JS inference presupposes that require means the CJS require function.

Huh, TIL; for some reason I always thought bare require worked. So does TS still require you to write import foo = require(...) under verbatimModuleSyntax for CommonJS targets?

[kamil-pogorzelski-allegro]

@RyanCavanaugh Could you explain why is that? Couldn't inference check if e.g. type: "commonjs" is set in package.json or certain module and moduleResolution options for node are present? Or any other mechanism that would mirror how node decides whether module is CommonJS or ESM one?

[typescript-bot]

This issue has been marked as "Working as Intended" and has seen no recent activity. It has been automatically closed for house-keeping purposes.