Move to a new file doesn't add extension with "module": "nodeNext" leading to a broken import

[Jamesernator]

Bug Report

🔎 Search Terms

move to new file extension nodenext

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about extensions

⏯ Playground Link

N/A Only applies to multi-file refactoring

💻 Code

// Refactor this function to a new file
function someLibFn(): string {
    return someOtherFn();
}

function someOtherFn(): string {
    return "hello world!";
}

console.log(someLibFn());

🙁 Actual behavior

The import generated is missing the .js extension.

i.e. This is generated:

import { someLibFn } from "./someLibFn";

Similarly in the other file the reverse import is also missing it's extension:

import { someOtherFn } from "./example";

This broken refactor produces a predictable TS error:

Relative import paths need explicit file extensions in EcmaScript imports when '--moduleResolution' is 'node16' or 'nodenext'. Did you mean './someLibFn.js'?ts(2835)

See also as video:

Screencast.from.11-09-22.00.10.49.webm

🙂 Expected behavior

It should generate with the .js extension as (and ditto for the other file):

import { someLibFn } from "./someLibFn.js";

Notes

This is almost certainly related to #46290 . However this doesn't really have anything to do with the vscode specific option importModuleSpecifierEnding, so I made a separate issue.

tsconfig.json

In case this issue is caused by a combination of settings here is the full tsconfig.json:

{
    "include": [
        "./**/*.ts",
        "./**/*.mts",
        "./**/*.cts"
    ],
    "exclude": [
        "./**/*.d.ts",
        "./**/*.d.mts",
        "./**/*.d.cts"
    ],
    "compilerOptions": {
        "composite": true,
        "declaration": true,
        "declarationMap": true,
        "downlevelIteration": true,
        "isolatedModules": true,
        "module": "NodeNext",
        "rootDir": "./",
        "sourceMap": true,
        "target": "esnext",
        "newLine": "lf",
        "useDefineForClassFields": true,
        "strict": true,
        "alwaysStrict": true,
        "exactOptionalPropertyTypes": true,
        "noImplicitOverride": true,
        "noUncheckedIndexedAccess": true,
        "importsNotUsedAsValues": "error",
        "forceConsistentCasingInFileNames": true
    }
}

[a-tarasyuk]

Just curious, we have a TypeScript file/code and we want to move it to a new file (JavaScript file? 😕 ) and import that code from the JavaScript file - am I right?

/cc @andrewbranch

[andrewbranch]

It looks like both files are TypeScript from the screencast, but I don’t think it really matters.

[egasimus]

The entire concept that one should import ./foo.js instead of ./foo when actually meaning ./foo.ts - especially in a mode that specifically targets Node 16+'s new ESM handling - is so ass-backwards that it's backwards-ass. So no surprise that it comes back to bite yall in the ass with issues like these. Believe me, you haven't seen half of it.

Expected behavior: when moduleResolution is node16 or nodenext, TSC should automatically transpile import './foo' to import './foo.js' to abstract away Node's new weirdness, warn if this would cause any odd name collisions, and that should be that. Who says I'm even outputting JS files anyway?

Anything else is just an experiment in how much shit will webdevs eat and, guess what, I ain't having any. Already staying off the frontend because of the shitshow that is ubiquitous React, already doubling down on the WASM so once Microsoft is done capturing the EcmaScript ecosystem we'll have somewhere way comfier to retreat to, already wrote my own shit-shovel too (~350 LOC of custom AST parsing in plain old CommonJS), and now I'm here to fling all that right back at yall. A reality check is good from time to time.