Pdf.js: Supprimer webpack peerDependency du projet pdfjs-dist

Créé le 17 mai 2018  ·  7Commentaires  ·  Source: mozilla/pdf.js

Quel est le comportement attendu ?
Le projet pdfjs-dist ne doit pas inclure webpack en tant que peerDependency car il peut vraiment fonctionner sans lui lors du chargement des scripts à partir du répertoire de construction.

Qu'est ce qui ne s'est pas bien passé?
J'utilise PDFJS dans un composant pour visualiser un PDF à l'aide d'Angular 6. Ne pas inclure de webpack dans mon projet (je n'en ai pas du tout besoin), créer une fenêtre contextuelle d'avertissement de peerDependency à chaque fois que j'exécute une commande npm ou à chaque fois que quelqu'un installe mon composant .

1-other

Commentaire le plus utile

Salut, @timvandermeij. Merci pour votre réponse!

webpack est un outil de construction et, en tant que tel, il n'a généralement de sens qu'en tant que "devDependency" - ou est autrement limité au pipeline de construction de la bibliothèque. L'inclure en tant que "peerDependency" signifie que les utilisateurs doivent soit l'installer localement (même s'ils n'en ont pas besoin/ne s'en soucient pas), soit ignorer l'avertissement qui apparaît à chaque fois sur npm install .

Je ne connais pas worker-loader , alors prenez mes commentaires avec une pincée de sel. Mais s'il est comme n'importe quel autre chargeur webpack , ils ne sont généralement requis que comme étape de configuration de construction et rien d'autre. De plus, cela n'a pas de sens dans un contexte où la bibliothèque est destinée à être utilisée en dehors du Web (comme Node).

Est-ce que pdf.js agit comme une sorte de plugin webpack dans certains cas ? S'il _est_, il _pourrait_ être logique d'inclure à la fois le chargeur et webpack tant que dépendance. Mais, même dans ce cas, je dirais que ce type de support devrait être extrait dans son propre référentiel/module.

J'ai pris la liberté de bifurquer le repo et de retirer tout webpack lié. Cela fonctionne toujours parfaitement pour moi dans mon application Node.

Tous les 7 commentaires

Exactement. Avoir webpack tant que "peerDependency" dans un paquet distribuable comme celui-ci est tout à fait faux et devrait être supprimé.

La dépendance aux pairs a été ajoutée dans #9249 à cause de worker-loader . Pourriez-vous expliquer un peu pourquoi il est mal de l'avoir dans notre référentiel ? Je suis d'accord pour l'enlever si c'est sûr de ne pas casser les choses.

Salut, @timvandermeij. Merci pour votre réponse!

webpack est un outil de construction et, en tant que tel, il n'a généralement de sens qu'en tant que "devDependency" - ou est autrement limité au pipeline de construction de la bibliothèque. L'inclure en tant que "peerDependency" signifie que les utilisateurs doivent soit l'installer localement (même s'ils n'en ont pas besoin/ne s'en soucient pas), soit ignorer l'avertissement qui apparaît à chaque fois sur npm install .

Je ne connais pas worker-loader , alors prenez mes commentaires avec une pincée de sel. Mais s'il est comme n'importe quel autre chargeur webpack , ils ne sont généralement requis que comme étape de configuration de construction et rien d'autre. De plus, cela n'a pas de sens dans un contexte où la bibliothèque est destinée à être utilisée en dehors du Web (comme Node).

Est-ce que pdf.js agit comme une sorte de plugin webpack dans certains cas ? S'il _est_, il _pourrait_ être logique d'inclure à la fois le chargeur et webpack tant que dépendance. Mais, même dans ce cas, je dirais que ce type de support devrait être extrait dans son propre référentiel/module.

J'ai pris la liberté de bifurquer le repo et de retirer tout webpack lié. Cela fonctionne toujours parfaitement pour moi dans mon application Node.

Existe-t-il un plan pour supprimer webpack en tant que dépendance. @nfantone aviez -vous prévu de soumettre un PR ?

@mishawakerman Je n'ai jamais vraiment reçu de réponse "officielle" à ce problème - et je ne sais toujours pas pourquoi webpack est répertorié comme une dépendance. Mon intuition (limitée) me dit que cela fait partie d'un problème plus important où pdf.js est couplé à une partie de son implémentation qui dépend indirectement de webpack et doit être remaniée d'une manière ou d'une autre.

Cette question est également posée sur IRC et nous avons obtenu cette réponse : https://mozilla.logbot.info/pdfjs/20180606#c14862530 -c14862541. En bref, je ne connais pas vraiment le regroupement Webpack lui-même, mais si ce n'est vraiment que pour l'exemple, je suppose que nous pouvons le supprimer. Veuillez vérifier si tel est le cas avant de soumettre un PR.

Fermer puisque faire cela n'est pas vraiment une bonne option étant donné que #9248 reviendra si nous faisons cela. Au lieu de cela, ce que nous devrions faire est #9580 qui est discuté dans IRC à https://mozilla.logbot.info/pdfjs/20180606#c14862530 -c14862634.

Cette page vous a été utile?
0 / 5 - 0 notes