Karma unit test failures: Cant resolve fs, no tests run

[rockResolve]

I'm submitting a bug report

• Library Version:
  au cli 1.0.0-beta.7

Please tell us about your environment:

• Operating System:
  Windows 10

• Node Version:
  10.13.0

• NPM Version:
  6.4.1

• Browser:
  Chrome 70

• Language:
  TypeScript 3.2.1

• Loader/bundler:
  Webpack

Current behavior:
To reproduce:
au new
choose Default Typescript setup
run au karma

I get the following error
ERROR in .../Default TypeScript/node_modules/jest-message-util/build/index.js
Module not found: Error: Can't resolve 'fs' in '...\Default TypeScript\node_modules\jest-message-util\build'
@ .../Default TypeScript/node_modules/jest-message-util/build/index.js 8:10-23
@ .../Default TypeScript/node_modules/jest-matchers/build-es5/toThrowMatchers.js
@ .../Default TypeScript/node_modules/jest-matchers/build-es5/index.js
@ .../Default TypeScript/test/karma-bundle.js

ERROR in .../Default TypeScript/node_modules/snapdragon/lib/source-maps.js
Module not found: Error: Can't resolve 'fs' in '...\Default TypeScript\node_modules\snapdragon\lib'
@ .../Default TypeScript/node_modules/snapdragon/lib/source-maps.js 3:9-22
@ .../Default TypeScript/node_modules/snapdragon/lib/compiler.js
@ .../Default TypeScript/node_modules/snapdragon/index.js
@ .../Default TypeScript/node_modules/micromatch/lib/utils.js
@ .../Default TypeScript/node_modules/micromatch/index.js
@ .../Default TypeScript/node_modules/jest-message-util/build/index.js
@ .../Default TypeScript/node_modules/jest-matchers/build-es5/toThrowMatchers.js
@ .../Default TypeScript/node_modules/jest-matchers/build-es5/index.js
@ .../Default TypeScript/test/karma-bundle.js

In addition no tests are actually run. The output has
SUMMARY:
√ 0 tests completed

• What is the expected behavior?
  karma tests should run without errors

[3cp]

Could be #970.
Can you try reverting to modules: [srcDir, 'node_modules'], in webpack config?

[rockResolve]

Reverting #970 fixed the error, but still 0 tests completed

[rockResolve]

I also found a fix that was explicitly installing fs.
Again while it fixed the error, still 0 tests were completed.
webpack-contrib/css-loader#447

[3cp]

@chrisckc could you have a look?

[chrisckc]

Had a quick look at the 2 issues:

First issue:

The error "Module not found: Error: Can't resolve 'fs' in" can be fixed by adding the following to the webpack config: node: { fs: 'empty' }, as mentioned in the referenced issue, rather than reverting to modules: [srcDir, 'node_modules'],

Second issue with the tests not running:
comment out the optimization config section in the webpack config to fix the issue, this is because optimisation cannot be used with the 'karma-webpack' plugin so would need to be disabled when running tests. Thankfully we don't have to figure out how to do that, see below.

codymikol/karma-webpack#325

It would seem that the SplitChunksPlugin, well actually Webpack v4 itself is incompatible with the version of karma-webpack (v3.0.5) used in the CLI generated package.json.

To resolve the issue use karma-webpack v4.0.0-RC.3

npm install [email protected]

That version automatically disables optimisation in webpack config by setting it to false.

[davismj]

This error is thrown on Node 8 and Node 10, but not Node 6.

{ fs: 'empty' } and [email protected] got the tests running, but it still throws an error after running the tests, (during coverage report?):

Error: Path contains invalid characters

[peitschie]

@davismj I just hit that as well. The workaround for me was to add a context in my webpack.config.js file, as karma-coverage-istanbul-reporter uses this to de-absolute the paths covered.

The top fragment of my webpack.config.js now looks like:

module.exports = ({ production, server, extractCss, coverage, analyze, karma } = {}) => ({
  context: karma ? __dirname : undefined,
  ...
}

[3cp]

Should we only use jest in the default webpack setup? So at least users can get a working skeleton.

[3cp]

@peitschie that sounds like it should be fixed in karma-coverage-istanbul-reporter.

I read from webpack doc, when context is undefined, "By default the current directory is used".

But karma-coverage-istanbul-reporter tries to read webpackConfig.context directly.
https://github.com/mattlewis92/karma-coverage-istanbul-reporter/blob/50f441f496622b8f923388182d2d9acaad596138/src/util.js#L31

It should be reading const webpackContext = webpackConfig.context || process.cwd(); if my understanding is correct.

[3cp]

@peitschie I am not sure what did I do wrongly. I have a default webpack skeleton. The context: karma ? __dirname : undefined, didn't fix the missing fs issue for me.

[peitschie]

@huochunpeng sorry, I wasn't clear with my comment.

The fs issue requires the tweak specified in #996 (comment). My additional config change fixes the next issue @davismj encountered where the coverage was throwing an Path contains invalid characters error.

The tweaks to my webpack to get this working again were:

module.exports = ({ production, server, extractCss, coverage, analyze, karma } = {}) => ({
  context: karma ? __dirname : undefined,
  node: {
    fs: 'empty'
  },
  optimization: {
    splitChunks: karma ? false : { ... /* existing config */ }
  }
  ...
}

[peitschie]

Another tweak is also required for karma.config.js on Windows, to avoid the html reporter breaking (I added a fix to mattlewis92/karma-coverage-istanbul-reporter#61 for this as well):

module.exports = function (config) {
  config.set({
    ...
    coverageIstanbulReporter: {
      ...
      skipFilesWithNoCoverage: true
    },
  })
}

[3cp]

#970 has been reverted, karma looks fine now.

Reverting #970 fixed the error, but still 0 tests completed

@rockResolve I cannot reproduce your 0 tests issue after reverting #970.

[rockResolve]

No longer using karma, moved to jest

[3cp]

@EisenbergEffect let's close this issue for now.