Pegjs: 기능: pegjs 파일의 런타임 요구

나는 이것을 허용하지 않는 것이 좋습니다.

@ExE-Boss : 우리의 사용 사례의 경우 테스트용일 것입니다(또한 이것이 pegjs 리포지토리라고 언급했는지 확실하지 않습니다.)

이것이 PEG.js 리포지토리 라는 것을 알고 있습니다. 이것이 바로 제가 여기에서 이것을 구현하는 것을 반대하는 이유입니다.

좋습니다.

2017년 es6 모듈과 화살표를 사용할 수 있는 2줄이 나올 때까지 더 이상 기능이 없습니다.

또한 실제로 원하는 것이 테스트 인 것 같습니다.

라이브러리에 커버리지 후크를 두지 않습니다. 테스트 파일에 넣습니다.

적용 범위를 원하는 경우 jest 설치하면 됩니다. 필요한 모든 것이 자동으로 포함되며 라이브러리를 수정할 필요가 없습니다. 커버리지 도구는 내부가 아닌 외부에서 추가되도록 설계되었습니다.

이 파서 생성기는 내부 기능으로 갑자기 node.js 패키지 생태계에 연결되어서는 안 됩니다.

게다가 커버리지는 파서에 대한 잘못된 욕망입니다. 다음을 고려하세요:

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

이제 쌀에 대한 테스트를 작성하십시오. peg 은 먼저 Peanuts 를 시도한 다음 작동하지 않을 때 peg 는 Shellfish 를 시도한 다음 peg 는 Rice 를 시도합니다.

Rice 에 대한 테스트만 작성했지만 세 가지 모두에 대한 적용 범위를 잘못 표시하고 있습니다.

packrat 파서(솔직히 내가 생각할 수 있는 파서의 방식)가 작동하는 방식은 적용 범위가 가짜임을 의미합니다

시간을 낭비하지 마세요

라이브러리에 커버리지 후크를 넣는 한 일반적으로 테스트에 넣습니다. 하지만 파서가 관련성이 있는 일부 분기와 그렇지 않은 분기로 자동 생성되면 자동 생성기가 이것을 생성하는 것이 합리적입니다. 파서 파일을 무시하고 싶지 않은 프로젝트는 그렇게 할 수 있습니다. 이는 pegjs 라이브러리(자체 적용 요구 사항이 있음)의 적용 범위와 관련이 없지만 생성된 구문 분석기의 문법 사용 적용 범위와 관련이 있습니다.

귀하의 예에서 생성된 파서는 "땅콩", "조개류" 및 "쌀"을 확인하기 위한 코드 행이 있으며, 포함되지 않은 경우 실제로 보고될 수 있습니다.

ruleA = ruleB / ruleC 와 같은 규칙이 "ruleA"에 "ruleB"와 "ruleC"가 모두 있는 경우를 확인해야 하는지 또는 "ruleA", "ruleB" , 및 "ruleC"는 모두 어떻게든 적용됩니다(예: ruleD = ruleB / ruleF ruleB 의 적용 범위는 일부 프로젝트에서 해당 적용 범위가 내에서 적용되는지 확인할 필요를 피하기에 충분하다고 볼 수 있습니다. "ruleA", 특히 대안과 조합이 많은 경우).

이 문제에 관해서는 기능을 추가한 입구 파일과 추가하지 않은 입구 파일이 있을 수 있습니다.

@brettz9 - "나는 다른 사람에게 이와 같은 문제에 대해 이야기하고 있습니다"라고 말하려던 참이었는데, 그게 바로 당신이라는 걸 깨달았습니다. 그래서 우리가 비슷한 사람을 위해 이 토론을 중단하겠습니다. 괜찮으시다면

나는 현재 거기에서 긴 것을 쓰고 있다