core icon indicating copy to clipboard operation
core copied to clipboard

fix: avoid shared module will be compiled in wrong target compiler

Open 2heal1 opened this issue 1 year ago • 13 comments
trafficstars

Description

  • avoid shared module will be compiled in wrong target compiler

html-webpack-plugin will use childCompiler which loader target is node to compile . And it will output the asset if the shared set a file path like this:

shared: {
  'shared-config': {
     import: './src/shared-config'
    }
},

html-webpack-plugin asset:

image

default target(browser) asset:

image

Related Issue

Types of changes

  • [ ] Docs change / refactoring / dependency upgrade
  • [ ] Bug fix (non-breaking change which fixes an issue)
  • [ ] New feature (non-breaking change which adds functionality)

Checklist

  • [x] I have added tests to cover my changes.
  • [x] All new and existing tests passed.
  • [x ] I have updated the documentation.

2heal1 avatar Jan 19 '24 09:01 2heal1

@ScriptedAlchemy I'm not sure whether the ProvideSharedPlugin can use thisCompilation instead of compilation, please help to review and check

2heal1 avatar Jan 19 '24 10:01 2heal1

the webpack reproduce demo:

  • repo: https://github.com/2heal1/webpack-demo/tree/chore/mf-share-file
  • reproduce steps
  1. pnpm i
  2. pnpm build
  3. watch the dist , and you will see two same name but different hash files :

image

One is bundled from htmlPlugin childCompiler and the other is from main compiler

2heal1 avatar Jan 19 '24 10:01 2heal1

I'm not sure of the implications of doing this. Would it mean that any child compilers created would not include any federation stuff unless the plugin is applied again on the child compiler?

ScriptedAlchemy avatar Jan 20 '24 00:01 ScriptedAlchemy

Can we cut a release of this? then i can override the packages in federation examples and we can test against all those as well

ScriptedAlchemy avatar Jan 20 '24 02:01 ScriptedAlchemy

I'm not sure of the implications of doing this. Would it mean that any child compilers created would not include any federation stuff unless the plugin is applied again on the child compiler?

@ScriptedAlchemy Yes, because the child compiler may have different target than the main compiler. Like HtmlPlugin sub cpmpiler will have node target, but the main compiler have browser target .

But maybe we can solve it according another way .

2heal1 avatar Jan 22 '24 02:01 2heal1

the webpack reproduce demo:

  • repo: https://github.com/2heal1/webpack-demo/tree/chore/mf-share-file
  • reproduce steps
  1. pnpm i
  2. pnpm build
  3. watch the dist , and you will see two same name but different hash files :

image

One is bundled from htmlPlugin childCompiler and the other is from main compiler

@ScriptedAlchemy Can you help to check this demo ? Maybe we can solve the issue in a simple way.

2heal1 avatar Jan 22 '24 02:01 2heal1

This is caused by addInclude in ProvideSharedPlugin, all provide modules will be added to compilation (and also child compilations) at hooks.finishMake.

Actually the additional html-webpack-plugin asset won't affect anything, and won't cause any issue, only the output size is bigger, I think it's ok to have these additional html-webpack-plugin assets. From the perspective of impact, can't shared modules in child compilation has more impact, it's potentially a breaking change, so I suggest keep it as it is

ahabhgk avatar Jan 22 '24 06:01 ahabhgk

Change htmlWebpackPlugin from child compiler to compilation.executeModule seems a better way to solve this

ahabhgk avatar Jan 22 '24 07:01 ahabhgk

This is caused by addInclude in ProvideSharedPlugin, all provide modules will be added to compilation (and also child compilations) at hooks.finishMake.

Actually the additional html-webpack-plugin asset won't affect anything, and won't cause any issue, only the output size is bigger, I think it's ok to have these additional html-webpack-plugin assets. From the perspective of impact, can't shared modules in child compilation has more impact, it's potentially a breaking change, so I suggest keep it as it is

@ahabhgk Yes, it will not have issues in most cases . But if users set chunkFileName as [name].js, which not include hash , the compile will be failed because of duplicate name file. image

2heal1 avatar Jan 22 '24 10:01 2heal1

Change htmlWebpackPlugin from child compiler to compilation.executeModule seems a better way to solve this

@ahabhgk how to set compilation.executeModule ? Do you mean excludeChunks in htmlWebpackPlugin ? I try it and not work as expected.

2heal1 avatar Jan 22 '24 11:01 2heal1

HtmlWebpackPlugin use child compiler to compile and execute to get the html asset, importModule (executeModule) is an alternative for child compiler, MiniCssExtractPlugin already switch to importModule from child compiler, HtmlWebpackPlugin hasn't, maybe we can have a try and contribute to HtmlWebpackPlugin

ahabhgk avatar Jan 22 '24 11:01 ahabhgk

One thing that wired to me is ConsumeSharedPlugin is using hooks.thisCompilation instead of hooks.compilation, what's the point if you provide shared modules in child compilation but only consume it in the main compilation. Now this fix make since to me :D

ahabhgk avatar Jan 24 '24 12:01 ahabhgk

Stale pull request message

github-actions[bot] avatar Mar 24 '24 15:03 github-actions[bot]

Stale pull request message

github-actions[bot] avatar May 26 '24 15:05 github-actions[bot]