Build with "–mode production" hangs on Windows Subsystem for Linux (WSL)

Version

3.3.0

Environment info

System:
  OS: Linux 4.4 Ubuntu 18.04.1 LTS (Bionic Beaver)
  CPU: (4) x64 Intel(R) Xeon(R) CPU E3-1240 v5 @ 3.50GHz
Binaries:
  Node: 10.15.0 - ~/.nvm/versions/node/v10.15.0/bin/node
  Yarn: Not Found
  npm: 6.4.1 - ~/.nvm/versions/node/v10.15.0/bin/npm
Browsers:
  Chrome: Not Found
  Firefox: Not Found
npmPackages:
  vue:  2.5.22
npmGlobalPackages:
  @vue/cli: 3.3.0

IMPORTANT NOTE: Ubuntu 18.04 runs on WSL (Windows 10 Education, 1809)

Steps to reproduce

vue-cli-service build

What is expected?

“vue-cli-service build” will terminate. Either with a successful build or some sort of error.

What is actually happening?

On some WSL installations, the Vue CLI 3 build in production mode hangs and never terminates (message “Building for production…”).

I observed this behavior with a mid-sized Vue project (~ 150 .vue files) on a 4 and 14 core machine. Strangely the project was building just fine on a machine with 8 cores. (Same Windows, WSL, Ubuntu, Node and Vue (CLI) version)

Because “serve” and “build --mode development” were working on all machines, I finally stumbled upon the following discussion in the forum:

https://forum.vuejs.org/t/vue-cli-3-pages-npn-run-build-gets-stuck/41566/3

And yes, deleting the “named-chunks” plugin was also working in my situation:

webpackChainconfig.plugins.delete('named-chunks');

---

The whole investigation brought up some questions:

• I couldn’t find much information for debugging webpack via Vue CLI. Why is there no easy way of passing --verbose to webpack?
• When building with “named-chunks”-plugin, multiple node processes get spawned. This happens even when “parallel” (https://cli.vuejs.org/config/#parallel) is set to false. Shouldn’t also the “named-chunks”-plugin, respectively all modules used by Vue CLI, respect the parallel-option?
• Are there any known shortcomings when using webpack in WSL? Would you advise against such a build environment on Windows?

Unfortunately, I cannot share the code of the project. But I have an affected system/project ready for further investigation.

[boardend]

@sodatea thanks for https://github.com/vuejs/vue-cli/commit/702a2c9fd0131f336b0eb5d5ff0af78bd83e1220 👍

This allows me to turn off the parallel option in vue.config.js on WSL setups and get a workaround without any impacts on the build result itself. (I’m not so worried about the performance, because I still have the option to build multiple modules in parallel with Rush)

Maybe it’s a good idea to turn off Vue CLI’s parallel option as a default for WSL setups?

process.platform === 'linux' && os.release().includes('Microsoft')

Or we just wait what happens with https://github.com/webpack-contrib/terser-webpack-plugin/issues/21 So feel free to close this issue.

[boardend]

Looks like I’ve ran into same problem as https://github.com/webpack-contrib/terser-webpack-plugin/issues/21.

Maybe the root cause is WSL itself, see https://github.com/Microsoft/WSL/issues/2613:

• Yes, I’m using a Windows drive (/mnt/c/…)
• And yes, I’m using Symlinks with pnpm for the linking of dependencies inside the monorepo…

Besides removing the “named-chunks”-plugin in my vue.config.js, patching /cli-service/lib/config/terserOptions.js#L40 with parallel: false is also a feasible workaround.