Pdf.js: Сгенерировать (тестировать) статистику покрытия

unittestcli - запускает некоторые модульные тесты PDF.js в Node.js (с минимальными изменениями исходного кода, только с транспиляцией с помощью babel).
browsertest - запускает тесты в браузерах (мы тестируем Chrome и Firefox). Это полагается на двоичный файл, созданный целью сборки generic , которая использует код, переданный с помощью babel, а затем связанный с webpack.

Обратите внимание, что хотя browsertest будет запускать эталонные тесты, есть также команда unittest которая запускает полный набор модульных тестов в браузерах (в отличие от unittestcli которая запускает только подмножество существующих юнит-тестов).

Кроме того, обратите внимание, что этап «транспиляция с помощью Babel» можно пропустить, если установлен флаг сборки PDFJS_NEXT (либо как другие флаги сборки в gulpfile.js , либо как аргумент командной строки). Хотя код по-прежнему связан с Webpack, по крайней мере, можно избежать этапа транспиляции.

@ Роб - В, я хотел бы поработать над этим

Это ваше! Дайте нам знать (желательно через IRC), если у вас есть вопросы.

@timvandermeij Я подумываю использовать инструмент Karma. Он работает с механизмом покрытия кода istanbul. Статистику можно проверять на выполнение тестов, с его помощью можно создавать отчеты в формате HTML. Это хороший способ начать?

Используя Karma, я получил отчеты об испытаниях https://drive.google.com/file/d/0ByddvU1PKkWaWEZTWHFYT0Y0aTg/view?usp=sharing
но статистика покрытия тестами не отображается https://drive.google.com/file/d/0ByddvU1PKkWaS1ZiT1dobU1DQUk/view?usp=sharing

@ Divya063 Не могли бы вы поделиться своим кодом, например, поместив текущий код в ветку вилки pdf.js на Github? Интересно, запускается ли при необходимости webpack или babel.

А какую версию Node.js вы используете?

Спасибо за ответ, версия Node - 6.11.1. Вот ссылка на ветку https://github.com/Divya063/pdf.js/tree/dev

Ошибки:

Firefox 43.0.0
SyntaxError: объявления импорта могут появляться только на верхнем уровне
Хром 60.0.3112
Uncaught SyntaxError: неожиданный импорт токена

Это указывает на то, что код не передается перед использованием. В настоящее время встроенная поддержка модулей ES не включена по умолчанию ни в одном браузере ( подробнее ), поэтому сначала необходимо перенести код.

Я отредактировал свой первоначальный пост, чтобы указать, где в системе сборки PDF.js настроена транспиляция. Возможно, вы можете попробовать использовать существующий плагин для интеграции istanbul и babel. Быстрый поиск показывает https://github.com/istanbuljs/babel-plugin-istanbul , но могут быть и другие варианты.

(а текущая стабильная версия Firefox - 55. Вы тестировали Firefox 43, который является устаревшим и не поддерживается. Я предлагаю вам перейти на последнюю версию Firefox перед повторным тестированием)

@ Rob - W Спасибо за указание ошибок. Скоро я сообщу о результатах.

@ Rob - Я передал код с помощью karma-browserify и обновил версию firefox, но по-прежнему возникает много ошибок. Вот ссылка на ветку https://github.com/Divya063/pdf.js/tree / dev

Вы можете поделиться сообщениями об ошибках?

И если возможно, попробуйте использовать webpack вместо browserify, потому что webpack - это то, что мы уже используем. Это позволяет нам инструментировать код, который фактически используется в браузере.

И я также вижу, что вы проверяете .idea и другие файлы проектов / IDE для конкретных пользователей. Когда вы вносите свой вклад в существующий проект, лучше не добавлять в проект несвязанные файлы, потому что это загромождает репозиторий и вызывает конфликты слияния. В окончательный запрос на включение эти файлы не следует включать.

Эта проблема все еще актуальна? Если да, я бы хотел поработать над этим.

Да, не стесняйтесь работать над этим.

