Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Can't apply plugins to worker

Ouverte
#87 4 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
28/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
À l'abandon
Stack technique
javascript, webpack

Piste de recherche

Commencez dans src/index.js autour de l'appel à createChildCompiler à la ligne 59 et examinez le comportement de webpack's Compiler.js concernant les compilateurs enfants aux lignes liées. Suivez la manière dont les compilateurs enfants de worker sont créés et déterminez comment une liste de plugins pourrait être fournie sans affecter les autres compilateurs enfants. C'est terminé lorsque les builds de worker peuvent recevoir des plugins tels que CompressionPlugin, avec une couverture pour la configuration prise en charge.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
JavaScript
Étoiles
2.3k
Forks
85
Métriques de merge des PR
Aucune PR mergée en 30 j

Guide de contribution

Aucun guide de contribution indexé pour ce dépôt

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de developit/workerize-loader

Toutes les issues de developit/workerize-loader

Issues similaires

Plus d'issues JavaScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.