Pegjs: Feature: Laufzeitanforderungen von Pegjs-Dateien

Das lasse ich lieber nicht zu.

@ExE-Boss: Für unseren Anwendungsfall wäre es nur zum Testen (auch nicht sicher, ob Sie bemerkt haben, dass dies das Pegjs-Repo ist.)

Ich weiß, dass dies das PEG.js- Repo ist, und genau deshalb bin ich dagegen, dies hier zu implementieren.

Ok, cool ... (Ich kann manchmal einem Link zu einem anderen Repo folgen, ohne zu bemerken, dass es sich nicht um ein separates Problem handelt, also nur um sicherzugehen) :)

Keine weiteren Funktionen, bis die Zweizeiler von 2017, mit denen wir es6-Module und Pfeile verwenden können, nicht mehr verfügbar sind.

Außerdem sieht es so aus, als ob Sie eigentlich testen möchten

Sie stellen die Coverage-Hooks nicht in die Bibliothek. Sie fügen sie in die Testdatei ein.

Wenn Sie eine Abdeckung wünschen, können Sie jest installieren und fertig. Es enthält automatisch alles, was Sie brauchen, und es müssen keine Änderungen an der Bibliothek vorgenommen werden. Coverage-Tools sind so konzipiert, dass sie von außen hinzugefügt werden können, nicht von innen.

Dieser Parser-Generator sollte nicht plötzlich als internes Feature an das node.js -Paket-Ökosystem gebunden werden.

Außerdem ist Coverage ein falscher Wunsch nach einem Parser. Folgendes berücksichtigen:

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

Schreiben Sie jetzt einfach einen Test für Reis. peg versucht zuerst Peanuts , wenn es dann nicht funktioniert, versucht $ peg Shellfish , dann versucht peg Rice

Beachten Sie, dass Sie nur einen Test für Rice geschrieben haben, aber Sie zeigen fälschlicherweise die Abdeckung für alle drei an

Die Art und Weise, wie ein Packrat-Parser (ehrlich gesagt, jeder Parser, der mir einfällt) funktioniert, bedeutet, dass die Abdeckung gefälscht ist

Verschwenden Sie nicht Ihre Zeit

Was das Einfügen von Coverage-Hooks in die Bibliothek betrifft, fügt man sie normalerweise in seine Tests ein, ja, aber wenn ein Parser automatisch generiert wird, wobei einige Zweige als relevant und andere als nicht relevant sind, ist es für den Autogenerator sinnvoll, dies zu erstellen damit diejenigen Projekte, die ihre Parser-Datei nicht ignorieren möchten, dies tun können. Es bezieht sich nicht auf die Abdeckung der Pegjs-Bibliothek (die ihre eigenen Abdeckungsanforderungen hat), sondern auf die Abdeckung der Verwendung der Grammatik durch den generierten Parser.

In Ihrem Beispiel enthält der generierte Parser Codezeilen, um nach „Peanuts“, „Shellfish“ und „Rice“ zu suchen, und wenn sie nicht abgedeckt sind, können sie tatsächlich gemeldet werden.

Es wird eher zu einer offenen Frage, ob eine Regel wie ruleA = ruleB / ruleC überprüfen sollte, ob "ruleA" Fälle mit "ruleB" und "ruleC" hat, oder ob es ausreicht zu überprüfen, dass "ruleA", "ruleB" , und "ruleC" werden alle irgendwie abgedeckt (z. B. wenn es ein ruleD = ruleB / ruleF gibt, kann die Abdeckung von ruleB von einigen Projekten als ausreichend angesehen werden, um zu vermeiden, dass überprüft werden muss, ob es darin enthalten ist "ruleA", besonders wenn es viele Alternativen und Kombinationen gibt).

Was dieses Problem angeht, könnte es eine Eingangsdatei geben, die die Funktion hinzugefügt hat, und eine andere, die dies nicht getan hat.

@brettz9 - Ich wollte gerade sagen "Ich rede mit jemand anderem über dieselbe Sache" und dann wurde mir klar, dass Sie es sind, also werde ich diese Instanz dieser Diskussion zugunsten der ähnlichen Diskussion beenden, die wir führen auf #633 zu haben, wenn dir das in Ordnung erscheint

Ich schreibe dort gerade etwas längeres