Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Can't apply plugins to worker

Aberta
#87 4 comentários 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
28/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Estagnada
Stack de tecnologia
javascript, webpack
Domínio
build-system, tooling

Direção de pesquisa

Comece em src/index.js, em torno da chamada a createChildCompiler na linha 59, e revise o comportamento de compiladores filhos de webpack's Compiler.js nas linhas vinculadas. Rastreie como os compiladores filhos de worker são criados e determine como uma lista de plugins poderia ser fornecida sem afetar compiladores filhos não relacionados. Está concluído quando os builds de worker puderem receber plugins como CompressionPlugin, com cobertura para a configuração compatível.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

Currently there is no way to pass plugins to workerize-loader.

Webpack's documentation is wrong when it states that child compilers inherit all hooks and plugins from the parent compiler. They infact do not inherit plugins at all; they copy over a number of hooks from the parent compiler -- where some plugins may have added them -- to the child compiler.

Several hooks are blacklisted. Banned from this copy process are: make, compile, emit, afterEmit, invalid, done, and thisCompilation. There are ofcourse good reasons not to copy those hooks - as doing so would mess with the control flow for the child compilation and parent compilation. However, it does mean the child compiler has to be fed its own instances of plugins such as the CompressionPlugin which attach to those hooks.

https://github.com/webpack/webpack/blob/498bb0841bd79476569701dc2e4f0f65dc87359c/lib/Compiler.js#L773-L846

This is what the third plugins argument to the createChildCompiler method is for, but having a look at how the child compiler that creates the body of the worker is called:

https://github.com/developit/workerize-loader/blob/2688667adf334e45c69c04ee3bd60f68a455583a/src/index.js#L59

it doesn't link up that third parameter. So right now there is no well-defined way to e.g. apply CompressionPlugin and get Gzip or Brotli compressed workers.


It may still be possible to achieve this by tapping the childCompiler hook on the parent compilation, as it does get passed the created child compiler.

This requires people write their own custom "plugin to apply plugins" - which is well beyond the comfort zone of most Webpack users. (Most webpack users don't write their own plugins. That's something you typically only do if you really; really know what you're doing. )

It's also not exactly trivial to get right, as you'd still also need to filter by the child compiler's name to ensure they're only adding plugins to the correct child compilers created by the workerize-loader and not to e.g. those created by the MiniCssExtractPlugin. Making this worse is the fact that those child compiler names are internal implementation details and not part of any public API, i.e. are subject to change over time.

I.e. this is a short-term workaround at best.

Linguagem predominante
JavaScript
Estrelas
2.3k
Forks
85
Métricas de merge de PRs
Nenhum PR com merge em 30d

Guia de contribuição

Nenhum guia de contribuição indexado para este repositório

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de developit/workerize-loader

Todas as issues de developit/workerize-loader

Issues semelhantes

Mais issues de JavaScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.