Gherkin Laravel Package

Product Decisions This Supports

• Build vs. buy for Gherkin parsing: If the product or internal tooling must read .feature files, this package removes the need to build a parser. It provides a lexer, parser, node model, loaders, caching, and tag/line filters under MIT. Parsing is commodity infrastructure; differentiate on workflow, reporting, and integrations instead.
• BDD and executable-specification roadmap: Supports decisions to expose Gherkin-based acceptance criteria, living documentation, or test catalogs in a PHP product. It is a parser, not a runner—pair it with Behat, Cucumber, or a custom execution layer.
• Standards-compatibility roadmap: Recent releases stabilize GHERKIN_32 and GHERKIN_42 compatibility modes, add Rule node support, and align with cucumber/gherkin parity tests. New projects should plan for GHERKIN_42; LEGACY remains default but is not recommended for new work.
• Localization and global rollout: 40+ native language keyword sets support international teams writing acceptance criteria in local languages. This is a differentiator for products serving non-English QA and product organizations.
• CI/test-selection features: Tag filters, line/range filters, background handling, scenario outlines, doc strings, and data tables enable test selection, impact analysis, and faster CI pipelines without bespoke parsing logic.
• Tooling use cases: Feature-file linting, test catalog generation, documentation extraction, editor/IDE support, migration from legacy Gherkin, AST/JSON conversion, and quality gates on acceptance criteria.
• Dependency and API lifecycle planning: New ParserInterface and DialectProviderInterface APIs, deprecations of FilterInterface/SimpleFilter, and compatibility modes create a clear migration path—but require an owner and version-pinning strategy.

When to Consider This Package

• Consider it when: The stack is PHP; the team uses Behat or Cucumber-style Gherkin; you need to parse rather than execute feature files; you need multilingual keyword support; you need AST nodes, filters, loaders, or caching; MIT licensing and volunteer-maintained OSS are acceptable.
• Strong fit: Internal QA platforms, test orchestration tools, feature-file validators, documentation generators, migration utilities, and PHP services that ingest acceptance criteria.
• Weak fit: Non-PHP stacks; teams needing a full BDD runner rather than a parser; products requiring commercial SLAs; use cases better served by JSON/YAML; custom DSLs that only resemble Gherkin.
• Dependency caution: The index shows 0 direct dependents, but real usage flows through Behat. Treat it as a transitive critical dependency if it sits in the test/QA path, not as a vanity-metric decision.
• Look elsewhere when: You need guaranteed long-term vendor support, native Java/JavaScript/Ruby Gherkin tooling, or a parser with a formal compatibility guarantee beyond the maintainers’ release cadence. Also look elsewhere if the team cannot absorb migration work from LEGACY mode and deprecated filter APIs.

How to Pitch It (Stakeholders)

• For executives: This is a mature, MIT-licensed parser that lets us support standard Gherkin acceptance criteria without building and maintaining a parser ourselves. It covers 40+ languages, has active releases through v4.18.0, and is already the foundation of Behat. It is not a differentiator by itself, but it reduces delivery risk and time-to-market for BDD, QA tooling, and localization. Approve it as an enabler, assign an owner, and budget a small migration effort to modern Gherkin compatibility.
• For engineering: It offers a clean lexer/parser architecture, ParserInterface, dialect providers, loaders, caching, tag/line filters, Rule support, and cucumber parity tests. Use GHERKIN_42 for new work, pin versions, avoid deprecated FilterInterface/SimpleFilter APIs, and add regression tests around feature-file parsing.
• For product: It enables living documentation, localized acceptance criteria, test selection by tags, and feature-file quality checks. Do not use it for runtime business logic or as a test runner. Measure success by parse reliability, migration completion off LEGACY, reduced CI selection time, and fewer malformed feature files reaching review.