Pdf.js: getDocument se bloque dans l'environnement Jest/JSDom

Créé le 18 mars 2018  ·  4Commentaires  ·  Source: mozilla/pdf.js

Sur PDF.js 2.0.385 et versions ultérieures, exécutez l'exemple le plus simple suivant :

pdf.getDocument({ data: arrayBufferData })
  .then(() => console.log('Success'))
  .catch() => console.log('Fail'));

fonctionne bien sur Node.js, évidemment.

Exécution de la même pièce dans Jest, comme dans cet exemple (simplifié, veuillez ignorer le fait que les tests doivent être asynchrones) :

describe('Test', () => {
  it('does something', () => {
    pdf.getDocument({ data: arrayBufferData })
      .then(() => console.log('Success'))
      .catch() => console.log('Fail'));
  });
}
  • si testEnvironment est défini sur "node" , réussit.
  • si testEnvironment est défini sur "jsdom" (par défaut), se bloque et n'atteint jamais .then() .

Sur PDF.js 2.0.305 et versions antérieures, ce n'est pas un problème, car vous pouvez facilement désactiver les travailleurs manuellement.

Maintenant qu'il n'y a aucun moyen de le faire via la configuration à partir de # 9385, tous les projets utilisant PDF.js et Jest/JSDom ne pourront pas tester quoi que ce soit lié à PDF.js. Passer testEnvironment à "node" n'est généralement pas une option car cela entraînera l'échec de pratiquement tout le reste sur le front-end.

1-core

Commentaire le plus utile

J'ai réussi à m'en occuper ! Pour ceux qui sont bloqués comme moi, ne définissez PAS pdfjs.GlobalWorkerOptions.workerSrc ou pdfjs.GlobalWorkerOptions.workerPort . Utilisez plutôt le fichier pdf.worker.entry.js - importez-le simplement et le tour est joué !

Tous les 4 commentaires

Comme mentionné dans ISSUE_TEMPLATE.md et CONTRIBUTING.md :
Pour les problèmes liés aux implémentations personnalisées, vous devez donner accès à un petit exemple exécutable complet pour que le problème soit exploitable. Et s'il vous plaît ne présumez pas que les gens sont familiers avec divers frameworks JS, dans ce cas "Jest".

Sans aucun contexte ni code, les questions suivantes viennent à l'esprit :
Les workers sont-ils pris en charge, et si oui, avez-vous essayé de définir l'option workerSrc et d'exécuter simplement des tests avec les workers activés ?
Avez-vous essayé d'utiliser l'option workerPort pour charger le fichier de travail ? Gardez à l'esprit qu'il est également possible de passer un travailleur à getDocument , voir https://github.com/mozilla/pdf.js/blob/0d391daccc2f4e4b9c91268e719bd10fe63a49ae/src/display/api.js#L129 -L130

J'ai réussi à m'en occuper ! Pour ceux qui sont bloqués comme moi, ne définissez PAS pdfjs.GlobalWorkerOptions.workerSrc ou pdfjs.GlobalWorkerOptions.workerPort . Utilisez plutôt le fichier pdf.worker.entry.js - importez-le simplement et le tour est joué !

La solution ci-dessus n'a pas fonctionné pour moi, à la place, j'ai dû configurer jest pour utiliser node au lieu de jsdom (activé par défaut)

L'ajout de ceci en haut de mon fichier de spécifications l'a résolu

/**
 * @jest-environment node
 */

Pour moi, aucune des solutions ci-dessus ne fonctionne. J'utilise vue-cli avec des tests de plaisanterie

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