Crashed when using Webpack `import()`

[fxxjdedd]

Version

3.0.1

Reproduction link

https://github.com/fxxjdedd/vue-cli3-import-test.git

Node and OS info

Node 10.3.0, yarn 1.9.4, Windows10

Steps to reproduce

yarn install && yarn serve

What is expected?

running

What is actually happening?

crashed with error:

 RangeError: Maximum call stack size exceeded

  - Array.join

  - loader.js:228 Function.Module._findPath
    internal/modules/cjs/loader.js:228:56

  - loader.js:591 Function.Module._resolveFilename
    internal/modules/cjs/loader.js:591:25

  - loader.js:520 Function.Module._load
    internal/modules/cjs/loader.js:520:25

  - loader.js:650 Module.require
    internal/modules/cjs/loader.js:650:17

  - helpers.js:20 require
    internal/modules/cjs/helpers.js:20:18

  - extract-chunks.js:35 getNames
    [vue-cli3-import-test]/[@vue]/preload-webpack-plugin/src/lib/extract-chunks.js:35:22

  - extract-chunks.js:44 getNames
    [vue-cli3-import-test]/[@vue]/preload-webpack-plugin/src/lib/extract-chunks.js:44:21

---

概述:

这个问题是在我迁移项目到cli3时遇到的，项目中使用到了import()，并且它的参数是一个变量。
我总结了一下，出现这个问题的需要两个条件：

1. 使用了Webpack的import()动态导入功能，且参数是一个变量（这个变量即使已经限制了文件夹范围，依然会有问题）。

2. 包含上述行为的.js文件在多页面应用中被多个page同时引用（我实验了一下，发现至少需要3个page）。另外，更加奇怪的是，从非pages文件引入就没这个问题。

注意：

需要结合我给的reproduction项目看一下:

1. 写了一个src/common/index.js, 用来引入pages和non-pages里的import-test模块
2. pages中一共有4个page，在其中A、B、C三个page里的app.js中，引入common/index.js
3. 为了验证从非pages文件夹中引入是否有问题，新建了一个no-pages文件夹

[LinusBorg]

Presumably some sort of cicular dependeny problem.

https://github.com/fxxjdedd/vue-cli3-import-test/blob/master/src/common/index.js#L2-L3

let filename = 'import-test.js'
import(`@/pages/${filename}`)

• this code will create async chunks for all components in /pages, not just import-test.js
• Some of these components import /common/index.js

I can't judge if this is inevitable or a bug in @vue/preload-webpack-plugin

[fxxjdedd]

yeah, circular dependency is the point，but isn't it common in projects？

[Kocal]

Not really, circular dependencies should be avoided to prevent this kind of problem.

Here for example, you can try to move your import() into a pages.js file, next to common.js. Then you will be able to import your common file in pages

[fxxjdedd]

you are right, but there is another confusing thing，in the demo project，if we only import '@/common' in pageA， and delete import in pageB and pageC, it won't crash.

[Kocal]

Mmmmh, maybe because it's not "cyclic"? 🤔
I'm not sure about dependencies resolving behaviour, but pageA imports common that imports pageA that imports common: so we have pageA <-> common and webpack can resolve it properly.

But when pageA imports common that imports that all pages, all pages will import common that will import all pages... And that's a total mess 😅

[LinusBorg]

Maybe it's indeed the preload-plugin we add that creates an infinite loop through the recursive call here:

https://github.com/vuejs/preload-webpack-plugin/blob/master/src/lib/extract-chunks.js#L43-L45

/cc @yyx990803

[dabaii]

在使用vue-cli2 迁移到vue-cli3过程中. 我也遇到相同的问题.

vue-cli2中index.html在根目录.

vue-cli3 默认配置中,index.html在public中.

迁移过程中我尝试把index.html移动到public,项目没有任何问题能够启动.

但是我不移动index.html(保持和vue-cli2项目目录),通过配置vue.config.js 的pages选项定义HtmlWebpackPlugin的template. 项目在编译过程中就会无法编译通过:

