5.95.0 -> 5.96.1 regression TypeError: this._moduleGraph.getIncomingConnections is not a function

[Knagis]

Bug report

What is the current behavior?

After upgrading webpack from 5.95.0 to 5.96.1, running webpack production build results in

TypeError: this._moduleGraph.getIncomingConnections is not a function
    at AssetGenerator.getTypes (/builds/mobile/js-clients/node_modules/webpack/lib/asset/AssetGenerator.js:593:41)
    at NormalModule.getSourceTypes (/builds/mobile/js-clients/node_modules/webpack/lib/NormalModule.js:1386:66)
    at getSize (/builds/mobile/js-clients/node_modules/webpack/lib/optimize/SplitChunksPlugin.js:1717:34)
    at /builds/mobile/js-clients/node_modules/webpack/lib/util/deterministicGrouping.js:295:40
    at Function.from (<anonymous>)
    at module.exports (/builds/mobile/js-clients/node_modules/webpack/lib/util/deterministicGrouping.js:293:22)
    at /builds/mobile/js-clients/node_modules/webpack/lib/optimize/SplitChunksPlugin.js:1689:23
    at Hook.eval (eval at create (/builds/mobile/js-clients/node_modules/tapable/lib/HookCodeFactory.js:19:10), <anonymous>:19:16)
    at Hook.CALL_DELEGATE [as _call] (/builds/mobile/js-clients/node_modules/tapable/lib/Hook.js:14:14)
    at Compilation.seal (/builds/mobile/js-clients/node_modules/webpack/lib/Compilation.js:3111:36)

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

This happens on our rather large monorepo build, i haven't had the chance to troubleshoot, hoping that the stack trace might give enough idea to you. If not, i will do more research in the upcoming days.

What is the expected behavior?

Other relevant information:
webpack version: 5.96.1
Node.js version: 20.11.1
Operating System: linux/docker
Additional tools:

[alexander-akait]

What is the expected behavior?

Please fill in this information.

[alexander-akait]

maybe you have something like that new AssetGenerator - https://github.com/webpack/webpack/blob/main/lib/asset/AssetModulesPlugin.js and don't pass moduleGraph.

Technically it is not a public class and therefore not considered a critical changes, but you all could import it (using require/import) and use it.

[Knagis]

oh, thank you... i saw the stack trace only containing webpack code and didn't realize that one of our plugins extend, not copy the default AssetGenerator, thought we had copies only.

Very sorry, this is our own issue.

[alexander-akait]

@Knagis To be honest - ideally we should pass moduleGraph in getTypes - https://github.com/webpack/webpack/blob/main/lib/asset/AssetGenerator.js#L591 as the second arg, I thought about it but decided that since it is not a public class, it should not break for anyone, perhaps the solution to pass it as the second arg would be more secure.

I still think about implementing this for the new release... Maybe do you want to help with it and no future breaking changes

[Knagis]

I'll see, maybe i can do that.

btw, the one what i think more legitimate usecase for the custom asset plugin is handling of .babylon files as assets - but since .babylon files can include links to images, i need to parse them out and add as dependencies. usually people do this via loaders, but to me it felt like embracing asset modules is better, but it is something that have broken multiple times already during upgrades (since we are using internal code). However, perhaps such assets with dependencies is something that could be more natively supported (providing some extendable interface) or is the intention that loader would be used for this, not asset modules?

the other case where we have custom asset resources is "image sets" - we can have for example image.png.small - an auto generated modification of the original image. These files are served by webserver automatically based on some rules. But to do that i need both files to have the same filename - including the content hash part. And i need the content hash for both to be generated from both files, not just the one. so my asset parser finds the linked files, adds dependencies and then generator is just a copy of built-in assetGenerator where the generate() function is overridden to generate hash from all files, not just one.

would you consider a PR that makes the AssetParser / AssetGenerator somehow extensible to support such assets with dependencies? I think mostly just extracting few parts of AssetGenerator.generate() into separate methods that can be overridden as hooks would be sufficient, though with the added drawback that AssetParser/AssetGenerator would become public api.

[alexander-akait]

@Knagis

would you consider a PR that makes the AssetParser / AssetGenerator somehow extensible to support such assets with dependencies? I think mostly just extracting few parts of AssetGenerator.generate() into separate methods that can be overridden as hooks would be sufficient, though with the added drawback that AssetParser/AssetGenerator would become public api.

I see the problem, yes, the solution to use hooks here seems like a pretty good idea, I would consider your suggestion for improvement. I think we could find a balance in this.