Pdf.js: Générer (tester) des statistiques de couverture

unittestcli - Exécute quelques tests unitaires de PDF.js dans Node.js (avec des changements de source minimes, uniquement avec transpilation avec babel).
browserertest - Exécute des tests dans les navigateurs (nous testons Chrome et Firefox). Cela s'appuie sur le binaire créé par la cible de construction generic , qui utilise du code transpilé avec babel puis livré avec webpack.

Notez que bien que browsertest exécute les tests de référence , il existe également la commande unittest qui exécute l'ensemble complet des tests unitaires dans les navigateurs (par opposition à unittestcli qui n'exécute qu'un sous-ensemble des tests unitaires existants).

De plus, notez que l'étape "transpilation avec Babel" peut être ignorée, si l'indicateur de construction PDFJS_NEXT est défini (soit comme les autres indicateurs de construction dans gulpfile.js , soit comme argument de ligne de commande). Bien que le code soit toujours fourni avec Webpack, il est au moins possible d'éviter l'étape de transpilation.

@ Rob - WI aimerait travailler là-dessus

C'est le tien! Faites-nous savoir (de préférence sur IRC) si vous avez des questions.

@timvandermeij Je pense utiliser l'outil Karma.Il fonctionne avec le moteur de couverture de code d'Istanbul.Les statistiques peuvent être vérifiées pour l'exécution des tests, des rapports HTML peuvent être créés à partir de celui-ci.Est-ce une bonne façon de commencer?

En utilisant Karma, j'ai reçu des rapports de test https://drive.google.com/file/d/0ByddvU1PKkWaWEZTWHFYT0Y0aTg/view?usp=sharing
mais les statistiques de couverture des tests ne sont pas affichées https://drive.google.com/file/d/0ByddvU1PKkWaS1ZiT1dobU1DQUk/view?usp=sharing

@ Divya063 Pourriez-vous partager votre code, par exemple en poussant votre code actuel dans une branche de votre fork pdf.js sur Github? Je me demande si webpack ou babel est exécuté lorsque cela est nécessaire.

Et quelle version de Node.js utilisez-vous?

Merci pour la réponse, la version Node est 6.11.1. Voici le lien vers la branche https://github.com/Divya063/pdf.js/tree/dev

Les erreurs sont:

Firefox 43.0.0
SyntaxError: les déclarations d'importation ne peuvent apparaître qu'au niveau supérieur
Chrome 60.0.3112
Erreur de syntaxe non interceptée: importation de jeton inattendue

