Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Can't apply plugins to worker

Aperta
#87 4 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
28/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
javascript, webpack

Direzione di ricerca

Inizia in src/index.js intorno alla chiamata a createChildCompiler alla riga 59 e analizza il comportamento di webpack's Compiler.js relativo ai compilatori figli nelle righe collegate. Traccia come vengono creati i compilatori figli dei worker e determina come potrebbe essere fornito un elenco di plugin senza influire sugli altri compilatori figli. Il lavoro è completato quando le build dei worker possono ricevere plugin come CompressionPlugin, con la copertura per la configurazione supportata.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
JavaScript
Stelle
2.3k
Fork
85
Metriche di merge delle PR
Nessuna PR unita negli ultimi 30g

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di developit/workerize-loader

Tutte le issue di developit/workerize-loader

Issue simili

Altre issue su JavaScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.