Pdf.js: Eliminar webpack peerDependency del proyecto pdfjs-dist

Creado en 17 may. 2018  ·  7Comentarios  ·  Fuente: mozilla/pdf.js

¿Cuál es el comportamiento esperado?
El proyecto pdfjs-dist no debe incluir webpack como peerDependency, ya que realmente puede funcionar sin él al cargar los scripts desde el directorio de compilación.

¿Qué salió mal?
Estoy usando PDFJS en un componente para visualizar un PDF usando Angular 6. No incluir paquete web en mi proyecto (no lo necesito en absoluto), crear una ventana emergente de advertencia de peerDependency cada vez que ejecuto cualquier comando npm o cada vez que alguien instala mi componente .

1-other

Comentario más útil

Hola, @timvandermeij. ¡Gracias por su respuesta!

webpack es una herramienta de compilación y, como tal, por lo general solo tiene sentido como "devDependency" , o está restringida de otro modo a la canalización de compilación de la biblioteca. Incluirlo como "peerDependency" significa que los usuarios deben instalarlo localmente (aunque no lo necesiten / no les importe) o ignorar la advertencia que aparece cada vez en npm install .

No estoy familiarizado con worker-loader , así que tome mis comentarios con una pizca de sal. Pero si es como cualquier otro cargador de webpack , normalmente solo se requieren como un paso de configuración de compilación y nada más. Además, tiene poco sentido en un contexto en el que la biblioteca debe usarse fuera de la web (como Node).

¿Está pdf.js actuando como una especie de complemento de webpack en algunos casos? Si _es_, _ podría_ tener sentido incluir tanto el cargador como webpack como dependencia. Pero, incluso entonces, diría que ese tipo de soporte debería extraerse a su propio repositorio / módulo.

Me tomé la libertad de bifurcar el repositorio y sacar todo lo relacionado con webpack . Todavía funciona absolutamente bien para mí en mi aplicación Node.

Todos 7 comentarios

Exactamente. Tener webpack como "peerDependency" en un paquete distribuible como este es simplemente incorrecto y debe eliminarse.

La dependencia de pares se agregó en # 9249 debido a worker-loader . ¿Podrías explicar un poco por qué está mal tenerlo en nuestro repositorio? Estoy de acuerdo con quitarlo si es seguro que no romperá las cosas.

Hola, @timvandermeij. ¡Gracias por su respuesta!

webpack es una herramienta de compilación y, como tal, por lo general solo tiene sentido como "devDependency" , o está restringida de otro modo a la canalización de compilación de la biblioteca. Incluirlo como "peerDependency" significa que los usuarios deben instalarlo localmente (aunque no lo necesiten / no les importe) o ignorar la advertencia que aparece cada vez en npm install .

No estoy familiarizado con worker-loader , así que tome mis comentarios con una pizca de sal. Pero si es como cualquier otro cargador de webpack , normalmente solo se requieren como un paso de configuración de compilación y nada más. Además, tiene poco sentido en un contexto en el que la biblioteca debe usarse fuera de la web (como Node).

¿Está pdf.js actuando como una especie de complemento de webpack en algunos casos? Si _es_, _ podría_ tener sentido incluir tanto el cargador como webpack como dependencia. Pero, incluso entonces, diría que ese tipo de soporte debería extraerse a su propio repositorio / módulo.

Me tomé la libertad de bifurcar el repositorio y sacar todo lo relacionado con webpack . Todavía funciona absolutamente bien para mí en mi aplicación Node.

¿Hay algún plan para eliminar el paquete web como dependencia? @nfantone ¿

@mishawakerman Realmente nunca recibí una respuesta "oficial" a este problema, y ​​todavía no sé por qué webpack aparece como una dependencia. Mi intuición (limitada) me dice que esto es parte de un problema mayor en el que pdf.js está acoplado a alguna parte de su implementación que depende indirectamente de webpack y necesita ser refactorizado de alguna manera.

Esta pregunta también se hace en IRC y obtuvimos esta respuesta: https://mozilla.logbot.info/pdfjs/20180606#c14862530 -c14862541. En resumen, no estoy realmente familiarizado con el empaquetado de Webpack en sí, pero si en realidad es solo para el ejemplo, supongo que podemos eliminarlo. Sin embargo, compruebe si ese es el caso antes de enviar un PR.

Cerrar ya que hacer esto no es realmente una buena opción dado que # 9248 regresará si hacemos eso. En cambio, lo que deberíamos hacer es # 9580, que se analiza en IRC en https://mozilla.logbot.info/pdfjs/20180606#c14862530 -c14862634.

¿Fue útil esta página
0 / 5 - 0 calificaciones