Cela indique que le code n'est pas transpilé avant utilisation. Actuellement, la prise en charge intégrée des modules ES n'est activée par défaut dans aucun navigateur ( plus d'informations ), le code doit donc être transpilé en premier.

J'ai édité mon message initial pour indiquer où la transpilation est configurée dans le système de construction de PDF.js. Vous pouvez peut-être essayer d'utiliser un plugin existant pour intégrer istanbul et babel. Une recherche rapide montre https://github.com/istanbuljs/babel-plugin-istanbul , mais il peut y avoir d'autres options aussi.

(et la version stable actuelle de Firefox est 55. Vous avez testé avec Firefox 43, qui est ancien et non pris en charge. Je vous suggère de mettre à niveau vers une version récente de Firefox avant de tester à nouveau)

@ Rob - W Merci d'avoir indiqué les erreurs. Je mettrai bientôt à jour les résultats.

@ Rob - WI a transpilé le code en utilisant karma-browserify et mis à jour la version firefox mais encore beaucoup d'erreurs sont à venir.Voici le lien de la branche https://github.com/Divya063/pdf.js/tree / dev

Pouvez-vous partager les messages d'erreur?

Et si possible, essayez d'utiliser webpack au lieu de browserify, car webpack est déjà ce que nous utilisons. Cela nous permet d'instrumenter le code qui est réellement utilisé dans le navigateur.

Et je vois également que vous archivez .idea et d'autres fichiers projet / IDE spécifiques à l'utilisateur. Lorsque vous contribuez à un projet existant, il est préférable de ne pas ajouter de fichiers non liés au projet, car cela encombre le référentiel et provoque des conflits de fusion. Dans la demande d'extraction finale, ces fichiers ne doivent pas être inclus.

Ce problème est-il toujours en place? Si oui, j'aimerais y travailler.

Oui, n'hésitez pas à y travailler.

@timvandermeij
Je travaillais là-dessus. J'ai utilisé istanbul pour couvrir mes tests et ma combinaison pour afficher les rapports. J'ai apporté les modifications nécessaires là où c'est nécessaire. Cependant, chaque fois que je lance des combinaisons en utilisant

npm run coveralls

J'obtiens l'erreur suivante

npm run coveralls

> [email protected] coveralls /home/shikhar/Desktop/mozillaPdfJs/pdf.js
> npm run cover -- --report lcovonly && cat ./coverage/lcov.info | coveralls


> [email protected] cover /home/shikhar/Desktop/mozillaPdfJs/pdf.js
> istanbul cover test/**/*.js "--report" "lcovonly"

Running test 1/16: test_first_run
Running test 2/16: test_first_run_incognito
Running test 3/16: test_storage_managed_unavailable
Running test 4/16: test_managed_pref
Running test 5/16: test_local_pref
Running test 6/16: test_managed_pref_is_overridden
Running test 7/16: test_run_extension_again
Running test 8/16: test_running_for_a_while
Running test 9/16: test_browser_update
Running test 10/16: test_browser_update_between_pref_toggle
Running test 11/16: test_extension_update
Running test 12/16: test_unofficial_build
Running test 13/16: test_fetch_is_supported
Running test 14/16: test_fetch_not_supported
Running test 15/16: test_fetch_mode_not_supported
Running test 16/16: test_network_offline
All tests completed.
No coverage information was collected, exit without writing coverage information
[error] "2017-12-17T11:00:06.112Z"  'error from lcovParse: ' 'Failed to parse string'
[error] "2017-12-17T11:00:06.116Z"  'input: ' ''
[error] "2017-12-17T11:00:06.116Z"  'error from convertLcovToCoveralls'

/home/shikhar/Desktop/mozillaPdfJs/pdf.js/node_modules/coveralls/bin/coveralls.js:18
        throw err;
        ^
Failed to parse string
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] coveralls: `npm run cover -- --report lcovonly && cat ./coverage/lcov.info | coveralls`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the [email protected] coveralls script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/shikhar/.npm/_logs/2017-12-17T11_00_06_136Z-debug.log

J'ai essayé de chercher ça ici et ici mais en vain. Avez-vous de l'aide sur le problème?

C'est difficile à dire sans voir le code. Pourriez-vous pousser le code vers une branche afin que les contributeurs ici puissent regarder avec vous?

@timvandermeij la voici . Veuillez ignorer le fichier gem. je l'ai déjà supprimé.

Tout commentaire @timvandermeij

Après un peu de recherche sur Google, il semble que cette erreur signifie que coveralls ne reçoit pas de données au format lcov . Vous pouvez vérifier si les commandes individuelles de npm run cover -- --report lcovonly && cat ./coverage/lcov.info | coveralls renvoient en fait les résultats que vous attendez.

@timvandermeij
Le principal problème actuellement est cette déclaration
No coverage information was collected, exit without writing coverage information
Pour cette raison, le fichier lcov reste à tout moment vide et cela se produit

[error] "2017-12-17T11:00:06.112Z"  'error from lcovParse: ' 'Failed to parse string'
[error] "2017-12-17T11:00:06.116Z"  'input: ' ''
[error] "2017-12-17T11:00:06.116Z"  'error from convertLcovToCoveralls'

Sur Google, il semble que ce soient des erreurs très courantes. et l'erreur revient essentiellement à Istanbul. J'ai essayé de basculer entre différentes versions du même mais l'erreur a continué à se produire. Cependant, à tous les endroits, le test a été fait par moka et non par lint ou unittest etc. et donc la plupart (presque) des résolutions sont également pour le moka uniquement. C'étaient des sources que j'ai recherchées