@timvandermeij
Я работал над этим. Я использовал istanbul для покрытия своих тестов и комбинезона для отображения отчетов. Я внес необходимые необходимые изменения везде, где это было необходимо. Однако всякий раз, когда я использую комбинезон,

npm run coveralls

Я получаю следующую ошибку

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

Я пытался найти это здесь и здесь, но безуспешно. Любая помощь в том, в чем может быть проблема?

Трудно сказать, не увидев кода. Не могли бы вы отправить код в ветку, чтобы участники могли смотреть вместе с вами?

@timvandermeij вот и он. Пожалуйста, игнорируйте гем-файл. я уже удалил это.

Любые комментарии @timvandermeij

Если немного погуглить, похоже, что эта ошибка означает, что coveralls не получает данные в формате lcov . Вы можете проверить, действительно ли отдельные команды в npm run cover -- --report lcovonly && cat ./coverage/lcov.info | coveralls возвращают ожидаемые результаты.

@timvandermeij
Основная проблема на данный момент - это утверждение
No coverage information was collected, exit without writing coverage information
Из-за этого файл lcov всегда остается пустым, и это происходит

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

При поиске в Google кажется, что это очень частые ошибки. и ошибка в основном связана с Стамбулом. Я пробовал переключаться между разными версиями одного и того же, но ошибка повторялась. Тем не менее, во всех местах тестирование проводилось с помощью мокко, а не с помощью lint или unittest и т. Д., И поэтому большинство (почти) разрешений также предназначены только для мокко. Это были некоторые источники, которые я искал

