Pdf.js: Gerar (testar) estatísticas de cobertura

unittestcli - executa alguns testes de unidade de PDF.js em Node.js (com mudanças mínimas de origem, apenas com transpilação com babel).
browsertest - Executa testes em navegadores (testamos Chrome e Firefox). Isso se baseia no binário criado pelo destino de construção generic , que usa o código transpilado com o babel e depois empacotado com o webpack.

Observe que, embora browsertest execute os testes de referência , há também o comando unittest que executa o conjunto completo de testes de unidade em navegadores (ao contrário de unittestcli que executa apenas um subconjunto dos testes de unidade existentes).

Além disso, observe que a etapa de "transpilação com Babel" pode ser ignorada, se o sinalizador de construção PDFJS_NEXT estiver definido (como outros sinalizadores de construção em gulpfile.js , ou como um argumento de linha de comando). Embora o código ainda esteja empacotado com o Webpack, pelo menos é possível evitar a etapa de transpilação.

@ Rob - W eu gostaria de trabalhar nisso

É seu! Informe-nos (de preferência no IRC) se tiver dúvidas.

@timvandermeij Estou pensando em usar a ferramenta Karma. Funciona com o mecanismo de cobertura de código de Istambul. As estatísticas podem ser verificadas para a execução dos testes, relatórios em HTML podem ser feitos a partir dela. É uma boa maneira de começar?

Usando Karma, recebi relatórios de teste https://drive.google.com/file/d/0ByddvU1PKkWaWEZTWHFYT0Y0aTg/view?usp=sharing
mas as estatísticas de cobertura de teste não estão sendo mostradas https://drive.google.com/file/d/0ByddvU1PKkWaS1ZiT1dobU1DQUk/view?usp=sharing

@ Divya063 Você poderia compartilhar seu código, por exemplo,

E qual versão do Node.js você está usando?

Obrigado pela resposta, a versão do Node é 6.11.1. Aqui está o link para o branch https://github.com/Divya063/pdf.js/tree/dev

Os erros são:

Firefox 43.0.0
SyntaxError: as declarações de importação podem aparecer apenas no nível superior
Chrome 60.0.3112
SyntaxError não capturado: importação de token inesperada

Isso indica que o código não é transpilado antes do uso. Atualmente, há suporte embutido para módulos ES não habilitado por padrão em nenhum navegador ( mais informações ), então o código precisa ser transpilado primeiro.

Eu editei minha postagem inicial para apontar onde a transpilação é configurada no sistema de compilação do PDF.js. Talvez você possa tentar usar um plugin existente para integrar Istambul e Babel. Uma pesquisa rápida mostra https://github.com/istanbuljs/babel-plugin-istanbul , mas pode haver outras opções também.

(e a versão estável atual do Firefox é 55. Você estava testando com o Firefox 43, que é antigo e não é compatível. Sugiro que atualize para uma versão recente do Firefox antes de testar novamente)

@ Rob - W Obrigado por indicar os erros. Em breve atualizarei com os resultados.

@ Rob - WI transpilei o código usando karma-browserify e atualizou a versão do firefox, mas ainda assim muitos erros estão aparecendo. Aqui está o link do branch https://github.com/Divya063/pdf.js/tree / dev

Você pode compartilhar as mensagens de erro?

E se possível, tente usar webpack em vez de browserify, porque webpack é o que já usamos. Isso nos permite instrumentar o código que é realmente usado no navegador.

E também vejo que você está fazendo check-in .idea e outros arquivos de projeto / IDE específicos do usuário. Quando você contribui com um projeto existente, é melhor não adicionar arquivos não relacionados ao projeto, porque isso confunde o repositório e causa conflitos de mesclagem. Na solicitação final de pull, esses arquivos não devem ser incluídos.

Este problema ainda está ativo? Se sim, gostaria de trabalhar nisso.

Sim, fique à vontade para trabalhar nisso.

