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

[boardend]

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.

[haoqunjiang]

Please try to upgrade @vue/cli-services version in your project.

The bug you referred to was fixed long ago in v3.0.2 #2324 and was caused by a hash collision, rather than multi-core problem. Also, the implementation of named-chunks has nothing to do with multithreading / multiprocess.

vue-cli/packages/@vue/cli-service/lib/config/app.js

Lines 122 to 132 in a2d356e

	webpackConfig
	.plugin('named-chunks')
	.use(require('webpack/lib/NamedChunksPlugin'), [chunk => {
	if (chunk.name) {
	return chunk.name
	}
	return `chunk-` + Array.from(chunk.modulesIterable, m => {
	return m.id
	}).join('_')
	}])
	}

https://github.com/webpack/webpack/blob/master/lib/NamedChunksPlugin.js

Without a runnable runnable reproduction, that's all I can tell.

[boardend]

@sodatea I'm using the latest @vue/cli-service version from NPM (3.3.0).

IMHO just the same workaround can be applied. If the root cause would be a hash collision too, then it wouldn’t make sense that it works on one machine, but fails on two others.

I've tried to reproduce the issue on an affected system with a newly created Vue CLI Project. Without success, unfortunately.

I don't know why or where the build gets stuck, but I can reproduce the issue on two of my machines. Maybe you can help me to get more information where exactly webpack gets stuck?

[haoqunjiang]

Considering "the build gets stuck", it might be related to this bug in friendly-errors-webpack-plugin, which is also related to async chunks.

friendly-errors-webpack-plugin has already fixed that problem but not yet released to npm. You can install it from GitHub by adding following field to package.json and rerun yarn install:

"resolutions": {
    "friendly-errors-webpack-plugin": "git+https://github.com/geowarin/friendly-errors-webpack-plugin.git"
  }

You might be abe to see the actual error log when running yarn build after applying the patch above.

[boardend]

Just checked the 3 systems: All have the same (and latest) version 1.7.0 of the friendly-errors-webpack-plugin installed. So I don’t think this bug cases the situation on 2 of 3 systems. But yes, the project uses the default @ alias from Vue CLI and some custom # aliases.

Maybe I should explain ”build gets stuck” a little further: At some point, the build gets in some sort of a lock-situation. No work will be done anymore (no CPU Load nor changing Memory Usage) and no timeout will occur. At this point multiple node and sass processes are hanging (as seen in the Windows Task Manager and lsof inside the Ubuntu WSL Installation). It seems that playing around with UV_THREADPOOL_SIZE and v8_thread_pool_size changes the amount of processes that are involved. But neither a big, small nor a zero pool size at all will prevent the lock situation.

I really need to get more information from webpack in order to tell which plugins/loaders are involved in such a situation. Node-Debugging didn’t let me pause in such a situation, because I only was able to attach the debugger to the outermost node process which won’t pause while waiting on the “child-processes”.

[haoqunjiang]

To use the webpack config file directly, see https://cli.vuejs.org/guide/webpack.html#using-resolved-config-as-a-file

[boardend]

Looks like I've ran into same problem as webpack-contrib/terser-webpack-plugin#21.

Maybe the root cause is WSL itself, see microsoft/WSL#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.

[boardend]

@sodatea thanks for 702a2c9 👍

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 webpack-contrib/terser-webpack-plugin#21 So feel free to close this issue.

[purocean]

I have the same problem and I set parallel with false, no named-chunks plugin, still hang. any additional configuration? @boardend

[purocean]

And it not hang forever. Build will be completed about 5~10 mins on my machine. In the Linux CI server. only need 30s. @boardend

[boardend]

@purocean I'm not sure if we encountered the same issue. On WSL the build really hangs and will never terminate (tested this overnight).

For setting parallel to false, you need the latest dev-branch of this repository. Otherwise webpackChainconfig.plugins.delete('named-chunks'); should do the trick (but will affect your build result)

[vue-bot]

Hello!
This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues requiring feedback after 20 days of inactivity. It’s been at least 10 days since the last update here. If we missed this issue or if you want to keep it open, please reply here. (A maintainer can also add the label not stale to keep this issue open.)

Thanks for being a part of the Vue community! 💪💚️

[vue-bot]

Hey again! 😸️

It’s been 20 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it.
Please keep in mind that I’m only a robot, so if I’ve closed this issue in error, I’m HUMAN_EMOTION_SORRY. 🤖 Please feel free to reopen this issue or create a new one if you need anything else.

Thanks again for being part of the Vue community! 💚️