Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Can't apply plugins to worker

Abierto
#87 4 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
28/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
javascript, webpack

Línea de trabajo

Comienza en src/index.js alrededor de la llamada a createChildCompiler en la línea 59 y revisa el comportamiento de webpack's Compiler.js para los compiladores secundarios en las líneas enlazadas. Rastrea cómo se crean los compiladores secundarios de worker y determina cómo podría proporcionarse una lista de plugins sin afectar a otros compiladores secundarios. Se considera terminado cuando las compilaciones de worker pueden recibir plugins como CompressionPlugin, con cobertura para la configuración compatible.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
JavaScript
Estrellas
2.3k
Forks
85
Métricas de merge de PR
Sin PR fusionados en 30 d

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de developit/workerize-loader

Todos los issues de developit/workerize-loader

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.