Pdf.js: Generar (probar) estadísticas de cobertura

unittestcli: ejecuta algunas pruebas unitarias de PDF.js en Node.js (con cambios mínimos de fuente, solo con transpilación con babel).
browsertest: ejecuta pruebas en los navegadores (probamos Chrome y Firefox). Esto se basa en el binario creado por el destino de compilación generic , que usa código transpilado con babel y luego incluido con el paquete web.

Tenga en cuenta que si bien browsertest ejecutará las pruebas de referencia , también existe el comando unittest que ejecuta el conjunto completo de pruebas unitarias en los navegadores (a diferencia de unittestcli que solo ejecuta un subconjunto de las pruebas unitarias existentes).

Además, tenga en cuenta que el paso de "transpilación con Babel" se puede omitir, si el indicador de compilación PDFJS_NEXT está establecido (como otros indicadores de compilación en gulpfile.js , o como un argumento de línea de comandos). Si bien el código todavía está incluido con Webpack, al menos es posible evitar el paso de transpilación.

@ Rob - WI quisiera trabajar en esto

¡Es tuyo! Háganos saber (preferiblemente en IRC) si tiene preguntas.

@timvandermeij Estoy pensando en usar la herramienta Karma. Funciona con el motor de cobertura de código de Estambul. Se pueden verificar las estadísticas para la ejecución de las pruebas, se pueden hacer informes HTML a partir de ella. ¿Es una buena manera de comenzar?

Usando Karma obtuve informes de prueba https://drive.google.com/file/d/0ByddvU1PKkWaWEZTWHFYT0Y0aTg/view?usp=sharing
pero las estadísticas de cobertura de prueba no se muestran https://drive.google.com/file/d/0ByddvU1PKkWaS1ZiT1dobU1DQUk/view?usp=sharing

@ Divya063 ¿Podrías compartir tu código, por ejemplo,

¿Y qué versión de Node.js estás usando?

Gracias por la respuesta, la versión de Node es 6.11.1. Aquí está el enlace a la sucursal https://github.com/Divya063/pdf.js/tree/dev

Los errores son:

Firefox 43.0.0
SyntaxError: las declaraciones de importación solo pueden aparecer en el nivel superior
Chrome 60.0.3112
Error de sintaxis no detectado: importación de token inesperada

Esto indica que el código no se transpila antes de su uso. Actualmente, el soporte integrado para módulos ES no está habilitado de forma predeterminada en ningún navegador ( más información ), por lo que el código debe transpilarse primero.

He editado mi publicación inicial para señalar dónde está configurada la transpilación en el sistema de compilación de PDF.js. Quizás puedas intentar usar un complemento existente para integrar istanbul y babel. Una búsqueda rápida muestra https://github.com/istanbuljs/babel-plugin-istanbul , pero también puede haber otras opciones.

(y la versión estable actual de Firefox es 55. Estaba probando con Firefox 43, que es antiguo y no es compatible. Le sugiero que actualice a una versión reciente de Firefox antes de volver a probar)

@ Rob - W Gracias por indicar los errores. Pronto actualizaré los resultados.

@ Rob - WI transpiló el código usando karma-browserify y actualizó la versión de Firefox, pero todavía aparecen muchos errores. Aquí está el enlace de la rama https://github.com/Divya063/pdf.js/tree / dev

¿Puedes compartir los mensajes de error?

Y si es posible, intente usar webpack en lugar de browserify, porque webpack es lo que ya usamos. Hacerlo nos permite instrumentar el código que realmente se usa en el navegador.

Y también veo que está registrando .idea y otros archivos de proyecto / IDE específicos del usuario. Cuando contribuye a un proyecto existente, es mejor no agregar archivos no relacionados al proyecto, ya que satura el repositorio y causa conflictos de fusión. En la solicitud de extracción final, estos archivos no deben incluirse.

¿Sigue presente este problema? Si es así, me gustaría trabajar en ello.

Sí, siéntete libre de trabajar en esto.

