mochajs / mocha

β˜•οΈ simple, flexible, fun javascript test framework for node.js & the browser
https://mochajs.org
MIT License
22.61k stars 3.02k forks source link

πŸ› Bug: Mocha not print any output when failed loading #4948

Open SettingDust opened 2 years ago

SettingDust commented 2 years ago

Prerequisites

Description

I'm not quite sure if this should be a feature request or bug report

Mocha not print anything with my project without DEBUG=*. The logs in debug mode isn't helpful for find out where is the problem It's exit immediately after Mocha#loadFilesAsync emit the first test file.

It's seems there is some problem with my source files. Mocha will pass a test file when it's empty. But it's not important. I think mocha need log something helpful.

So below is just for people interested. Not relating to this issue. I'm using mocha on a typescript + ts-node + swc. It's fine at a commit. But output nothing at another commit. It's weird caused by move the test files.

Edit: I've tried to add two lines before https://github.com/mochajs/mocha/blob/master/lib/nodejs/esm-utils.js#L7. But the second one isn't print anything. I think it is the problem. But there isn't anything being catched. I don't know how to debug the import behavior. But it's seems something in deeper instead of mocha :(

console.log(url.pathToFileURL(file))
console.log(await import(url.pathToFileURL(file)))
return await import(url.pathToFileURL(file)) // L7

Edit: After test. The exit happened after I move the types from utils.ts to default-extractors.ts. And fixed after move the types from default-extractors.ts to another file

Steps to Reproduce

Clone project: https://github.com/SettingDust/article-extractor/commit/62ec19f72cde4df533ede66512e03efcc3d9f368 Run tests

Expected behavior: Log something when Mocha#loadFilesAsync failed to load a test file. Such as the file name.

Actual behavior: Nothing print

Debug log: https://pastes.dev/Bt5vI875iS

Reproduces how often: 1/1

Versions

JoshuaKGoldberg commented 10 months ago

Since the paste expired, here's what I get from DEBUG=*:

josh ~/repos/article-extractor $ DEBUG=* yarn test
  mocha:cli:config findConfig: found config file /Users/josh/repos/article-extractor/.mocharc.json +0ms
  mocha:cli:config loadConfig: trying to parse config at /Users/josh/repos/article-extractor/.mocharc.json +1ms
  mocha:cli:options no config found in /Users/josh/repos/article-extractor/package.json +0ms
  mocha:cli:mocha loaded opts {
  _: [ 'src/**/*.spec.ts' ],
  config: false,
  package: false,
  extension: [ 'ts' ],
  'node-option': [ 'experimental-specifier-resolution=node', 'loader=ts-node/esm' ],
  diff: true,
  reporter: 'spec',
  slow: 75,
  timeout: 2000,
  ui: 'bdd',
  'watch-ignore': [ 'node_modules', '.git' ]
} +0ms
  mocha:cli:mocha final node argv [ '--experimental-specifier-resolution=node', '--loader=ts-node/esm' ] +1ms
  mocha:cli:mocha forking child process via command: /Users/josh/.nvm/versions/node/v21.5.0/bin/node --experimental-specifier-resolution=node --loader=ts-node/esm /Users/josh/repos/article-extractor/node_modules/mocha/lib/cli/cli.js src/**/*.spec.ts --no-config --no-package --extension ts --diff --reporter spec --slow 75 --timeout 2000 --ui bdd --watch-ignore node_modules --watch-ignore .git +0ms
(node:1249) ExperimentalWarning: `--experimental-loader` may be removed in the future; instead use `register()`:
--import 'data:text/javascript,import { register } from "node:module"; import { pathToFileURL } from "node:url"; register("ts-node/esm", pathToFileURL("./"));'
(Use `node --trace-warnings ...` to show where the warning was created)
  mocha:cli:cli entered main with raw args [
  'src/**/*.spec.ts', '--no-config',
  '--no-package',     '--extension',
  'ts',               '--diff',
  '--reporter',       'spec',
  '--slow',           '75',
  '--timeout',        '2000',
  '--ui',             'bdd',
  '--watch-ignore',   'node_modules',
  '--watch-ignore',   '.git'
] +0ms
  mocha:plugin-loader registered plugin def "mochaHooks" +0ms
  mocha:plugin-loader registered plugin def "mochaGlobalSetup" +0ms
  mocha:plugin-loader registered plugin def "mochaGlobalTeardown" +0ms
  mocha:plugin-loader registered 3 plugin defs (0 ignored) +0ms
  mocha:plugin-loader finalized plugins: [Object: null prototype] {} +7ms
  mocha:cli:run post-yargs config {
  package: [Getter/Setter],
  _: [],
  config: false,
  extension: [ 'ts' ],
  diff: true,
  reporter: 'spec',
  slow: '75',
  timeout: '2000',
  ui: 'bdd',
  'watch-ignore': [ 'node_modules', '.git' ],
  watchIgnore: [ 'node_modules', '.git' ],
  spec: [ 'src/**/*.spec.ts' ],
  '$0': 'mocha'
} +0ms
  mocha:suite slow 75 +0ms
  mocha:suite timeout 2000 +0ms
  mocha:mocha configured 0 global setup functions +0ms
  mocha:mocha configured 0 global teardown functions +0ms
  mocha:cli:run:helpers test files (in order):  [
  '/Users/josh/repos/article-extractor/src/author-extractor.spec.ts',
  '/Users/josh/repos/article-extractor/src/author-url-extractor.spec.ts',
  '/Users/josh/repos/article-extractor/src/index.spec.ts',
  '/Users/josh/repos/article-extractor/src/modified-date-extractor.spec.ts',
  '/Users/josh/repos/article-extractor/src/published-date-extractor.spec.ts',
  '/Users/josh/repos/article-extractor/src/title-extractor.spec.ts',
  '/Users/josh/repos/article-extractor/src/url-extractor.spec.ts',
  '/Users/josh/repos/article-extractor/src/utils/jsonld.spec.ts',
  '/Users/josh/repos/article-extractor/src/utils/parse-date.spec.ts',
  '/Users/josh/repos/article-extractor/src/utils/parse-html.spec.ts'
] +0ms
  mocha:cli:run:helpers single run with 10 file(s) +0ms
  mocha:mocha set lazy load to true +10ms
josh ~/repos/article-extractor $ 

Note that in order to yarn I needed to remove the @yarnpkg/plugin-interactive-tools entry from .yarnrc.yml.

I poked around a bit internally and it looks like there's an error thrown in esm-utils.js > formattedImport. Locally for me the path it's trying import looks like '/Users/josh/repos/article-extractor/src/author-extractor.spec.ts'.

Seems that this is a bug in Mocha's error reporting. Whatever ESM-related misconfiguration might be present, at least an error should be presented to the user. Accepting PRs to fix the error reporting.