https://github.com/gotwarlost/istanbul/issues/262
https://github.com/coryhouse/react-slingshot/issues/245
https://github.com/gotwarlost/istanbul/issues/496
и еще несколько, но ни один из них не помог :(

Сборка передается на travis ( https://travis-ci.org/shikhar-scs/pdf.js/jobs/318422621 ), но опять же покрытие не создается.

Я не совсем уверен, почему это происходит, но я также нахожу множество людей, которые успешно справились с этим с Жасмин, так что это должно быть возможно. Не могли бы вы попробовать, работает ли https://bryce.fisher-fleig.org/blog/setting-up-istanbul-with-jasmine/index.html для вас? Сначала просто попробуйте эти точные шаги, чтобы убедиться, что работает автономно, а затем попробуйте интегрировать его в PDF.js.

@timvandermeij на нем
Наконец-то готовятся отчеты о покрытии. Однако мне нужно транспилировать, а затем тестировать, потому что у него появляются проблемы с операторами импорта и экспорта.
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)
Эта ошибка возникает в каждом файле js, и я скоро поработаю над ней и напишу PR.

@timvandermeij

Вот они: прохождение сборки и вызов покрытия .

Отчеты о покрытии

Однако, поскольку существуют операторы импорта и экспорта, даже после получения этих файлов они не полностью протестированы, и поэтому мы получаем отчеты о покрытии 0%. Насколько я знаю, мне нужно добавить эти файлы в ES6 перед тестированием жасмина, и это оказалось проблемой. Как мне предоставить код ES6 для жасмина?
Могу ли я внести изменения в файл gulp, как указано здесь http://jpsierens.com/use-es6-right-now/ ?

Вы действительно приближаетесь к решению. Из отчетов о покрытии похоже, что вы запускаете покрытие для файлов lib , которые уже должны быть перенесены в ES6 (см. Https://github.com/mozilla/pdf.js/blob/6ac9e1c5ed0d5f067872b8482724c171c79566b2/gulpfile. js # L965 и https://github.com/mozilla/pdf.js/blob/6ac9e1c5ed0d5f067872b8482724c171c79566b2/gulpfile.js#L985). Или проблема в том, что сами юнит-тесты не передаются? Я не очень хорошо знаю, как это работает, но в этом случае могут потребоваться некоторые изменения в Gulpfile для модульных тестов.

@timvandermeij

Или проблема в том, что сами юнит-тесты не передаются? Я не очень хорошо знаю, как это работает, но в этом случае могут потребоваться некоторые изменения в Gulpfile для модульных тестов.

Проблема заключалась в том, что я запускал тесты не в той папке. Папка build>lib уже содержит весь проект в формате ES6, и теперь я исправил все, то есть путь жасмина и комбинезона.
Другой проблемой был оператор --report lcovonly . Волшебным образом (правда, не знаю почему), когда я удалил эту деталь из линейки комбинезонов, начали формироваться отчеты. Может, мне следовало уделить больше внимания

Вы можете проверить, выполняются ли отдельные команды в npm cover - --report lcovonly && cat ./coverage/lcov.info | комбинезоны действительно возвращают ожидаемые результаты.

Спасибо, что указали на это.

Наконец, мы можем создавать отчеты: tada: и хотя они выглядят немного грустно, но чтение точных файлов даст вам причину, почему -

1. Все невыполненные условные утверждения считаются «не покрытыми».
2. Все невыполненные операторы присваивания также считаются «не покрытыми».

Я, очевидно, не загружал сгенерированные отчеты сам, но разместил их по ссылке здесь http://pdfjscoveragereport.bitballoon.com . Пожалуйста, перейдите по этим ссылкам, и вы получите точный отчет.

Однако эти результаты не отражаются на coveralls.io : cry: Не знаю почему. Кроме того, я заметил, что даже после многократной фиксации coveralls все еще строит мой проект на основе очень старой фиксации, а не на последней, из-за чего покрытие там хотя и создается, но всегда остается 0 ( хотя сейчас не 0). Пожалуйста, помогите мне решить эту проблему.

Но все же npm run coveralls предоставит все отчеты о покрытии в этом формате, лежащие в папке build/lib/coverage/lcov-report .

Надеюсь, все это в конце концов поможет, но наша последняя проблема - как-то показать эти отчеты на комбинезоне.

Это ссылка на мою последнюю сборку. https://travis-ci.org/shikhar-scs/pdf.js
Это ссылка на мой последний коммит .

Думаю, за исключением отчетов, которые не создаются на coshopss.io, все в порядке. Так что, стоит ли мне создавать PR, так как это привлечет внимание еще большего числа людей и может решить эту проблему раньше?

Хорошая работа! Действительно хорошо иметь представление об освещении, и отчеты, наконец, дают нам это. Действительно, это ясно показывает, что нам нужно гораздо больше модульного тестирования, но все методы, для которых мы недавно добавили модульные тесты, действительно показаны в отчете, так что это выглядит прекрасно.

Я действительно задаюсь вопросом, можно ли запустить покрытие исходных файлов вместо встроенных файлов. Это упрощает понимание, потому что теперь на http://pdfjscoveragereport.bitballoon.com/lib/display/metadata.js.html я вижу, что строка 28 не покрывается, хотя это не наш код, а вместо этого автоматически сгенерирован код. Если окажется, что это сложно, мы можем просто использовать текущий подход в качестве первой версии и сделать это в следующем выпуске.

Так что, стоит ли мне создавать PR, так как это привлечет внимание еще большего числа людей и может решить эту проблему раньше?

Да, что это хорошая идея. Затем мы можем начать процесс проверки и посмотреть, какие проблемы нужно решить.

Действительно хорошо иметь представление об освещении, и отчеты, наконец, дают нам это. Действительно, это ясно показывает, что нам нужно гораздо больше модульного тестирования, но все методы, для которых мы недавно добавили модульные тесты, действительно показаны в отчете, так что это выглядит прекрасно.

Хотя, безусловно, верно то, что мы могли бы использовать гораздо больше модульных тестов, есть большие части кодовой базы, которые, к сожалению, никогда не смогут приблизиться к «хорошему» достаточному тестированию только с помощью одних только модульных тестов.

Как упоминалось в https://github.com/mozilla/pdf.js/issues/8632#issue -241690851, есть несколько разных наборов тестов, и, если я не ошибаюсь, также получаю результаты покрытия от gulp browsertest было бы почти необходимо, чтобы действительно знать, как выглядит наше фактическое покрытие тестами.

@Snuffleupagus @timvandermeij

Этим утром я много пытался найти отчеты о покрытии во всех папках по отдельности, используя оператор cd build && cd lib && istanbul cover --include-all-sources jasmine-node test , меняя разные каталоги, используя cd <directory name> и тестируя, используя jasmine-node <directory names and js files> но тщетно.

Хотя отчеты о тестах генерируются время от времени (не всегда), это происходит из-за того, что в определенных каталогах лежат один или два файла js в формате ES6 (что дает только <2 ~ 3% отчетов о покрытии). К сожалению, любой js-файл, содержащий import or export statements , возвращает ошибку в этом формате.

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

И с этой ошибкой файл вообще не проверяется на предмет покрытия и поэтому возвращает отчет 0%.

Я действительно задаюсь вопросом, можно ли запустить покрытие исходных файлов вместо встроенных файлов.

Опять же, исходная папка содержит файлы, которые имеют операторы импорта и экспорта, и поэтому возникают вышеуказанные ошибки, из-за которых связанные файлы вообще не проверяются, что приводит к 0% охвату.

Таким образом, мы обязательно проводим тестирование в самой папке сборки.

Получение результатов покрытия от gulp browsertest также было бы почти важным, чтобы действительно знать, как выглядит наше фактическое покрытие тестированием.

@Snuffleupagus Где лежат эти конкретные тесты? Мы можем попробовать протестировать их напрямую, используя оператор jasmine-node, упомянутый выше.

Если окажется, что это сложно, мы можем просто использовать текущий подход в качестве первой версии и сделать это в следующем выпуске.

Да, мы могли бы это сделать.

Да, что это хорошая идея. Затем мы можем начать процесс проверки и посмотреть, какие проблемы нужно решить.

Конечно, я начну с этого.

PR на # 9308 показал пример тестового покрытия только для юнит-тестов. Сгенерированные отчеты не представляют большой ценности, потому что наш набор модульных тестов очень мал. Подробнее см. Https://github.com/mozilla/pdf.js/pull/9308#issuecomment -353588039.

Итак, чтобы пройти тесты браузера, нам понадобятся:

1. Способ создания данных о покрытии.
2. Способ получить данные о покрытии (и загрузить их в комбинезон).

Для адреса 1) необходимо отредактировать gulpfile.js , чтобы при необходимости добавить инструментарий кода, который экспортируется в объект window.__coverage__ в браузере. gulp-istanbul может оказаться полезным. Документация кажется скудной, но я нашел пример на https://stackoverflow.com/questions/38208735/no-window-coverage-object-is-created-by-istanbul-phantomjs. Мы НЕ используем PhantomJS, но вы можете прочитать вопрос, ответ и связанное сообщение в блоге, чтобы лучше понять, как все работает.

После завершения шага 1 тесты браузера будут иметь переменную window.__coverage__ (или все, что вы указали в параметре конфигурации coverageVariable ). Чтобы получить отчеты о покрытии:

1. Измените средство выполнения теста (https://github.com/mozilla/pdf.js/blob/e081a708c36cb2aacff7889048863723fcf23671/test/driver.js), чтобы опубликовать результат покрытия с XMLHttpRequest на тестовом сервере.
2. На тестовом сервере (https://github.com/mozilla/pdf.js/blob/e081a708c36cb2aacff7889048863723fcf23671/test/test.js) зарегистрируйте новый хук для получения результатов теста и запишите его в файл, используя fs Node.js API (возможно, после некоторой постобработки, например, при необходимости преобразования в формат lcov).
3. Загрузите отчет в комбинезоны (например, с помощью команды «комбинезоны», как показано в # 9308).

@ Rob - W Спасибо за такой подробный обзор. Я свяжусь с вами и вернусь как можно скорее.

Этот комментарий предлагает советы по реализации и отвечает на вопросы https://github.com/mozilla/pdf.js/pull/9308#issuecomment -353710595.

istanbul только добавляет в код инструментарий. Предполагается, что эти входные данные являются исполняемым кодом, потому что «инструментарий» означает добавление дополнительного кода JavaScript, который определяет, когда выполнение проходит через эту строку, оператор и т. Д. Если код снова значительно изменяется после добавления инструментария, итоговый отчет о покрытии теряет смысл.

Этот инструментарий может быть выполнен на лету во время выполнения программы (например, когда вы запускаете istanbul cover из командной строки, istanbul будет перехватывать вызовы require Node.js. и преобразовать код с помощью инструментовки до загрузки модуля ) или отдельно от выполнения (например, как показано в сообщении в блоге: инструментальный код генерируется в командной строке, выполнение выполняется в браузере).

В вашем текущем PR на # 9308 вы вызываете istanbul cover с jasmine в качестве программы для запуска. Как я упоминал ранее, эффект аналогичен запуску gulp unittestcli - т.е. тесты запускаются с предварительно созданной библиотекой в ​​каталоге build/lib (это настраивается в test/unit/clitests.json ) . Это объясняет, почему в вашем отчете о покрытии отображается 0 для всего, кроме build/lib/ (потому что только модули require -d (Node.js) находятся в build/lib и build/streams/ - см. конец определения задачи gulp unittestcli ).

Чтобы получить полезные отчеты о покрытии, предпочтительно, чтобы отчеты о покрытии были на уровне модуля. Это шаг вперед: вам нужно интегрировать istanbul в конвейер сборки, чтобы при переносе кода из ES6 добавлялись инструменты. После этого становится сложнее создавать отчеты по модулям (но это не невозможно, теоретически исходные карты предоставляют достаточно информации для сопоставления данных с исходными файлами).
Это сложная задача, требующая хорошего понимания того, как использовать Babel, gulp, istanbul и исходные карты / модули (я уже упоминал соответствующие места в исходном коде, где PDF.js объединяет все модули для создания PDF.js библиотека - см. №8632). Эти знания очень полезны, поэтому, если вы не боитесь проблем, вы можете изучить их под моим руководством.

Но прежде чем погрузиться в подробности, давайте начнем с чего-то более простого: получения отчетов о покрытии из браузера. У нас есть два способа запуска тестов в браузере: unittest и browsertest . Поскольку у нас уже есть довольно простой способ запуска модульных тестов в Node.js, давайте сосредоточимся на browsertest . В тестах браузера используются не отдельные модули, а библиотека PDF.js, созданная целевой целью generic gulp в GENERIC_DIR , также известной как build/generic/ . Так что достаточно добавить инструментарий кода в build/generic . Я предлагаю взять build/generic/ в качестве входного каталога и записать результат в coverage/build/generic .

После этого вам нужно изменить test/test_slave.html чтобы не загружать ../build/generic/build/pdf.js безоговорочно в теге <script> , но условно загружать либо ../build/generic/build/pdf.js или ../coverage/build/generic/build/pdf.js зависимости от некоторого параметра конфигурации (для тестирования вы можете просто жестко запрограммировать последний URL-адрес, очень легко изменить этот жестко запрограммированный параметр позже, после того, как вы выполните более сложную задачу отправки отчета о покрытии обратно на тестовый сервер) .

После того, как вы заменили обычную библиотеку pdf.js инструментальной библиотекой pdf.js, статистика покрытия будет сгенерирована во время выполнения теста. Результат сохраняется в глобальной переменной window.__coverage__ . Когда тестовый драйвер в браузере завершает работу ( метод _quit в test / driver.js ), вы можете сериализовать этот отчет (например, используя JSON.stringify(window.__coverage__) ) и отправить его на сервер с помощью XMLHttpRequest (примеры см. в других местах в файле driver.js - убедитесь, что вы отправили отчет на сервер ПЕРЕД отправкой сообщения /tellMeToQuit , иначе отчет о покрытии может не передаваться правильно).
Вы можете добавить новый обработчик для вашего нового вызова пользовательского API в https://github.com/mozilla/pdf.js/blob/ba5dbc96326518ad716158ef040f61794cc72202/test/test.js . Примеры кода можно найти в вызовах XMLHttpRequest в driver.js (например, в сообщении /tellMeToQuit ) и найдите соответствующий обработчик в test.js . Как только вы получили сериализованный JSON на стороне сервера, используйте fs.writeFileSync API, чтобы записать отчет о покрытии в файл (опять же, в test.js есть другие примеры, которые показывают, как вы можете писать файлы) .

@ Роб - W Я сейчас недоступен до нового года ... После этого я точно пойму

После этого вам нужно изменить test / test_slave.html, чтобы не загружать безоговорочно ../build/generic/build/pdf.js в

После этого вам нужно изменить test / test_slave.html, чтобы не загружать безоговорочно ../build/generic/build/pdf.js в

@ Rob - Мне удалось создать аналогичный параметр в tests.js (имитируя параметр testFilter), однако включение его в test/test_slave.html все еще остается для меня проблемой. Для остальных изменений, пожалуйста, посетите PR еще раз, я выдвинул новые коммиты. # 9308

Также, если бы вы могли предоставить мне ссылки для присоединения к каналу IRC или списку рассылки slack / gitter /, относящемуся к pdf.js.

@ Роб - W Проблема все еще не решена? Если да, я бы хотел поработать над этим.
Спасибо.

Первая попытка сделать это в # 9308, так что вы можете использовать это как вдохновение. Давайте сосредоточимся на том, чтобы минимальная версия работала, т. Е. Работала только локально. Он не обязательно должен работать с ботами или Travis CI; если мы сможем делать отчеты о покрытии на местном уровне, это уже очень важно. Для локального использования было бы неплохо создать команду с именем gulp coverage которая запускает инструментальные модульные тесты и генерирует на их основе отчет о покрытии. Это то, что работает и объединено, мы всегда можем повторить это.

@timvandermeij он все еще активен? Я тоже могу попробовать

Да, смело работайте над этим! Мы должны начать с простого; см. https://github.com/mozilla/pdf.js/issues/8632#issuecomment -455868037 для возможного подхода.

@timvandermeij интересно, могу ли я gulp ?

Я не слишком хорошо знаком с gulp но я хочу узнать, требуется ли это для этого

Я не думаю, что кто-то работает над этим, так что вперед! Важно, чтобы начальный патч оставался простым. Поскольку мы используем Gulp в качестве основного инструментария, мы предпочитаем его использовать, но мы также открыты для других предложений. Обратитесь к https://github.com/mozilla/pdf.js/issues/8632#issuecomment -455868037 для идей по реализации. Однако для этого не требуется большого опыта работы с Gulp, поскольку Gulp является довольно простым средством выполнения задач, т. Е. В основном он охватывает все, что вы также могли бы сделать в сценарии NPM. Взгляните на Gulpfile, чтобы получить вдохновение.

Я бы хотел над этим поработать. Вопрос все еще открыт? А где мне лучше разобраться в ошибке?

@jezhou работал над этим и добился некоторого прогресса в # 11580. Однако в последнее время PR не обновлялся.

Большое спасибо за обновление. Думаю, я могу начать над этим работать? где
могу я получить дополнительную информацию? О проблеме и остальном ??

В субботу, 16 мая 2020 года, 17:56 Роб Ву, [email protected] написал:

@jezhou https://github.com/jezhou работал над этим и сделал несколько
прогресс # 11580 https://github.com/mozilla/pdf.js/pull/11580 . Пиар
хотя в последнее время не обновлялся.

-
Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/mozilla/pdf.js/issues/8632#issuecomment-629637879 ,
или отписаться
https://github.com/notifications/unsubscribe-auth/AKUZ65CGSIZF6OMFZWENWF3RR2A77ANCNFSM4DSK7SGQ
.