https://github.com/gotwarlost/istanbul/issues/262
https://github.com/coryhouse/react-slingshot/issues/245
https://github.com/gotwarlost/istanbul/issues/496
et plusieurs autres aussi mais aucun d'entre eux n'a vraiment aidé :(

La construction est passée sur travis ( https://travis-ci.org/shikhar-scs/pdf.js/jobs/318422621 ) mais là encore, la couverture n'est pas générée.

Je ne sais pas vraiment pourquoi cela se produit, mais je trouve aussi beaucoup de gens qui l'ont fait avec succès avec Jasmine, donc ça doit être possible. Pourriez-vous essayer si https://bryce.fisher-fleig.org/blog/setting-up-istanbul-with-jasmine/index.html fonctionne pour vous? Essayez d'abord ces étapes exactes pour voir si cela fonctionne de manière autonome, puis essayez de l'intégrer dans PDF.js.

@timvandermeij dessus
Les rapports de couverture sont enfin en cours de création. Cependant, je dois transpiler puis tester car il présente des problèmes avec les déclarations d'importation et d'exportation
Transformation error for /home/shikhar/Desktop/mozillaPdfJs/pdf.js/web/ui_utils.js ; return original code 'import' and 'export' may appear only with 'sourceType: "module"' (16:0)
Cette erreur arrive avec chaque fichier js et je vais y travailler et déposer un PR bientôt.

@timvandermeij

Les voici: la construction qui passe et appelle à la couverture .

Les rapports de couverture

Cependant, comme les déclarations d'importation et d'exportation existent, même après avoir atteint ces fichiers, elles ne sont pas entièrement testées et nous obtenons donc des rapports de couverture de 0%. Autant que je sache, je dois babélifier ces fichiers sur ES6 avant de tester jasmine et cela s'avère être un problème. Comment fournir du code ES6 à Jasmine?
Puis-je apporter des modifications au fichier gulp comme mentionné ici http://jpsierens.com/use-es6-right-now/ ?

Vous vous rapprochez en effet de la solution. D'après les rapports de couverture, il semble que vous exécutiez la couverture sur les fichiers lib , qui devraient déjà être transpilés vers ES6 (voir https://github.com/mozilla/pdf.js/blob/6ac9e1c5ed0d5f067872b8482724c171c79566b2/gulpfile. js # L965 et https://github.com/mozilla/pdf.js/blob/6ac9e1c5ed0d5f067872b8482724c171c79566b2/gulpfile.js#L985). Ou est-ce que le problème est que les tests unitaires eux-mêmes ne sont pas transpilés? Je ne sais pas vraiment comment cela fonctionne exactement, mais si tel est le cas, certaines modifications du Gulpfile pour les tests unitaires peuvent être nécessaires.

@timvandermeij

Ou est-ce que le problème est que les tests unitaires eux-mêmes ne sont pas transpilés? Je ne sais pas vraiment comment cela fonctionne exactement, mais si tel est le cas, certaines modifications du Gulpfile pour les tests unitaires peuvent être nécessaires.

Le problème était que j'exécutais les tests dans le mauvais dossier. build>lib dossier
Un autre problème était l'instruction --report lcovonly . Comme par magie (je ne sais vraiment pas pourquoi), lorsque j'ai retiré cette partie de la gamme des combinaisons, des rapports ont commencé à être générés.

Vous pouvez vérifier si les commandes individuelles de npm fonctionnent cover - --report lcovonly && cat ./coverage/lcov.info | les combinaisons retournent en fait les résultats que vous attendez.

Merci de l'avoir signalé.

Enfin, nous sommes en mesure de générer des rapports: tada: et bien qu'ils aient l'air un peu triste, mais la lecture des fichiers exacts vous donnera la raison pour laquelle -

1. Toutes les instructions conditionnelles non exécutées sont comptées comme «non couvertes».
2. Toutes les instructions d'affectation non exécutées sont également comptées comme «non couvertes».

Je n'ai évidemment pas téléchargé les rapports générés moi-même, mais je les ai hébergés sur un lien ici http://pdfjscoveragereport.bitballoon.com . Veuillez visiter ces liens et vous obtiendrez le rapport exact attendu.

Cependant ces résultats ne sont pas reflétés sur coveralls.io : cry: Je ne sais pas pourquoi. De plus, j'ai remarqué que même après avoir commis plusieurs fois coveralls , je construis toujours mon projet basé sur un très ancien commit et non sur un récent en raison de la couverture qui y est générée, mais reste toujours 0 ( même si ce n'est pas 0 maintenant). Veuillez m'aider à résoudre ce problème.

Cependant, npm run coveralls donnera tous les rapports de couverture dans ce format dans le dossier build/lib/coverage/lcov-report .

J'espère que tout cela aidera enfin, cependant, notre dernier problème est de montrer ces rapports en quelque sorte sur des combinaisons.

C'est le lien pour ma dernière version. https://travis-ci.org/shikhar-scs/pdf.js
C'est le lien pour mon dernier commit .

À part les rapports qui ne sont pas générés sur coveralls.io, tout va bien, je suppose. Alors dois-je générer un PR car il attirera l'attention de beaucoup plus de gens et pourrait résoudre ce problème plus tôt à la place?

Bon travail! C'est vraiment bien d'avoir une idée de la couverture et les rapports nous le donnent enfin. En effet, cela montre clairement que nous avons besoin de beaucoup plus de tests unitaires, mais toutes les méthodes pour lesquelles nous avons récemment ajouté des tests unitaires sont en effet présentées comme couvertes dans le rapport, donc cela semble parfaitement bien.

Je me demande s'il serait possible d'exécuter la couverture sur les fichiers source au lieu des fichiers construits. Cela facilite la compréhension, car maintenant sur http://pdfjscoveragereport.bitballoon.com/lib/display/metadata.js.html, je vois que la ligne 28 n'est pas couverte alors que ce n'est pas notre code, mais plutôt du code généré automatiquement. Si cela s'avère difficile, nous pouvons simplement faire l'approche actuelle en tant que première version et le faire dans un numéro de suivi.

Alors dois-je générer un PR car il attirera l'attention de beaucoup plus de gens et pourrait résoudre ce problème plus tôt à la place?

Oui, c'est une bonne idée. Nous pouvons alors démarrer le processus d'examen et voir quels problèmes il reste à résoudre.

C'est vraiment bien d'avoir une idée de la couverture et les rapports nous le donnent enfin. En effet, cela montre clairement que nous avons besoin de beaucoup plus de tests unitaires, mais toutes les méthodes pour lesquelles nous avons récemment ajouté des tests unitaires sont en effet présentées comme couvertes dans le rapport, donc cela semble parfaitement bien.

Bien qu'il soit certainement vrai que nous pourrions faire beaucoup plus de tests unitaires, il y a de grandes portions de la base de code qui n'obtiendront probablement jamais une couverture de test assez "bonne" juste à partir des seuls tests unitaires.

Comme mentionné dans https://github.com/mozilla/pdf.js/issues/8632#issue -241690851, il y a quelques suites de tests différentes, et à moins que je ne me trompe, obtenir des résultats de couverture de gulp browsertest également serait presque essentiel de vraiment savoir à quoi ressemble notre couverture de test réelle.

@Snuffleupagus @timvandermeij

Ce matin, j'ai beaucoup essayé de trouver des rapports de couverture dans tous les dossiers individuellement en utilisant l'instruction cd build && cd lib && istanbul cover --include-all-sources jasmine-node test , en changeant différents répertoires en utilisant cd <directory name> et en testant en utilisant jasmine-node <directory names and js files> mais en vain.

Bien que les rapports de tests soient générés parfois (pas toujours), cela se produit à cause d'un ou deux fichiers js au format ES6 se trouvant dans les répertoires spécifiques (ce qui n'apporte que <2 à 3% des rapports de couverture). Malheureusement, tout fichier js contenant le import or export statements renvoie une erreur dans ce format.