@timvandermeij
Eu estava trabalhando nisso. Usei Istambul para cobrir meus testes e macacões para exibir os relatórios. Fiz as alterações necessárias sempre que necessário. No entanto, sempre que executo macacões usando

npm run coveralls

Eu obtenho o seguinte erro

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

Tentei procurar aqui e aqui, mas sem sucesso. Alguma ajuda sobre o que pode ser o problema?

É difícil dizer sem ver o código. Você poderia enviar o código para um branch para que os colaboradores aqui possam acompanhar você?

@timvandermeij aqui está. Ignore o arquivo gem. eu já removi.

Quaisquer comentários @timvandermeij

Olhando um pouco no Google, parece que este erro significa que coveralls não está obtendo dados no formato lcov . Você pode verificar se os comandos individuais em npm run cover -- --report lcovonly && cat ./coverage/lcov.info | coveralls de fato retornam os resultados esperados.

@timvandermeij
O principal problema atualmente é esta declaração
No coverage information was collected, exit without writing coverage information
Por causa disso, o arquivo lcov sempre permanece em branco e, portanto, isso acontece

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

Ao pesquisar no Google, parece que esses erros são muito comuns. e o erro está basicamente em Istambul. Tentei alternar entre diferentes versões do mesmo, mas o erro continuou ocorrendo. No entanto, em todos os lugares o teste foi feito por mocha e não por lint ou unittest etc. e, portanto, a maioria (quase) das resoluções também são apenas para mocha. Estas foram algumas fontes que pesquisei

