Why we need to change stage here?

The 100 is just a draft here, main reason is to ensure this plugin run after JavascriptPlugin

We register dependencyTemplate, we don't want it to be override by others. compilation.dependencyTemplates.set. Can we do that in other hook maybe ?

hm, need to think about it, lets' look at tests firstly, I will think about it

There is another question, what about require or other things, I think we should try to solve it for any cases, not just for side effect imports...

Currently I think it's the most safe way, I choose EsmSideEffectDependency because it just means this connection is for side effect, and we can ensure the js output of CssModule has no side effect(when disabled hmr). so this connection can be safely removed.

But others like require, user can write like this

const o = require('./foo.css')

call(o)

There is only one connection, and it contains CjsRequireDependency. CjsRequireDependency is not like EsmSideEffectDependency, it can have side effect and likely to consume the result. We cannot safely remove this connection.

What about just require('./foo.css')? Technically we can remove empty JS modules here too

Yes, but we can't do the same for require using the solution of this PR

SideEffectDependency means connection and executing side effect, we can know css has no side effect so we can remove SideEffectDependency.

If exports is used, there is SideEffectDependency and SpecifierDependency, so we can know it's exports are used

If exports is not used, there is only SideEffectDependency, so we can know it's exports are not used

But RequireDependency means connection and has access the exports, we can't know if the importer uses exports or not. Whether exports are used or not can not be told just by dependencies.

You can see there is no difference.

How about reading exportsType info ? Seems a way, I'll check if that's doable without affecting performance.

@JSerFeng I am fine with only for import, just think how we can solve it more common way (discussion, no more)

How about reading exportsType info ? Seems a way, I'll check if that's doable without affecting performance.

Feel free to experiments 👍

I tried, but unfortunately we can't tell if exports are used or not from exports info.

require('style.css')

FlagDependencyUsagePlugin doesn't analyze above syntax, even with __esModule.

I originally want to try removing js when CssModule has exportType === 'link' && !buildInfo.isCssModule, but that would break users who use if (require('./style.css') === undefined) {})

@JSerFeng PR looks good, let's resolve it, I still think we can move logic to HarmonyImportSideEffectDependency.apply and avoid stage here, so we will have the only one HarmonyImportSideEffectDependencyTemplate

Got it, done.

I was thinking that HarmonyImportSideEffectDependency should only render when ref module's sourceType is JavaScript. But it seems other sourceType need it too, like ConsumeShared or Remote or Runtime.

So now don't render if only all sourceType is Css.

It seems we can remove the module.hot !== true line.
Since we no longer generate JS code for import "./index.css", it doesn’t exist in the output __webpack_modules__, Its behavior is closer to being self-accepted. Then will skip generating the side-effect hmrCode for it.

don't know why there is no ./n.css in previous version, seems it should be here

No issues with the test case changes here, ./n.css got concatenated earlier.

same above