Transformation error for /home/shikhar/Desktop/mozillaPdfJs/pdf.js/src/core/arithmetic_decoder.js ; return original code 'import' and 'export' may appear only with 'sourceType: "module"' (183:0) Unable to post-instrument: /home/shikhar/Desktop/mozillaPdfJs/pdf.js/src/core/arithmetic_decoder.js

Et avec cette erreur, le fichier n'est pas du tout vérifié pour la couverture et renvoie donc un rapport de 0%.

Je me demande s'il serait possible d'exécuter la couverture sur les fichiers source au lieu des fichiers construits.

Encore une fois, le dossier source contient des fichiers qui ont des instructions d'importation et d'exportation et, par conséquent, les erreurs ci-dessus se produisent en raison desquelles les fichiers associés ne sont pas vérifiés du tout, conduisant à une couverture de 0%.

Ainsi, il est impératif que nous testions dans le dossier de construction lui-même.

obtenir les résultats de la couverture de gulp browserest également serait presque essentiel pour vraiment savoir à quoi ressemble notre couverture de test réelle.

@Snuffleupagus Où se situent ces tests spécifiques? Nous pouvons essayer de les tester directement en utilisant l'instruction jasmine-node mentionnée ci-dessus.

Si cela s'avère difficile, nous pouvons simplement faire l'approche actuelle en tant que première version et le faire dans un numéro de suivi.

