Issue when upgrading from 0.11.3 to 0.12.0 that persists through 1.4.0

• Operating System: Mac OS
• Node Version: 13.11.0
• NPM Version: 6.14.8
• webpack Version: 5.28.0
• mini-css-extract-plugin Version: 1.4.0

Expected Behavior

That I can build successfully. For some reason I’ve been unable to get mini-css-extract-plugin to work with Webpack 5. When I use style-loader, everything works fine, but if I set the mode to production and use this plugin, the build blows up with the below. It fails consistently, regardless of what’s in the css/scss files. Even an empty main.css file imported via entry blows up with the following error.

There are no issues if I move back to 0.11.3. If I move to 0.12.0, the issue starts. I noticed on the releases page and when comparing the two versions that a new feature was added in v0.12.0: opt-in to transitive only side effects (webpack@5), no more empty JS chunks

I’m not sure if this is a feature we can disable or if there is something in the build that 0.11.3 tolerated that 0.12.0 and beyond do not?

Any help would be appreciated, thanks!

Actual Behavior

> webpack --config ./webpack.prod.js && clientlib --verbose

/Users/bsolum/Documents/aem-playground/modified-archetype/ui.frontend/node_modules/webpack/lib/ExportsInfo.js:370
                for (const exportInfo of this._exports.values()) {
                                                       ^

RangeError: Maximum call stack size exceeded
    at MapIterator.[Symbol.iterator] (<anonymous>)
    at ExportsInfo.setUsedWithoutInfo (/Users/bsolum/Documents/aem-playground/modified-archetype/ui.frontend/node_modules/webpack/lib/ExportsInfo.js:370:42)
    at processReferencedModule (/Users/bsolum/Documents/aem-playground/modified-archetype/ui.frontend/node_modules/webpack/lib/FlagDependencyUsagePlugin.js:75:25)
    at processModule (/Users/bsolum/Documents/aem-playground/modified-archetype/ui.frontend/node_modules/webpack/lib/FlagDependencyUsagePlugin.js:263:9)
    at processModule (/Users/bsolum/Documents/aem-playground/modified-archetype/ui.frontend/node_modules/webpack/lib/FlagDependencyUsagePlugin.js:197:10)
    at processModule (/Users/bsolum/Documents/aem-playground/modified-archetype/ui.frontend/node_modules/webpack/lib/FlagDependencyUsagePlugin.js:197:10)
    at processModule (/Users/bsolum/Documents/aem-playground/modified-archetype/ui.frontend/node_modules/webpack/lib/FlagDependencyUsagePlugin.js:197:10)
    at processModule (/Users/bsolum/Documents/aem-playground/modified-archetype/ui.frontend/node_modules/webpack/lib/FlagDependencyUsagePlugin.js:197:10)
    at processModule (/Users/bsolum/Documents/aem-playground/modified-archetype/ui.frontend/node_modules/webpack/lib/FlagDependencyUsagePlugin.js:197:10)
    at processModule (/Users/bsolum/Documents/aem-playground/modified-archetype/ui.frontend/node_modules/webpack/lib/FlagDependencyUsagePlugin.js:197:10)

Code

    rules: [
        {
          test: /\.s?css$/,
          exclude: /node_modules/,
          use: [
            env.dev ? "style-loader" : MiniCssExtractPlugin.loader,
            {
              loader: "css-loader",
            },
            {
              loader: "sass-loader",
            },
          ],
        },
      ],
    },
    plugins: [
      new CleanWebpackPlugin(),
      new MiniCssExtractPlugin({
        filename: "clientlib-[name]/[name].css",
      }),
      new CopyWebpackPlugin({
        patterns: [
          {
            from: path.resolve(__dirname, SOURCE_ROOT + "/resources"),
            to: "./clientlib-site/",
          },
        ],
      }),
    ],

  "devDependencies": {
    "@babel/core": "^7.13.10",
    "@babel/eslint-parser": "^7.13.10",
    "@babel/preset-env": "^7.13.12",
    "@typescript-eslint/eslint-plugin": "^4.19.0",
    "@typescript-eslint/parser": "^4.19.0",
    "aem-clientlib-generator": "^1.7.5",
    "aemsync": "^4.0.3",
    "autoprefixer": "^10.2.5",
    "babel-loader": "^8.2.2",
    "browserslist": "^4.16.3",
    "clean-webpack-plugin": "^3.0.0",
    "copy-webpack-plugin": "^8.1.0",
    "css-loader": "^5.2.0",
    "cssnano": "^5.0.0-rc.2",
    "cssnano-preset-advanced": "^4.0.7",
    "eslint": "^7.22.0",
    "eslint-plugin-prettier": "^3.3.1",
    "glob-import-loader": "^1.1.4",
    "mini-css-extract-plugin": "^1.4.0",
    "postcss": "^8.2.8",
    "postcss-loader": "^5.2.0",
    "prettier": "^2.2.1",
    "sass": "^1.32.8",
    "sass-loader": "^11.0.1",
    "style-loader": "^2.0.0",
    "terser-webpack-plugin": "^5.1.1",
    "ts-loader": "^8.0.18",
    "tsconfig-paths-webpack-plugin": "^3.5.1",
    "typescript": "^4.2.3",
    "watch": "^1.0.2",
    "webpack": "^5.28.0",
    "webpack-cli": "^4.5.0",
    "webpack-dev-server": "^3.11.2",
    "webpack-merge": "^5.7.3"
  },

How Do We Reproduce?

In a typical webpack build, use the preceding package.json dev dependencies and try to import a .css/,scss file via the main entry file.

[kevinolivar]

@soluml FYI. I opened a ticket for aem archetype and linked to the issues (this one and webpack).

[soluml]

@soluml I saw that your global-import-loader replaces https://github.com/fred104/webpack-import-glob-loader in the archetype, how come?

@kevinolivar - A few reasons:

1. It’s essentially been abandoned.
2. If I recall correctly, at the time we were using it for our AEM projects, it was causing npm audit errors.
3. Aliasing was a big part of our workflow. I even submitted a PR to webpack-import-glob-loader but it’s just sat there for well over a year now. The fix in that repo also doesn’t leverage enhanced resolver.
4. While certainly not essential for all my projects, I’ve found it useful in several, especially with AEM projects. I thought I could also improve it by leveraging enhanced resolver to not only support aliases but other custom Webpack resolution configurations.

Those are the main ones. The reason I submitted to the archetype was all of the above plus the fact that the company I worked for is a heavy user of the archetype. I wanted aliasing out OOTB and figured a maintained dependency was better than an unmaintained one. If you run into issues with it, let me know and I won’t let you hanging for 3+ years, lord willing 😉

Also, unrelated, thanks for following up and producing a proper example of the issue here. I was in a time crunch when I made this ticket and we were able to find a work-around that satisfied npm audit (and the higher ups) so I never had a chance to follow up.