ERROR  Failed to compile with 1 errors                                                                                                                                                                                                                                                              15:20:37

  RangeError: Maximum call stack size exceeded

  - Array.join

  - loader.js:228 Function.Module._findPath
    internal/modules/cjs/loader.js:228:56

  - loader.js:591 Function.Module._resolveFilename
    internal/modules/cjs/loader.js:591:25

  - loader.js:520 Function.Module._load
    internal/modules/cjs/loader.js:520:25

  - loader.js:650 Module.require
    internal/modules/cjs/loader.js:650:17

  - helpers.js:20 require
    internal/modules/cjs/helpers.js:20:18

  - extract-chunks.js:35 getNames
    [vue-cli3]/[@vue]/preload-webpack-plugin/src/lib/extract-chunks.js:35:22

  - extract-chunks.js:44 getNames
    [vue-cli3]/[@vue]/preload-webpack-plugin/src/lib/extract-chunks.js:44:21

  - extract-chunks.js:44 getNames
    [vue-cli3]/[@vue]/preload-webpack-plugin/src/lib/extract-chunks.js:44:21

  - extract-chunks.js:44 getNames
    [vue-cli3]/[@vue]/preload-webpack-plugin/src/lib/extract-chunks.js:44:21

  - extract-chunks.js:44 getNames
    [vue-cli3]/[@vue]/preload-webpack-plugin/src/lib/extract-chunks.js:44:21

  - extract-chunks.js:44 getNames
    [vue-cli3]/[@vue]/preload-webpack-plugin/src/lib/extract-chunks.js:44:21

  - extract-chunks.js:44 getNames
    [vue-cli3]/[@vue]/preload-webpack-plugin/src/lib/extract-chunks.js:44:21

  - extract-chunks.js:44 getNames
    [vue-cli3]/[@vue]/preload-webpack-plugin/src/lib/extract-chunks.js:44:21

  - extract-chunks.js:44 getNames
    [vue-cli3]/[@vue]/preload-webpack-plugin/src/lib/extract-chunks.js:44:21

  - extract-chunks.js:44 getNames
    [vue-cli3]/[@vue]/preload-webpack-plugin/src/lib/extract-chunks.js:44:21

整个项目我只有路由配置文件采用了import()语法. 我尝试删减路由配置测试是否是import()语法引起的问题. 在少于4个import()的情况下,项目是可以通过编译的. 4个及以上编译不通过.

但是如果不使用 vue.config.js中配置的pages.就完全没有这个问题.这让我很迷惑.

[fxxjdedd]

Vue-cli3 is so charming🥞, but it is still under beta, we have to wait😋.

[wuservices]

This is exploding on me in the same way in my Vue CLI 3 project with a multi-page build. It happens once certain dependencies are included.

@LinusBorg it seems like this would be avoidable if the plugin kept track of what was processed in getNames (groups) to avoid infinite recursion. Or, it could be rewritten without recursion.

I haven't groked what the plugin does where it's crashing yet, but when searching around, I found https://github.com/webpack/webpack/blob/master/lib/optimize/EnsureChunkConditionsPlugin.js (potentially very unrelated), but noticed it was tracking chunk groups in a Set().

This might be logically wrong, but at least I was able to get my app running in dev mode temporarily by breaking the recursion by adding a Set() of processedGroups:

const processedGroups = new Set()
function getNames (groups) {
  const Entrypoint = require('webpack/lib/Entrypoint')
  const names = []
  for (const group of groups) {
    if (group instanceof Entrypoint) {
      // entrypoint
      if (group.options.name) {
        names.push(group.options.name)
      }
    } else {
      if (!processedGroups.has(group)) {
        processedGroups.add(group)
        names.push(...getNames(group.parentsIterable))
      }
    }
  }
  return names
}

Seems like this should be addressable by somebody who knows what actually should happen here.

Without a fix, is it impossible to have a multi-page build with circular references?