Oui, nous pourrions plutôt faire ça.

Oui, c'est une bonne idée. Nous pouvons alors démarrer le processus d'examen et voir quels problèmes il reste à résoudre.

Bien sûr, je vais commencer par ça.

Le PR au # 9308 a montré un exemple de couverture de test pour les tests unitaires uniquement. Les rapports générés offrent peu de valeur car notre ensemble de tests unitaires est très petit. Pour plus de détails, voir https://github.com/mozilla/pdf.js/pull/9308#issuecomment -353588039

Donc, pour obtenir des tests de navigateur, nous avons besoin de:

1. Un moyen de générer des données de couverture.
2. Un moyen de récupérer les données de couverture (et de les télécharger sur une combinaison).

À l'adresse 1), gulpfile.js doit être édité pour ajouter éventuellement une instrumentation de code, qui est exportée vers l'objet window.__coverage__ dans un navigateur. gulp-istanbul pourrait être utile. La documentation semble clairsemée, mais j'ai trouvé un exemple sur https://stackoverflow.com/questions/38208735/no-window-coverage-object-is-created-by-istanbul-phantomjs. Nous n'utilisons PAS PhantomJS, mais vous pouvez lire la question, la réponse et l'article de blog lié pour approfondir votre compréhension de la façon dont tout fonctionne.

Après avoir terminé l'étape 1, les tests du navigateur auront une variable window.__coverage__ (ou tout ce que vous avez mis dans le paramètre de configuration coverageVariable ). Pour obtenir des rapports de couverture:

