@effect-cucumber/gherkin
v0.10.3
Published
Gherkin feature-file parsing for effect-cucumber. Effect-native; effect is a peer dependency only (ADR-EC-021), never bundled. Uses core effect's FileSystem service interface; depends on no concrete platform implementation.
Maintainers
Readme
@effect-cucumber/gherkin
.feature file parsing and step-text matching for
effect-cucumber, wrapping the official
@cucumber/gherkin and
@cucumber/cucumber-expressions packages rather than
reimplementing them. It is Effect-native: effect is a peer dependency, never bundled and never a hard dependency
(ADR-EC-021), and the package reaches
FileSystem/Path through core effect's own service interfaces, so it depends on no concrete platform implementation
and no test runner — whichever runner package consumes it supplies those.
Most consumers should install @effect-cucumber/vitest instead, which re-exports loadFeature from this
package.
Status
Published on npm as 0.1.0 (pre-1.0: the API can still move). The parse pipeline has shipped. loadFeature(path) returns
Effect<ParsedFeature, LoadFeatureError | StepPatternError, FileSystem.FileSystem | ParameterTypeStore> and
parseFeature(source, uri) returns Effect<ParsedFeature, LoadFeatureError | StepPatternError, ParameterTypeStore> —
Effect-returning since ADR-EC-021,
with the former options? argument replaced by an ambient ParameterTypeStore service since
ADR-EC-023, so a caller provides
both requirements as Layers rather than passing either one. The ParsedFeature contract — correlated
scenarios, steps, rules, and the LoadFeatureError / LoadFeatureWarning surface — is real. Custom parameter
types and step matching have shipped too: ParameterTypeStore.layer([...]) declares custom types as plain data
carried by a Layer (there is no process-wide store), every parse replays that store's definitions into a fresh
registry handed back on
ParsedFeature.parameterTypes, and createStepMatcher matches a step text against every registered pattern
with its arguments already coerced. The DataTable wrapper has shipped too: a step's DocString and data table
arrive on ParsedStep.stepArguments, wrapped and in the source order the feature file wrote them, a DataTable
there answers .raw()/.hashes()/.rowsHash() — this package's own accessors, since .hashes() is not native
to @cucumber/gherkin — and decodeHashes(rowSchema) decodes a table's body rows through Schema, naming the
offending row and column on failure. See spec/roadmap.md for what is built versus what
is only specified.
Install
pnpm add @effect-cucumber/gherkinRequirements
Node >=20.
