Pegjs: Функция: во время выполнения требуются файлы pegjs.

Я бы предпочел не допустить этого.

@ExE-Boss: в нашем случае это будет просто для тестирования (также не уверен, заметили ли вы, что это репозиторий pegjs.)

Я знаю, что это репозиторий PEG.js , и именно поэтому я против реализации этого здесь.

Хорошо, круто... (Иногда я могу перейти по ссылке на другой репозиторий, не заметив, что это не отдельная проблема, так что просто удостоверюсь) :)

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

Кроме того, похоже, что вы на самом деле хотите протестировать

Вы не помещаете крючки покрытия в библиотеку. Вы помещаете их в тестовый файл.

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

Этот генератор синтаксических анализаторов не должен внезапно привязываться к экосистеме пакетов node.js как внутренняя функция.

Кроме того, покрытие — это ложное желание парсера. Рассмотрим следующее:

Food
    / "Peanuts"
    / "Shellfish"
    / "Rice"

Теперь просто напишите тест для риса. peg #$ сначала попробует Peanuts , затем, когда это не сработает, peg попробует Shellfish , затем peg попробует Rice

Обратите внимание, что вы написали тест только для Rice , но неправильно показываете покрытие для всех трех

То, как работает синтаксический анализатор packrat (честно говоря, тот парсер, который я когда-либо мог придумать), означает, что покрытие является поддельным.

Не тратьте свое время

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

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

Это становится более открытым вопросом, должно ли правило типа ruleA = ruleB / ruleC проверять, что «правило A» имеет случаи как с «правилом B», так и с «правилом C», или достаточно проверить, что «правило A», «правило B» , и "ruleC" каким-то образом покрываются (например, если есть ruleD = ruleB / ruleF , его покрытие ruleB может рассматриваться некоторыми проектами как достаточное, чтобы избежать необходимости проверять его покрытие внутри "правило А", особенно если есть много альтернатив и комбинаций).

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

@brettz9 - Я собирался сказать: «Я говорю с кем-то еще об этом же», но потом понял, что это вы, поэтому я собираюсь прекратить этот пример этого обсуждения в пользу аналогичного, которое мы имея номер 633, если вам это кажется нормальным

Я пишу что-то длинное там в настоящее время