1. Modifiez le lanceur de test (https://github.com/mozilla/pdf.js/blob/e081a708c36cb2aacff7889048863723fcf23671/test/driver.js) pour publier le résultat de la couverture avec XMLHttpRequest sur le serveur de test.
2. Dans le serveur de test (https://github.com/mozilla/pdf.js/blob/e081a708c36cb2aacff7889048863723fcf23671/test/test.js), enregistrez un nouveau hook pour recevoir les résultats du test, et écrivez-le dans un fichier en utilisant fs Node.js API (peut-être après un post-traitement, comme la conversion au format lcov si nécessaire).
3. Téléchargez le rapport sur les combinaisons (par exemple avec la commande «combinaisons» comme indiqué dans # 9308).

@ Rob - W Merci pour cet examen détaillé. Je vais faire un suivi et revenir dès que possible.

Ce commentaire offre des conseils pour la mise en œuvre et répond aux questions de https://github.com/mozilla/pdf.js/pull/9308#issuecomment -353710595

istanbul n'ajoute que l'instrumentation au code. Cette entrée est censée être du code exécutable, car «instrumentation» signifie ajouter du code JavaScript supplémentaire qui détecte le moment où l'exécution passe par cette ligne, cette instruction, etc.

Cette instrumentation peut être effectuée à la volée pendant l'exécution du programme (par exemple, lorsque vous exécutez istanbul cover partir de la ligne de commande, istanbul interceptera les appels aux require de Node.js et transformer le code avec instrumentation avant le chargement du module ), ou séparément de l'exécution (par exemple comme le montre le billet de blog: le code instrumenté est généré en ligne de commande, l'exécution se fait dans le navigateur).

Dans votre PR actuel au # 9308, vous invoquez istanbul cover avec jasmine comme programme à exécuter. Comme je l'ai mentionné précédemment, l'effet est similaire à l'exécution de gulp unittestcli - c'est-à-dire que les tests sont exécutés sur une bibliothèque pré-construite dans le répertoire build/lib (cela est configuré dans test/unit/clitests.json ) . Cela explique pourquoi votre rapport de couverture affiche 0 couverture pour tout sauf pour build/lib/ (car les seuls modules require -d (Node.js) sont en build/lib et build/streams/ - voir la fin de la définition de tâche gulp unittestcli ).

Pour obtenir des rapports de couverture istanbul dans le pipeline de construction, de sorte que lorsque le code est transpilé depuis ES6, l'instrumentation est ajoutée. Après cela, il devient plus difficile de générer des rapports par module (mais ce n'est pas impossible, en théorie, les cartes source fournissent suffisamment d'informations pour mapper les données sur les fichiers d'origine).
C'est un défi, et nécessite une bonne compréhension de la façon d'utiliser Babel, gulp, istanbul et les cartes / modules source (j'ai déjà fait référence aux endroits pertinents dans le code source où PDF.js rassemble tous les modules pour générer le PDF.js bibliothèque - voir # 8632). Cette connaissance est très utile, donc si vous n'avez pas peur des défis, vous pouvez l'explorer sous ma direction.

Mais avant de plonger aussi profondément, commençons par quelque chose de plus simple: obtenir des rapports de couverture depuis le navigateur. Nous avons deux façons d'exécuter des tests dans le navigateur, unittest et browsertest . Puisque nous avons déjà un moyen assez simple d'exécuter des tests unitaires dans Node.js, concentrons-nous sur browsertest . Les tests du navigateur n'utilisent pas de modules individuels, mais la bibliothèque PDF.js créée par la cible generic gulp , dans GENERIC_DIR , alias build/generic/ . Il suffit donc d'ajouter une instrumentation de code à build/generic . Je suggère de prendre build/generic/ comme répertoire d'entrée et d'écrire le résultat dans coverage/build/generic .

Après cela, vous devez changer test/test_slave.html pour ne pas charger inconditionnellement ../build/generic/build/pdf.js dans une balise <script> , mais charger conditionnellement soit ../build/generic/build/pdf.js ou ../coverage/build/generic/build/pdf.js fonction de certains paramètres de configuration (pour le test, vous pouvez simplement coder en dur la dernière URL, il est très facile de modifier ce paramètre codé en dur plus tard après avoir terminé la tâche plus difficile de renvoyer le rapport de couverture au serveur de test) .

Une fois que vous avez remplacé la bibliothèque normale pdf.js bibliothèque instrumentée pdf.js, les statistiques de couverture seront générées en tant que test. Le résultat est stocké dans la variable globale window.__coverage__ . Lorsque le pilote de test dans le navigateur se termine ( la méthode _quit dans test / driver.js ), vous pouvez sérialiser ce rapport (par exemple en utilisant JSON.stringify(window.__coverage__) ) et l'envoyer au serveur avec XMLHttpRequest (voir les autres emplacements dans le fichier driver.js pour des exemples - assurez-vous d'envoyer le rapport au serveur AVANT d'envoyer le message /tellMeToQuit , sinon le rapport de couverture risque de ne pas être transmis correctement).
Vous pouvez ajouter un nouveau gestionnaire pour votre nouvel appel d'API personnalisé dans https://github.com/mozilla/pdf.js/blob/ba5dbc96326518ad716158ef040f61794cc72202/test/test.js . Pour des exemples de code, regardez les appels XMLHttpRequest dans driver.js (comme le message /tellMeToQuit ), et trouvez le gestionnaire correspondant dans test.js . Une fois que vous avez reçu le JSON sérialisé côté serveur, utilisez l'API fs.writeFileSync pour écrire le rapport de couverture dans un fichier (encore une fois, il y a d'autres exemples dans test.js qui montrent comment vous pouvez écrire des fichiers) .

@ Rob - W Je ne suis actuellement pas disponible avant la nouvelle année ... Je vais bien comprendre après ça

Après cela, vous devez modifier test / test_slave.html pour ne pas charger inconditionnellement ../build/generic/build/pdf.js dans un

Après cela, vous devez modifier test / test_slave.html pour ne pas charger inconditionnellement ../build/generic/build/pdf.js dans un

@ Rob - WI a réussi à créer un paramètre similaire dans le tests.js (en imitant le paramètre testFilter), cependant, l'incorporer dans le test/test_slave.html est toujours un problème pour moi. Pour le reste des changements, veuillez visiter à nouveau le PR, j'ai poussé de nouveaux commits. # 9308

Aussi, si vous pouviez me fournir des liens pour rejoindre le canal IRC ou slack / gitter / mailing list spécifique à pdf.js.

@ Rob - W Le problème est-il toujours en place? Si oui, j'aimerais y travailler.
Je vous remercie.

La première tentative pour cela se trouve dans # 9308, vous pouvez donc vous en inspirer. Concentrons-nous sur la mise en œuvre d'une version minimale, c'est-à-dire une version qui ne fonctionne que localement. Cela n'a pas à fonctionner sur les bots ou Travis CI; si nous pouvons faire des rapports de couverture localement c'est déjà très important. Pour localement, il serait bon de créer une commande appelée gulp coverage qui exécute des tests unitaires instrumentés et génère un rapport de couverture basé sur cela. Cela fonctionne et fusionne, nous pouvons toujours répéter là-dessus.

@timvandermeij est-il toujours actif? Je peux aussi essayer

Oui, n'hésitez pas à y travailler! Nous devrions commencer simple; voir https://github.com/mozilla/pdf.js/issues/8632#issuecomment -455868037 pour une approche possible.

@timvandermeij me demande si je peux gulp ?

Je ne connais pas trop bien gulp mais je suis prêt à savoir si c'est une exigence pour cela

Je ne pense pas que quiconque travaille là-dessus, alors allez-y! Il est important de rester simple pour le patch initial. Puisque nous utilisons Gulp comme outil principal, il est préférable de l'utiliser, mais nous sommes également ouverts à d'autres suggestions. Reportez-vous à https://github.com/mozilla/pdf.js/issues/8632#issuecomment -455868037 pour des idées de mise en œuvre. Cela ne nécessite pas beaucoup d'expérience avec Gulp car Gulp est un exécuteur de tâches assez simple, c'est-à-dire qu'il enveloppe principalement tout ce que vous feriez également dans un script NPM. Jetez un œil au Gulpfile pour vous inspirer.

J'aimerais travailler là-dessus. Le problème est-il toujours ouvert? Et où puis-je mieux comprendre le bogue?

@jezhou y travaillait et a fait quelques progrès dans # 11580. Le PR n'a cependant pas été mis à jour récemment.

Merci beaucoup pour la mise à jour. Je pense que je peux commencer à travailler dessus? Où
puis-je obtenir plus d'informations? À propos du problème et du reste ??

Le samedi 16 mai 2020, 17 h 56, Rob Wu, [email protected], a écrit:

@jezhou https://github.com/jezhou travaillait là-dessus et en a fait
progrès dans # 11580 https://github.com/mozilla/pdf.js/pull/11580 . Le PR
n'a pas été mis à jour récemment.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/mozilla/pdf.js/issues/8632#issuecomment-629637879 ,
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AKUZ65CGSIZF6OMFZWENWF3RR2A77ANCNFSM4DSK7SGQ
.