webpack: RangeError: Maximum call stack size exceeded

Bug report

What is the current behavior? After running npm run prod, webpack throws,

➜  aem-test git:(main) ✗ npm run prod

> aem-maven-archetype@1.0.0 prod
> NODE_ENV=production webpack --config ./webpack.prod.js && clientlib --verbose

/Users/kolivar/aem-test/node_modules/webpack/lib/util/runtime.js:60
exports.forEachRuntime = (runtime, fn, deterministicOrder = false) => {
                         ^

RangeError: Maximum call stack size exceeded
    at exports.forEachRuntime (/Users/kolivar/aem-test/node_modules/webpack/lib/util/runtime.js:60:26)
    at ExportInfo.setUsed (/Users/kolivar/aem-test/node_modules/webpack/lib/ExportsInfo.js:1017:4)
    at ExportsInfo.setUsedWithoutInfo (/Users/kolivar/aem-test/node_modules/webpack/lib/ExportsInfo.js:392:31)
    at processReferencedModule (/Users/kolivar/aem-test/node_modules/webpack/lib/FlagDependencyUsagePlugin.js:80:25)
    at processModule (/Users/kolivar/aem-test/node_modules/webpack/lib/FlagDependencyUsagePlugin.js:270:9)
    at processModule (/Users/kolivar/aem-test/node_modules/webpack/lib/FlagDependencyUsagePlugin.js:206:10)
    at processModule (/Users/kolivar/aem-test/node_modules/webpack/lib/FlagDependencyUsagePlugin.js:206:10)
    at processModule (/Users/kolivar/aem-test/node_modules/webpack/lib/FlagDependencyUsagePlugin.js:206:10)
    at processModule (/Users/kolivar/aem-test/node_modules/webpack/lib/FlagDependencyUsagePlugin.js:206:10)
    at processModule (/Users/kolivar/aem-test/node_modules/webpack/lib/FlagDependencyUsagePlugin.js:206:10)

If the current behavior is a bug, please provide the steps to reproduce.

Clone https://github.com/kevinolivar/aem-test
Run npm run prod

What is the expected behavior? The application should successfully be built as with using the command npm run dev.

If it can also help investigating this issue, I first thought it was maybe related to MiniCssExtractPlugin. Here some more details on that issue https://github.com/webpack-contrib/mini-css-extract-plugin/issues/733. However, the problem may also be in webpack.

Other relevant information: webpack version: 5.65.0 Node.js version: 16.11.1 Operating System: Mac OS Big Sur 11.5.2 (20G95) Additional tools: npm version: 8.0.0 yarn version: 1.22.5 webpack-cli version: 4.9.1 webpack-dev-server version: 4.7.1 webpack-merge version: 5.8.0 mini-css-extract-plugin version: 2.4.5

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 20 (10 by maintainers)

Most upvoted comments

@alexander-akait circular import itself works fine in js and css (mini-css) I have checked

vankop on Mar 23, 2022

Let’s keep open, webpack still should not throw an error on circular dependencies

alexander-akait on Dec 29, 2021

There is the problem with circular dependencies, I am afraid it works before, but works invalid, using import "./**/*.ts"; should not include itself, it is wrong, you can open an issue in https://github.com/adobe/aem-project-archetype and report them about the problem

alexander-akait on Dec 28, 2021

@soluml I myself never used glob but always manually included files I needed. Eg. exporting my components through a single index.ts. I guess case by case. Eg. team size, project size…

Your explanation makes absolutely sense, thanks again for the clarifications.

kevinolivar on Dec 29, 2021

@kevinolivar - glob-import-loader has been updated which excludes the resourcePath from being glob imported.

soluml on Dec 29, 2021

I look at source code of glob-import-loader and there are some problems too:

import has absolute paths, i.e. import "/home/evilebottnawi/IdeaProjects/aem-test/src/main/webpack/site/main.ts";, and it is wrong, because import should be URL
Also import should have relative paths (relative to the file where it is used), not absolute, because it will be bad for cache

Why you need this loader? I would recommend to be as close as possible with ESM spec and do not use this loader.

alexander-akait on Dec 28, 2021