Compilation fails with Webpack 4.2.0 when using au run through the CLI.

[weegeekps]

I'm submitting a bug report

• Library Version:
  0.33.1

Please tell us about your environment:

• Operating System:
  OSX 10.13

• Node Version:
  8.10.0

• NPM Version:
  5.6.0

• Browser:
  all

• Language:
  all

• Loader/bundler:
  Webpack

Current behavior:
When running au run with Webpack 4.2.0 in a brand new project, an error occurs which prevents the application from compiling successfully:

✖ ｢wdm｣: ConcurrentCompilationError: You ran Webpack twice. Each instance only supports a single concurrent compilation at a time.
    at Compiler.run (/Users/u0117404/Projects/test-webpack-broke/node_modules/webpack/lib/Compiler.js:147:37)
    at rebuild (/Users/u0117404/Projects/test-webpack-broke/node_modules/webpack-dev-middleware/lib/context.js:81:24)
    at done (/Users/u0117404/Projects/test-webpack-broke/node_modules/webpack-dev-middleware/lib/context.js:59:7)
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/Users/u0117404/Projects/test-webpack-broke/node_modules/tapable/lib/HookCodeFactory.js:24:12), <anonymous>:18:1)
    at AsyncSeriesHook.lazyCompileHook [as _callAsync] (/Users/u0117404/Projects/test-webpack-broke/node_modules/tapable/lib/Hook.js:35:21)
    at emitRecords.err (/Users/u0117404/Projects/test-webpack-broke/node_modules/webpack/lib/Compiler.js:199:22)
    at Compiler.emitRecords (/Users/u0117404/Projects/test-webpack-broke/node_modules/webpack/lib/Compiler.js:311:39)
    at emitAssets.err (/Users/u0117404/Projects/test-webpack-broke/node_modules/webpack/lib/Compiler.js:193:10)
    at hooks.afterEmit.callAsync.err (/Users/u0117404/Projects/test-webpack-broke/node_modules/webpack/lib/Compiler.js:297:14)
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/Users/u0117404/Projects/test-webpack-broke/node_modules/tapable/lib/HookCodeFactory.js:24:12), <anonymous>:15:1)
    at AsyncSeriesHook.lazyCompileHook [as _callAsync] (/Users/u0117404/Projects/test-webpack-broke/node_modules/tapable/lib/Hook.js:35:21)
    at asyncLib.forEach.err (/Users/u0117404/Projects/test-webpack-broke/node_modules/webpack/lib/Compiler.js:294:27)
    at done (/Users/u0117404/Projects/test-webpack-broke/node_modules/neo-async/async.js:2809:11)
    at /Users/u0117404/Projects/test-webpack-broke/node_modules/neo-async/async.js:2760:7
    at MemoryFileSystem.writeFile (/Users/u0117404/Projects/test-webpack-broke/node_modules/memory-fs/lib/MemoryFileSystem.js:328:9)
    at writeOut (/Users/u0117404/Projects/test-webpack-broke/node_modules/webpack/lib/Compiler.js:280:29)

This behavior does not occur if you run the project using nps or if you roll the Webpack version back to 4.1.1.

This appears to be somewhat related to this Pull Request in Webpack 8 days ago: webpack/webpack#6691

Reproduction is fairly easy:

1. Create a fresh project using au new.
2. Install all dependencies using either npm or yarn. (I tested both.)
3. Run au run and try to navigate to the page in any browser.

The error will occur.

• What is the expected behavior?

With a fresh CLI project we should see "Hello world!" when hitting the application for the first time.

[Alexander-Taran]

I can reproduce this
au new -> default typescript
au run

@weegeekps thank you for an informative report.
you did great job there.

[Alexander-Taran]

Ok
1st thing - au run --watch works fine
2nd it looks like without --watch webpack dev server waits for page to be actually navigated to before kicking in with compilation
and then barfs..

and the --watch option only adds .lazy = true; to options

[fkleuver]

(correction)
The absence of --watch enables lazy mode for webpack-dev-server. Rather than compiling on each change (including when first run), it compiles only when the entry point is loaded (e.g. page load). Even without --watch, however, if you change something and reload the page, you'll have the changed version.

When in lazy mode (in other words, run without --watch), some process that is meant to invoke the compiler is probably already running but it doesn't invoke the compiler directly. The page load then calls the dev server which likely starts that same process. There is meant to be some logic in webpack to prevent two compilers from starting at the same time, and it seems that logic is broken in 4.2.0.

I don't think there is a whole lot that can be done from aurelia-cli perspective apart from maybe excluding 4.2.0 in the dependency specification.

Other than that, I would suggest simply having the --watch flag on as it doesn't make as much a difference for webpack as it does for aurelia-cli. It's super fast anyway.

[Alexander-Taran]

@fkleuver thanks for all your help with investigation

[Alexander-Taran]

Yep. Current workaround is to au run --watch

It is not a CLI issue.
Runing webpack-dev-server with --lazy breaks the same way.

Issue was filed for webpack team

[CasiOo]

@Alexander-Taran would you mind linking the issue opened in the Webpack repository? :)

[Alexander-Taran]

[CasiOo]

People are still running into this issue when creating new projects.
Maybe we should stop them from installing webpack 4.2.x until they fix the issue (or we do) ?

https://github.com/aurelia/cli/blob/master/lib/dependencies.json#L105
Change it to something like ~4 for the time being ?

[4imble]

I experienced this error also, but notice when using --watch it will reload on changes but will not rebuild. This means any changes you made will not show. Also if you create a brand new project and then immediately do au run --watch it will fail due to the dist folder being empty.

Update
This is due to me having my working directory with a space in it. I'll open a new issue.

[reefath]

I'm using 4.6.0 version of webpack and still face the same problem. I do not use au though. Can you please help debug how to fix this issue? Also I noticed that its happening with chrome.

[fkleuver]

@reefath If you're not using au, then what are you using? I believe this issue is specific to the au run command

[geomorillo]

when is this gonna be fixed?

[fkleuver]

@geomorillo Considering there is a very easy workaround (simply use au run --watch instead of au run), I don't think this is very high on the priority list atm.

[JeroenVinke]

After consideration we don't see any use cases for au run without a watch mode. So I've made --watch the default for the run command (26cce92).