@timvandermeij
Estaba trabajando en esto. He usado Estambul para cubrir mis pruebas y overoles para mostrar los informes. He realizado los cambios necesarios necesarios donde sea necesario. Sin embargo, siempre que corro overoles usando

npm run coveralls

Obtuve el siguiente error

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

Intenté buscar esto aquí y aquí, pero fue en vano. ¿Alguna ayuda sobre cuál podría ser el problema?

Es difícil saberlo sin ver el código. ¿Podrías enviar el código a una sucursal para que los colaboradores aquí puedan mirar contigo?

@timvandermeij aquí está. Ignore el archivo de gemas. ya lo he eliminado.

Cualquier comentario @timvandermeij

Por un poco de búsqueda en Google, parece que este error significa que coveralls no está obteniendo datos en el formato lcov . Puede comprobar si los comandos individuales en npm run cover -- --report lcovonly && cat ./coverage/lcov.info | coveralls de hecho devuelven los resultados que espera.

@timvandermeij
El principal problema actualmente es esta declaración.
No coverage information was collected, exit without writing coverage information
Debido a esto, el archivo lcov en todo momento permanece en blanco y esto sucede

[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'

Al buscar en Google, parece que estos son errores muy comunes. y el error radica básicamente en Estambul. Intenté cambiar entre diferentes versiones del mismo, pero el error siguió ocurriendo. Sin embargo, en todos los lugares, las pruebas se han realizado con moka y no con lint o unittest, etc. y, por lo tanto, la mayoría (casi) de las resoluciones también son solo para mocha. Estas fueron algunas de las fuentes que busqué

https://github.com/gotwarlost/istanbul/issues/262
https://github.com/coryhouse/react-slingshot/issues/245
https://github.com/gotwarlost/istanbul/issues/496
y varios otros también, pero ninguno de ellos ayudó realmente :(

La compilación se pasa a travis ( https://travis-ci.org/shikhar-scs/pdf.js/jobs/318422621 ) pero nuevamente no se genera la cobertura.

No estoy muy seguro de por qué está pasando eso, pero también encuentro a mucha gente que lo hizo con éxito con Jasmine, así que debe ser posible. ¿Podría intentarlo si https://bryce.fisher-fleig.org/blog/setting-up-istanbul-with-jasmine/index.html funciona para usted? Primero, pruebe esos pasos exactos para ver si funciona de forma independiente, y luego intente integrarlo en PDF.js.

@timvandermeij en eso
Por fin se están generando informes de cobertura. Sin embargo, necesito transpilar y luego probar porque muestra problemas con las declaraciones de importación y exportación
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)
Este error aparece con todos y cada uno de los archivos js y trabajaré en él y presentaré un PR pronto.

@timvandermeij

Aquí están: la construcción pasando y pidiendo cobertura .

Los informes de cobertura

Sin embargo, como existen las declaraciones de importación y exportación, incluso después de llegar a esos archivos, no se han probado completamente y, por lo tanto, estamos obteniendo informes de cobertura del 0%. Hasta donde yo sé, necesito babelificar estos archivos a ES6 antes de la prueba de jazmín y eso está demostrando ser un problema. ¿Cómo proporciono el código ES6 a jasmine?
¿Puedo realizar cambios en el archivo gulp como se menciona aquí http://jpsierens.com/use-es6-right-now/ ?

De hecho, te estás acercando a la solución. Según los informes de cobertura, parece que ejecuta la cobertura en los archivos lib , que ya deberían transpilarse a ES6 (consulte https://github.com/mozilla/pdf.js/blob/6ac9e1c5ed0d5f067872b8482724c171c79566b2/gulpfile. js # L965 y https://github.com/mozilla/pdf.js/blob/6ac9e1c5ed0d5f067872b8482724c171c79566b2/gulpfile.js#L985). ¿O el problema es que las pruebas unitarias en sí mismas no se transpilan? No estoy realmente familiarizado con cómo funciona eso exactamente, pero si ese es el caso, es posible que sean necesarios algunos cambios en el Gulpfile para las pruebas unitarias.

@timvandermeij

¿O el problema es que las pruebas unitarias en sí mismas no se transpilan? No estoy realmente familiarizado con cómo funciona eso exactamente, pero si ese es el caso, es posible que sean necesarios algunos cambios en el Gulpfile para las pruebas unitarias.

El problema era que estaba ejecutando las pruebas en la carpeta incorrecta. build>lib carpeta
Otro problema fue la declaración --report lcovonly . Mágicamente (realmente no sé por qué) cuando quité esta parte de la línea de overoles, comenzaron a generarse informes. Tal vez debería haber prestado más atención a

Puede comprobar si los comandos individuales en npm run cubren - --report lcovonly && cat ./coverage/lcov.info | de hecho, los overoles devuelven los resultados esperados.

Gracias por señalar esto.

Finalmente, podemos generar informes: tada: y aunque se ven un poco tristes, leer los archivos exactos le dará la razón por la cual:

1. Todas las declaraciones condicionales no ejecutadas se cuentan como 'no cubiertas'.
2. Todas las instrucciones de asignación no ejecutadas también se cuentan como 'no cubiertas'.

Obviamente, no he subido los informes generados por mí mismo, pero los he alojado en un enlace aquí http://pdfjscoveragereport.bitballoon.com . Visite estos enlaces y obtendrá el informe exacto esperado.

Sin embargo, estos resultados no se reflejan en coveralls.io : cry: No sé por qué. Además, he notado que incluso después de comprometer varias veces, coveralls todavía está construyendo mi proyecto en función de una confirmación muy antigua y no en una reciente debido a la cobertura que se genera allí, aunque se genera, pero siempre permanece 0 ( aunque no sea 0 ahora). Por favor, ayúdame a resolver eso.

Pero aún así npm run coveralls dará todos los informes de cobertura en este formato que se encuentran en la carpeta build/lib/coverage/lcov-report .

Espero que todo esto ayude finalmente, sin embargo, nuestro último problema es mostrar estos informes de alguna manera en monos.

Este es el enlace de mi última versión. https://travis-ci.org/shikhar-scs/pdf.js
Este es el enlace de mi última confirmación .

Aparte de que los informes no se generan en coveralls.io, supongo que todo está bien. Entonces, ¿debo generar un PR, ya que atraerá la atención de muchas más personas y podría resolver este problema antes?

¡Buen trabajo! Es realmente bueno tener una idea de la cobertura y los informes finalmente nos lo dan. De hecho, muestra claramente que necesitamos muchas más pruebas unitarias, pero todos los métodos para los que recientemente agregamos pruebas unitarias se muestran como cubiertos en el informe, por lo que se ve perfectamente bien.

Me pregunto si sería posible ejecutar la cobertura sobre los archivos fuente en lugar de los archivos construidos. Eso hace que sea más fácil de entender, porque ahora en http://pdfjscoveragereport.bitballoon.com/lib/display/metadata.js.html veo que la línea 28 no está cubierta mientras que ese no es nuestro código, sino un código generado automáticamente. Si resulta ser difícil, podemos simplemente hacer el enfoque actual como una primera versión y hacerlo en un número de seguimiento.

Entonces, ¿debo generar un PR, ya que atraerá la atención de muchas más personas y podría resolver este problema antes?

Si esa es una buena idea. Luego, podemos comenzar el proceso de revisión y ver qué problemas quedan por abordar.

Es realmente bueno tener una idea de la cobertura y los informes finalmente nos lo dan. De hecho, muestra claramente que necesitamos muchas más pruebas unitarias, pero todos los métodos para los que recientemente agregamos pruebas unitarias se muestran como cubiertos en el informe, por lo que se ve perfectamente bien.

Si bien es cierto que nos vendría bien muchas más pruebas unitarias, hay grandes porciones de la base de código que probablemente nunca llegarán a una cobertura de pruebas suficientemente "buena" solo con las pruebas unitarias, lamentablemente.

Como se menciona en https://github.com/mozilla/pdf.js/issues/8632#issue -241690851, hay algunos conjuntos de pruebas diferentes y, a menos que me equivoque, también obtengo resultados de cobertura de gulp browsertest Sería casi esencial saber realmente cómo es nuestra cobertura de prueba real.

@Snuffleupagus @timvandermeij

Esta mañana intenté extensamente encontrar informes de cobertura en todas las carpetas individualmente usando la declaración cd build && cd lib && istanbul cover --include-all-sources jasmine-node test , cambiando diferentes directorios usando cd <directory name> y probando usando jasmine-node <directory names and js files> pero en vano.

Aunque el informe de pruebas se genera a veces (no siempre), esto sucede debido a que uno o dos archivos js en formato ES6 se encuentran en directorios específicos (que solo generan <2 ~ 3% de los informes de cobertura). Lamentablemente, cualquier archivo js que contenga import or export statements devuelve un error en este formato.

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

Y con este error, no se comprueba la cobertura del archivo y, por lo tanto, devuelve un informe del 0%.

Me pregunto si sería posible ejecutar la cobertura sobre los archivos fuente en lugar de los archivos construidos.

Nuevamente, la carpeta de origen contiene archivos que tienen declaraciones de importación y exportación y, por lo tanto, los errores anteriores ocurren debido a los cuales los archivos relacionados no se verifican en absoluto, lo que genera una cobertura del 0%.

Por lo tanto, es imperativo que probemos en la propia carpeta de compilación.

Obtener resultados de cobertura de gulp browsertest también sería casi esencial para saber realmente cómo se ve nuestra cobertura de prueba real.

@Snuffleupagus ¿Dónde se encuentran estas pruebas específicas? Podemos intentar probarlos directamente usando la declaración de nodo de jazmín mencionada anteriormente.

Si resulta ser difícil, podemos simplemente hacer el enfoque actual como una primera versión y hacerlo en un número de seguimiento.

Sí, podríamos hacer eso.

Si esa es una buena idea. Luego, podemos comenzar el proceso de revisión y ver qué problemas quedan por abordar.

Seguro, empezaré con eso.

El PR en # 9308 ha mostrado un ejemplo de cobertura de prueba solo para las pruebas unitarias. Los informes generados proporcionan poco valor porque nuestro conjunto de pruebas unitarias es muy pequeño. Para obtener más detalles, consulte https://github.com/mozilla/pdf.js/pull/9308#issuecomment -353588039

Entonces, para obtener las pruebas del navegador, necesitamos:

1. Una forma de generar datos de cobertura.
2. Una forma de recuperar los datos de cobertura (y cargarlos en overoles).

Para la dirección 1), gulpfile.js debe editarse para agregar opcionalmente instrumentación de código, que se exporta al objeto window.__coverage__ en un navegador. gulp-istanbul podría ser útil. La documentación parece escasa, pero encontré un ejemplo en https://stackoverflow.com/questions/38208735/no-window-coverage-object-is-created-by-istanbul-phantomjs. NO utilizamos PhantomJS, pero puede leer la pregunta, la respuesta y la publicación del blog vinculada para profundizar su comprensión de cómo funciona todo.

Después de finalizar el paso 1, las pruebas del navegador tendrán una variable window.__coverage__ (o lo que haya puesto en el parámetro de configuración coverageVariable ). Para obtener informes de cobertura:

1. Modifique el corredor de prueba (https://github.com/mozilla/pdf.js/blob/e081a708c36cb2aacff7889048863723fcf23671/test/driver.js) para publicar el resultado de cobertura con XMLHttpRequest en el servidor de prueba.
2. En el servidor de prueba (https://github.com/mozilla/pdf.js/blob/e081a708c36cb2aacff7889048863723fcf23671/test/test.js), registre un nuevo gancho para recibir los resultados de la prueba y escríbalo en un archivo usando fs API
3. Cargue el informe en los overoles (por ejemplo, con el comando "overoles" como se muestra en # 9308).

@ Rob - W Gracias por una revisión tan detallada. Haré un seguimiento y volveré lo antes posible.

Este comentario ofrece consejos para la implementación y aborda las preguntas de https://github.com/mozilla/pdf.js/pull/9308#issuecomment -353710595

istanbul solo agrega instrumentación al código. Se supone que esta entrada es código ejecutable, porque "instrumentación" significa agregar código JavaScript adicional que detecta cuando la ejecución pasa a través de esa línea, declaración, etc. Si el código se modifica significativamente nuevamente después de agregar la instrumentación, el informe de cobertura resultante pierde sentido.

Esta instrumentación se puede realizar sobre la marcha mientras se ejecuta el programa (por ejemplo, cuando ejecuta istanbul cover desde la línea de comandos, istanbul interceptará las llamadas a require Node.js y transformar el código con instrumentación antes de que se cargue el módulo ), o por separado de la ejecución (por ejemplo, como demuestra la publicación del blog: el código instrumentado se genera en la línea de comandos, la ejecución se realiza en el navegador).

En su RP actual en # 9308, está invocando istanbul cover con jasmine como programa a ejecutar. Como mencioné antes, el efecto es similar a ejecutar gulp unittestcli , es decir, las pruebas se ejecutan en una biblioteca preconstruida en el directorio build/lib (esto está configurado en test/unit/clitests.json ) . Esto explica por qué su informe de cobertura muestra 0 cobertura para todo excepto build/lib/ (porque los únicos módulos require -d (Node.js) están en build/lib y build/streams/ - ver el final de la definición de la tarea gulp unittestcli ).

Para obtener informes de cobertura útiles , los informes de cobertura son preferiblemente a nivel de módulo. Este es un paso adelante: debe integrar istanbul en la canalización de compilación, de modo que cuando el código se transpile de ES6, se agregue la instrumentación. Después de eso, se vuelve más difícil generar informes por módulo (pero no imposible, en teoría, los mapas de origen brindan suficiente información para asignar datos a los archivos originales).
Esto es un desafío y requiere una buena comprensión de cómo usar Babel, gulp, istanbul y mapas / módulos fuente (ya me referí a los lugares relevantes en el código fuente donde PDF.js reúne todos los módulos para generar PDF.js biblioteca - vea # 8632). Este conocimiento es muy útil, por lo que si no le temen a los desafíos, puede explorarlo bajo mi guía.

Pero antes de profundizar tanto, comencemos con algo más simple: obtener informes de cobertura desde el navegador. Tenemos dos formas de ejecutar pruebas en el navegador, unittest y browsertest . Como ya tenemos una forma bastante fácil de ejecutar pruebas unitarias en Node.js, centrémonos en browsertest . Las pruebas del navegador no usan módulos individuales, sino la biblioteca PDF.js creada por el objetivo generic gulp , en GENERIC_DIR , también conocido como build/generic/ . Por lo tanto, basta con agregar instrumentación de código a build/generic . Sugiero tomar build/generic/ como directorio de entrada y escribir el resultado en coverage/build/generic .

Después de hacer eso, debe cambiar test/test_slave.html para no cargar incondicionalmente ../build/generic/build/pdf.js en una etiqueta <script> , sino cargar condicionalmente ../build/generic/build/pdf.js o ../coverage/build/generic/build/pdf.js dependiendo de algún parámetro de configuración (para las pruebas, puede codificar la última URL, es muy fácil cambiar este parámetro codificado más tarde, después de haber completado la tarea más difícil de enviar el informe de cobertura al servidor de prueba) .

Una vez que haya reemplazado la biblioteca pdf.js normal con la biblioteca pdf.js instrumentada, las estadísticas de cobertura se generarán como ejecución de prueba. El resultado se almacena en la variable window.__coverage__ global. Cuando finaliza el controlador de prueba en el navegador ( el método _quit en test / driver.js ), puede serializar este informe (por ejemplo, usando JSON.stringify(window.__coverage__) ) y enviarlo al servidor con XMLHttpRequest (vea las otras ubicaciones en el archivo driver.js para ver ejemplos; asegúrese de enviar el informe al servidor ANTES de enviar el mensaje /tellMeToQuit , de lo contrario, es posible que el informe de cobertura no se transmita correctamente).
Puede agregar un nuevo controlador para su nueva llamada de API personalizada en https://github.com/mozilla/pdf.js/blob/ba5dbc96326518ad716158ef040f61794cc72202/test/test.js . Para ejemplos de código, mire las llamadas XMLHttpRequest en driver.js (como el mensaje /tellMeToQuit ) y busque el controlador correspondiente en test.js . Una vez que haya recibido el JSON serializado en el lado del servidor, use la API fs.writeFileSync para escribir el informe de cobertura en un archivo (nuevamente hay otros ejemplos en test.js que muestran cómo puede escribir archivos) .

@ Rob - W Actualmente no estoy disponible hasta el año nuevo ... Seguro que lo entenderé después de eso

Después de hacer eso, debe cambiar test / test_slave.html para no cargar incondicionalmente ../build/generic/build/pdf.js en un

Después de hacer eso, debe cambiar test / test_slave.html para no cargar incondicionalmente ../build/generic/build/pdf.js en un

@ Rob - WI logró crear un parámetro similar en el tests.js (imitando el parámetro testFilter), sin embargo, incorporarlo en el test/test_slave.html sigue siendo un problema para mí. Para el resto de los cambios, visite el PR nuevamente, he enviado nuevas confirmaciones. # 9308

Además, si pudiera proporcionarme enlaces para unirse al canal de IRC o la lista de correo slack / gitter / mailing específico de pdf.js.

@ Rob - W ¿Sigue el problema? Si es así, me gustaría trabajar en ello.
Gracias.

El primer intento para esto está en el n. ° 9308, por lo que puede usarlo como inspiración. Centrémonos en conseguir que funcione una versión mínima, es decir, una que solo funcione localmente. No tiene que funcionar en los bots o Travis CI; si podemos hacer informes de cobertura a nivel local, eso ya es muy significativo. Para localmente, sería bueno crear un comando llamado gulp coverage que ejecute pruebas unitarias instrumentadas y genere un informe de cobertura basado en eso. Si funciona y se fusiona, siempre podemos iterar sobre eso.

@timvandermeij ¿todavía está activo? También puedo intentarlo

Sí, ¡siéntete libre de trabajar en esto! Deberíamos empezar de forma sencilla; consulte https://github.com/mozilla/pdf.js/issues/8632#issuecomment -455868037 para conocer un posible enfoque.

@timvandermeij preguntándose si puedo darle una oportunidad a esto? Una pregunta más importante que tengo es si es posible usar un script npm para generar el informe en su lugar, o si tiene que ser una tarea gulp .

No estoy muy familiarizado con gulp pero estoy dispuesto a saber si ese es un requisito para esto.

No creo que nadie esté trabajando en esto, ¡así que adelante! Es importante que sea sencillo para el parche inicial. Dado que usamos Gulp como nuestra herramienta principal, es preferible usar eso, pero también estamos abiertos a otras sugerencias. Consulte https://github.com/mozilla/pdf.js/issues/8632#issuecomment -455868037 para obtener ideas de implementación. Sin embargo, no requiere mucha experiencia con Gulp porque Gulp es un corredor de tareas bastante simple, es decir, en su mayoría envuelve cualquier cosa que también haría en un script NPM. Eche un vistazo al Gulpfile para inspirarse.

Me gustaría trabajar en esto. ¿El problema sigue abierto? ¿Y dónde puedo comprender mejor el error?

@jezhou estaba trabajando en esto y ha logrado algunos avances en el # 11580. Sin embargo, el PR no se ha actualizado recientemente.

Muchas gracias por la actualización. ¿Creo que puedo empezar a trabajar en eso? Dónde
¿puedo obtener más información? ¿Sobre el tema y el resto?

El sábado 16 de mayo de 2020 a las 5:56 pm, Rob Wu, [email protected] escribió:

@jezhou https://github.com/jezhou estaba trabajando en esto y ha hecho algunos
progreso en # 11580 https://github.com/mozilla/pdf.js/pull/11580 . El pr
Sin embargo, no se ha actualizado recientemente.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/mozilla/pdf.js/issues/8632#issuecomment-629637879 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AKUZ65CGSIZF6OMFZWENWF3RR2A77ANCNFSM4DSK7SGQ
.