https://github.com/gotwarlost/istanbul/issues/262
https://github.com/coryhouse/react-slingshot/issues/245
https://github.com/gotwarlost/istanbul/issues/496
e vários outros também, mas nenhum deles realmente ajudou :(

A compilação é transmitida travis ( https://travis-ci.org/shikhar-scs/pdf.js/jobs/318422621 ), mas novamente a cobertura não é gerada.

Não sei bem por que isso está acontecendo, mas também encontro muitas pessoas que fizeram isso com sucesso com Jasmine, então deve ser possível. Você poderia tentar se https://bryce.fisher-fleig.org/blog/setting-up-istanbul-with-jasmine/index.html funciona para você? Primeiro, tente essas etapas exatas para ver se funciona de forma independente e, em seguida, tente integrá-lo ao PDF.js.

@timvandermeij nele
Os relatórios de cobertura estão finalmente sendo gerados. No entanto, preciso transpilar e testar porque está apresentando problemas com as instruções de importação e exportação
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 erro está surgindo com cada arquivo js e irei trabalhar nisso e enviar um PR em breve.

@timvandermeij

Aqui estão eles: o build passando e pedindo cobertura .

Os relatórios de cobertura

No entanto, como as declarações de importação e exportação existem, mesmo depois de chegar a esses arquivos, eles não foram totalmente testados e, portanto, estamos recebendo relatórios de cobertura de 0%. Pelo que eu sei, preciso babelificar esses arquivos para ES6 antes do teste do jasmine e isso está provando ser um problema. Como forneço o código ES6 para o jasmine?
Posso fazer alterações no arquivo gulp conforme mencionado aqui http://jpsierens.com/use-es6-right-now/ ?

Você está realmente se aproximando da solução. A partir dos relatórios de cobertura, parece que você executou a cobertura nos arquivos lib , que já devem ser transpilados para ES6 (consulte https://github.com/mozilla/pdf.js/blob/6ac9e1c5ed0d5f067872b8482724c171c79566b2/gulpfile. js # L965 e https://github.com/mozilla/pdf.js/blob/6ac9e1c5ed0d5f067872b8482724c171c79566b2/gulpfile.js#L985). Ou o problema é que os próprios testes de unidade não são transpilados? Não estou realmente familiarizado com como isso funciona exatamente, mas se for o caso, algumas alterações no Gulpfile para os testes de unidade podem ser necessárias.

@timvandermeij

Ou o problema é que os próprios testes de unidade não são transpilados? Não estou realmente familiarizado com como isso funciona exatamente, mas se for o caso, algumas alterações no Gulpfile para os testes de unidade podem ser necessárias.

O problema era que eu estava executando os testes na pasta errada. build>lib pasta
Outro problema era a instrução --report lcovonly . Magicamente (eu realmente não sei por quê), quando removi essa parte da linha de macacões, os relatórios começaram a ser gerados. Talvez eu devesse ter prestado mais atenção a

Você pode verificar se os comandos individuais no npm executam cover - --report lcovonly && cat ./coverage/lcov.info | macacões de fato retornam os resultados que você espera.

Obrigado por apontar isto.

Finalmente, somos capazes de gerar relatórios: tada: e embora eles pareçam um pouco tristes, a leitura dos arquivos exatos lhe dará o motivo -

1. Todas as declarações condicionais não executadas estão sendo contadas como 'não cobertas'.
2. Todas as instruções de atribuição não executadas também estão sendo contadas como 'não cobertas'.

Obviamente, não fiz upload dos relatórios gerados, mas os hospedei em um link aqui http://pdfjscoveragereport.bitballoon.com . Visite esses links e você obterá o relatório exato esperado.

No entanto, esses resultados não se refletem em coveralls.io : cry: Não sei por quê. Além disso, notei que mesmo depois de comprometer várias vezes coveralls ainda está construindo meu projeto com base em um commit muito antigo e não em um recente, por causa da cobertura lá, embora seja gerada, mas sempre permanece 0 ( embora não seja 0 agora). Por favor me ajude em como resolver isso.

Mesmo assim, npm run coveralls fornecerá todos os relatórios de cobertura neste formato na pasta build/lib/coverage/lcov-report .

Espero que tudo isso ajude finalmente, porém, nosso último problema é mostrar esses relatórios de alguma forma em macacões.

Este é o link para minha última construção. https://travis-ci.org/shikhar-scs/pdf.js
Este é o link do meu último commit .

Tirando os relatórios não sendo gerados no coveralls.io está tudo bem eu acho. Portanto, devo gerar um RP, pois isso atrairá a atenção de muito mais pessoas e, em vez disso, poderá resolver o problema mais cedo?

Bom trabalho! É muito bom ter uma ideia da cobertura e os relatórios finalmente nos dão isso. Na verdade, isso mostra claramente que precisamos de muito mais testes de unidade, mas todos os métodos aos quais adicionamos recentemente os testes de unidade são mostrados conforme coberto no relatório, de modo que parece perfeitamente bom.

Eu me pergunto se seria possível executar a cobertura sobre os arquivos de origem em vez dos arquivos construídos. Isso torna mais fácil de entender, porque agora em http://pdfjscoveragereport.bitballoon.com/lib/display/metadata.js.html vejo a linha 28 não sendo coberta, embora não seja nosso código, mas código gerado automaticamente. Se for difícil, podemos apenas fazer a abordagem atual como uma primeira versão e fazer isso em uma edição de acompanhamento.

Portanto, devo gerar um RP, pois isso atrairá a atenção de muito mais pessoas e, em vez disso, poderá resolver o problema mais cedo?

Sim, essa é uma boa ideia. Podemos então iniciar o processo de revisão e ver quais problemas ainda precisam ser resolvidos.

É muito bom ter uma ideia da cobertura e os relatórios finalmente nos dão isso. Na verdade, isso mostra claramente que precisamos de muito mais testes de unidade, mas todos os métodos aos quais adicionamos recentemente os testes de unidade são mostrados conforme coberto no relatório, de modo que parece perfeitamente bom.

Embora seja verdade que poderíamos fazer muito mais testes de unidade, há grandes porções da base de código que provavelmente nunca chegará perto de uma cobertura de teste "boa" o suficiente apenas com os testes de unidade, infelizmente.

Conforme mencionado em https://github.com/mozilla/pdf.js/issues/8632#issue -241690851, há alguns conjuntos de testes diferentes e, a menos que eu esteja enganado, obter resultados de cobertura de gulp browsertest também seria quase essencial saber realmente como é a nossa cobertura de teste real.

@Snuffleupagus @timvandermeij

Esta manhã tentei encontrar relatórios de cobertura em todas as pastas individualmente usando a instrução cd build && cd lib && istanbul cover --include-all-sources jasmine-node test , mudando diretórios diferentes usando cd <directory name> e testando usando jasmine-node <directory names and js files> mas em vão.

Embora relatórios de testes sejam gerados às vezes (nem sempre), isso está acontecendo por causa de um ou dois arquivos de formato js ES6 nos diretórios específicos (o que está trazendo apenas <2 ~ 3% dos relatórios de cobertura). Infelizmente, qualquer arquivo js que contém import or export statements está retornando um erro neste 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

E com esse erro, o arquivo não é verificado quanto à cobertura e, portanto, retorna um relatório de 0%.

Eu me pergunto se seria possível executar a cobertura sobre os arquivos de origem em vez dos arquivos construídos.

Novamente, a pasta de origem contém arquivos que possuem declarações de importação e exportação e, portanto, os erros acima ocorrem porque os arquivos relacionados não são verificados, levando a uma cobertura de 0%.

Portanto, é imperativo que testemos na própria pasta de construção.

obter resultados de cobertura do gulp browsertest também seria quase essencial para realmente saber como é a nossa cobertura de teste real.

@Snuffleupagus Onde estão esses testes específicos? Podemos tentar testá-los diretamente usando a instrução jasmine-node mencionada acima.

Se for difícil, podemos apenas fazer a abordagem atual como uma primeira versão e fazer isso em uma edição de acompanhamento.

Sim, poderíamos preferir fazer isso.

Sim, essa é uma boa ideia. Podemos então iniciar o processo de revisão e ver quais problemas ainda precisam ser resolvidos.

Claro, vou começar com isso.

O PR em # 9308 mostrou um exemplo de cobertura de teste apenas para os testes de unidade. Os relatórios gerados fornecem pouco valor porque nosso conjunto de testes de unidade é muito pequeno. Para obter mais detalhes, consulte https://github.com/mozilla/pdf.js/pull/9308#issuecomment -353588039

Portanto, para obter testes de navegador, precisamos:

1. Uma forma de gerar dados de cobertura.
2. Uma maneira de recuperar os dados de cobertura (e enviá-los para macacões).

Para abordar 1), gulpfile.js deve ser editado para adicionar opcionalmente a instrumentação de código, que é exportada para o objeto window.__coverage__ em um navegador. gulp-istanbul pode ser útil. A documentação parece esparsa, mas encontrei um exemplo em https://stackoverflow.com/questions/38208735/no-window-coverage-object-is-created-by-istanbul-phantomjs. NÃO usamos o PhantomJS, mas você pode ler a pergunta, a resposta e a postagem do blog com link para aprofundar sua compreensão de como tudo funciona.

Depois de terminar a etapa 1, os testes do navegador terão uma variável window.__coverage__ (ou o que quer que você tenha colocado no parâmetro de configuração coverageVariable ). Para obter relatórios de cobertura:

1. Modifique o executor de teste (https://github.com/mozilla/pdf.js/blob/e081a708c36cb2aacff7889048863723fcf23671/test/driver.js) para postar o resultado da cobertura com XMLHttpRequest no servidor de teste.
2. No servidor de teste (https://github.com/mozilla/pdf.js/blob/e081a708c36cb2aacff7889048863723fcf23671/test/test.js), registre um novo gancho para receber os resultados do teste e grave-o em um arquivo usando fs API
3. Carregue o relatório para macacões (por exemplo, com o comando "macacões" conforme mostrado em # 9308).

@ Rob - W Obrigado por uma revisão tão detalhada. Farei o acompanhamento e reverterei o mais rápido possível.

Este comentário oferece dicas para a implementação e responde às perguntas de https://github.com/mozilla/pdf.js/pull/9308#issuecomment -353710595

istanbul apenas adiciona instrumentação ao código. Essa entrada deve ser um código executável, porque "instrumentação" significa adicionar código JavaScript extra que detecta quando a execução passa por essa linha, instrução, etc. Se o código for significativamente alterado novamente após adicionar a instrumentação, o relatório de cobertura resultante perderá o sentido.

Esta instrumentação pode ser feita em tempo real enquanto o programa está sendo executado (por exemplo, quando você executa istanbul cover na linha de comando, istanbul interceptará chamadas para require do Node.js e transformar o código com instrumentação antes que o módulo seja carregado ), ou separadamente da execução (por exemplo, como a postagem do blog demonstra: o código instrumentado é gerado na linha de comando, a execução é feita no navegador).

Em seu PR atual em # 9308, você está invocando istanbul cover com jasmine como o programa a ser executado. Como mencionei antes, o efeito é semelhante a executar gulp unittestcli - isto é, os testes são executados em uma biblioteca pré-construída no diretório build/lib (isso é configurado em test/unit/clitests.json ) . Isso explica por que seu relatório de cobertura mostra cobertura 0 para tudo, exceto build/lib/ (porque os únicos módulos require -d (Node.js) estão em build/lib e build/streams/ - veja o final da definição da tarefa gulp unittestcli ).

Para obter relatórios de cobertura úteis , os relatórios de cobertura são preferencialmente em nível de módulo. Este é um passo à frente: você precisa integrar istanbul no pipeline de compilação, de modo que quando o código for transpilado do ES6, a instrumentação seja adicionada. Depois disso, torna-se mais difícil gerar relatórios por módulo (mas não impossível, em teoria os mapas de origem fornecem informações suficientes para mapear os dados para os arquivos originais).
Este é um desafio e requer um bom entendimento de como usar Babel, gulp, istambul e mapas / módulos de origem (já me referi aos locais relevantes no código-fonte onde PDF.js reúne todos os módulos para gerar o PDF.js biblioteca - consulte # 8632). Esse conhecimento é muito útil, portanto, se você não tem medo de desafios, pode explorá-lo sob minha orientação.

Mas antes de mergulhar tão fundo, vamos começar com algo mais simples: obter relatórios de cobertura do navegador. Temos duas maneiras de executar testes no navegador, unittest e browsertest . Como já temos uma maneira bastante fácil de executar testes de unidade em Node.js, vamos nos concentrar em browsertest . Os testes de navegador não usam módulos individuais, mas a biblioteca PDF.js criada pelo destino generic gulp , em GENERIC_DIR , também conhecido build/generic/ . Portanto, é suficiente adicionar instrumentação de código a build/generic . Sugiro tomar build/generic/ como diretório de entrada e escrever o resultado em coverage/build/generic .

Depois de fazer isso, você precisa alterar test/test_slave.html para não carregar ../build/generic/build/pdf.js incondicionalmente em uma tag <script> , mas carregar condicionalmente ../build/generic/build/pdf.js ou ../coverage/build/generic/build/pdf.js dependendo de algum parâmetro de configuração (para teste, você pode apenas codificar o último URL, é muito fácil alterar este parâmetro codificado posteriormente após ter concluído a tarefa mais difícil de enviar o relatório de cobertura de volta ao servidor de teste) .

Depois de substituir a biblioteca pdf.js normal pela biblioteca pdf.js instrumentada, as estatísticas de cobertura serão geradas durante a execução do teste. O resultado é armazenado na variável global window.__coverage__ . Quando o driver de teste no navegador terminar ( o método _quit em test / driver.js ), você pode serializar este relatório (por exemplo, usando JSON.stringify(window.__coverage__) ) e enviá-lo ao servidor com XMLHttpRequest (veja os outros locais no arquivo driver.js para exemplos - certifique-se de enviar o relatório para o servidor ANTES de enviar a mensagem /tellMeToQuit , caso contrário, o relatório de cobertura pode não ser transmitido corretamente).
Você pode adicionar um novo manipulador para sua nova chamada de API personalizada em https://github.com/mozilla/pdf.js/blob/ba5dbc96326518ad716158ef040f61794cc72202/test/test.js . Para exemplos de código, observe XMLHttpRequest chamadas em driver.js (como a mensagem /tellMeToQuit ) e encontre o manipulador correspondente em test.js . Depois de receber o JSON serializado no servidor, use a API fs.writeFileSync para gravar o relatório de cobertura em um arquivo (novamente, há outros exemplos em test.js que mostram como você pode gravar arquivos) .

@ Rob - W Eu não estou disponível até o ano novo ... Vou pegar com certeza depois disso

Depois de fazer isso, você precisa alterar test / test_slave.html para não carregar incondicionalmente ../build/generic/build/pdf.js em um

Depois de fazer isso, você precisa alterar test / test_slave.html para não carregar incondicionalmente ../build/generic/build/pdf.js em um

@ Rob - WI consegui criar um parâmetro semelhante no tests.js (imitando o parâmetro testFilter), no entanto, incorporá-lo no test/test_slave.html ainda é um problema para mim. Para o resto das alterações, visite o PR novamente, eu enviei novos commits. # 9308

Também se você pudesse me fornecer links para entrar no canal IRC ou slack / gitter / lista de discussão específica para pdf.js.

@ Rob - W O problema ainda está ativo? Se sim, gostaria de trabalhar nisso.
Obrigado.

A primeira tentativa é em # 9308, então você pode usar isso como inspiração. Vamos nos concentrar em fazer com que uma versão mínima funcione, ou seja, uma que funcione apenas localmente. Não precisa funcionar nos bots ou no Travis CI; se pudermos fazer relatórios de cobertura localmente, isso já é muito significativo. Para localmente, seria bom fazer um comando chamado gulp coverage que executa testes de unidade instrumentados e gera um relatório de cobertura com base nisso. Se estiver funcionando e mesclado, sempre podemos iterar nisso.

@timvandermeij ainda está ativo? Eu posso tentar também

Sim, fique à vontade para trabalhar nisso! Devemos começar simples; consulte https://github.com/mozilla/pdf.js/issues/8632#issuecomment -455868037 para uma possível abordagem.

@timvandermeij está se perguntando se eu posso tentar isso? Uma dúvida maior que tenho é se é possível usar um script npm para gerar o relatório, ou se tem que ser uma tarefa gulp ?

Não tenho muita familiaridade com gulp mas estou disposto a aprender se isso é um requisito para isso

Acho que ninguém está trabalhando nisso, então vá em frente! É importante mantê-lo simples para o patch inicial. Como usamos o Gulp como nossa ferramenta principal, é preferível usá-lo, mas também estamos abertos para outras sugestões. Consulte https://github.com/mozilla/pdf.js/issues/8632#issuecomment -455868037 para ideias de implementação. Não requer muita experiência com o Gulp porque o Gulp é um executor de tarefas bastante simples, ou seja, ele envolve quase tudo que você faria em um script NPM. Dê uma olhada no Gulpfile para se inspirar.

Eu gostaria de trabalhar nisso. O problema ainda está aberto? E onde posso obter uma melhor compreensão do bug?

@jezhou estava trabalhando nisso e fez algum progresso no # 11580. O PR não foi atualizado recentemente.

Muito obrigado pela atualização. Acho que posso começar a trabalhar nisso? Onde
posso obter mais informações? Sobre o assunto e o resto ??

No sábado, 16 de maio de 2020, 17:56, Rob Wu, [email protected] escreveu:

@jezhou https://github.com/jezhou estava trabalhando nisso e fez alguns
progresso em # 11580 https://github.com/mozilla/pdf.js/pull/11580 . O PR
não foi atualizado recentemente embora.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/mozilla/pdf.js/issues/8632#issuecomment-629637879 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AKUZ65CGSIZF6OMFZWENWF3RR2A77ANCNFSM4DSK7SGQ
.