🐛 Bug: original require() errors are masked with an unrelated `ERR_UNKNOWN_FILE_EXTENSION`

[lkho]

Bug Report Checklist

• I have read and agree to Mocha's Code of Conduct and Contributing Guidelines
• I have searched for related issues and issues with the faq label, but none matched my issue.
• I have 'smoke tested' the code to be tested by running it outside the real test suite to get a better sense of whether the problem is in the code under test, my usage of Mocha, or Mocha itself.
• I want to provide a PR to resolve this (but after community discussion first)

Expected

in 11.7.0, if require() fails, the error is thrown and output to console. e.g.:

 $ mocha --require ts-node/register --require source-map-support/register 'a.ts'
 
  Exception during run: .../a.ts:61:66 - error TS2345: Argument of type '{ address: string; }' is not assignable to parameter of type ...
 
 $ mocha --version
 11.7.0

Actual

after this change #5384 (comment)
the err is masked and returned an ERR_UNKNOWN_FILE_EXTENSION which is misleading.

 $ mocha --require ts-node/register --require source-map-support/register 'a.ts'
 
  Exception during run: TypeError: Unknown file extension ".ts" for /.../a.ts
     at Object.getFileProtocolModuleFormat [as file:] (node:internal/modules/esm/get_format:219:9)
     at defaultGetFormat (node:internal/modules/esm/get_format:245:36)
     at defaultLoad (node:internal/modules/esm/load:120:22)
     at async ModuleLoader.loadAndTranslate (node:internal/modules/esm/loader:580:32)
     at async ModuleJob._link (node:internal/modules/esm/module_job:116:19) {
   code: 'ERR_UNKNOWN_FILE_EXTENSION'
 }
 
 $ mocha --version
 11.7.1

Minimal, Reproducible Example

1. install ts-node and require it along with the mocha command i.e. mocha --require ts-node/register abc.ts
2. try to run with a giblish ts file. e.g.

bla@#&#_@$

what ever contents in it causing a ts not compilable will output the same ERR_UNKNOWN_FILE_EXTENSION error

Versions

11.7.1 not work
11.7.0 works

Additional Info

I think this is open to discussion whether this should be classified as bug or not, but I just want to point out the breaking behavioral change in this patch version release which might potentially affect people who rely on the error output for debugging purpose or experiencing surprises suddenly.

[JoshuaKGoldberg]

Ah, fun, this is something of a duplicate-ish of #5235. The fact that you're filing this only a few months after that was closed as "not many people are asking for this" might mean we should reconsider the 'wontfix' label.

Minimal, Reproducible Example

Could you please post a full reproducible project or playground? In particular it'd be good to see your exact package lockfile and Node.js version, since we saw in #5235 that Mocha's behavior changes across Node.js versions.

[lkho]

https://codesandbox.io/p/devbox/adoring-butterfly-ypftzk
tried in node 20, 22

[JoshuaKGoldberg]

👍 thanks! Confirmed that this is a bug. Marking as accepting PRs for specifically improving one reported error message.

I'm not clear on what the right heuristic would be for knowing to report the import() vs. require() message. Maybe a good starting change would be to only switch to the original error if the new one is ERR_UNKNOWN_FILE_EXTENSION? A file extension complaint might be a reliable enough indication that the user's config intends to load through an older method.

[sean-at-heady]

Just adding some more information here.

I was having an issue with sinonJS failing because i was creating a stub on an already stubbed line of code in my global.ts file.

Mocha/ts-mocha was reporting this as Exception during run: TypeError: Unknown file extension ".ts" for global.ts

I was able to track it down by debugging the node_modules/mocha/lib/nodejs/esm-utils.js file

const formattedImport = async (file, esmDecorator = forward) => {
  if (path.isAbsolute(file)) {
    try {
      return await exports.doImport(esmDecorator(url.pathToFileURL(file)));
    } catch (err) {
      // This is a hack created because ESM in Node.js (at least in Node v15.5.1) does not emit
      // the location of the syntax error in the error thrown.
      // This is problematic because the user can't see what file has the problem,
      // so we add the file location to the error.
      // TODO: remove once Node.js fixes the problem.
      if (
        err instanceof SyntaxError &&
        err.message &&
        err.stack &&
        !err.stack.includes(file)
      ) {
        const newErrorWithFilename = new SyntaxError(err.message);
        newErrorWithFilename.stack = err.stack.replace(
          /^SyntaxError/,
          `SyntaxError[ @${file} ]`
        );
        throw newErrorWithFilename;
      }
      throw err;
    }
  }
  return exports.doImport(esmDecorator(file));
};

Perhaps a simple solution would be to just join all the errors that occur here. Not sure at which point the orignal errors are getting swallowed/ignored.

Just leaving this here for googlers going crazy trying to fix unrelated Exception during run: TypeError: Unknown file extension ".ts" for... errros

[lkho]

Mocha/ts-mocha was reporting this as Exception during run: TypeError: Unknown file extension ".ts" for global.ts

Perhaps a simple solution would be to just join all the errors that occur here. Not sure at which point the orignal errors are getting swallowed/ignored.

Just leaving this here for googlers going crazy trying to fix unrelated Exception during run: TypeError: Unknown file extension ".ts" for... errros

yes you have exactly hit the situation like me whenever your test files are not compilable for whatever reasons.

i think the original error is somewhere inside the next recursive call (as you see should be the line exports.doImport(...) which again triggers another loop into one of the exports.requireOrImport implementations.