cucumber/common: the issue tracker that Cucumber's polyglot repos share
A home for issues that are common to multiple cucumber repositories
At a glance
- What is it?
- cucumber/common is not a library you install. It is the coordination repo where issues that span cucumber-expressions, tag-expressions, gherkin, messages, query and gherkin-utils are filed, and this article explains when that is the right place to put a bug.
- Who is it for?
- File here only when an issue genuinely spans more than one Cucumber library or you cannot tell which repo owns it; if the bug reproduces inside a single library such as gherkin or cucumber-expressions, open it there instead, where the maintainers of that code will see it. Before posting, check the README's library table and search the target repo's existing issues, because cucumber/common has no code, no releases and no install path to fall back on.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 136 days ago.
- What is it written in?
- GitHub does not report a main language for this repository.
Answers come from the project's GitHub data, last synced on September 27, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What cucumber/common actually is, and who files issues there
The repository contains three top-level entries: .github/, CODE_OF_CONDUCT.md and README.md. There is no source tree, no package manifest, no build file. The README opens by explaining that Cucumber is made up of several libraries, many of which are kept in polyglot repositories, meaning multiple language implementations of the same library live together in one repo. cucumber/common is the place those libraries share when a problem does not belong to any single one of them.
The README states the routing rule directly: if you are not sure which repository your issue belongs under, or it cuts across multiple repos, raise it in this repo. That is the entire product. The intended user is someone filing a bug or a design question about Cucumber internals who has already looked at the library list and still cannot pick a target, or who knows the problem touches several targets at once.
This matters because the polyglot layout makes ownership genuinely ambiguous. A behaviour that shows up in a Java step definition and a Go step definition may originate in the shared specification rather than in either binding. cucumber/common exists so that ambiguity does not turn into a bug report filed in the wrong tracker and closed without action.
The six libraries named in the README table
The README lists six libraries, each with a one-line description and a link to its own repository. cucumber-expressions handles pattern-matching for Gherkin steps. tag-expressions parses tag selection queries. gherkin is the parser for Gherkin feature files. messages is the JSON message protocol. query is a query API for messages. gherkin-utils is an API for querying parsed Gherkin documents.
Read that table as a routing map, not as a feature list. Each row points at a separate repository with its own release cadence and its own issue tracker. The README does not describe version compatibility between them, and it does not say which library a given Cucumber implementation depends on at which version. If your question is about that dependency graph, the README is silent, and that silence is itself a reason the shared tracker exists.
The release feed attached to this repository is a good illustration of how uneven the cadence is. The most recent releases listed are gherkin/go/v24.1.0 from 2022-10-10, gherkin/go/v23.0.1 from 2022-03-31 and gherkin/go/v23.0.0 from 2022-03-31. Those are Go module tags for one library, published years before the last push to this repository on 2026-05-17. Activity in cucumber/common and release activity in the libraries it points to are not the same signal.
How routing works: there is no code path to trace
There is no mechanism to describe in the software sense, because cucumber/common has no runtime. The data flow is a human one. A reporter arrives with a problem, reads the README table, and either picks a library repository or stays here. The README's instruction is the only routing logic in the repository.
That design has a consequence worth stating plainly. Nothing in the repository enforces the rule. There is no template in the visible top-level layout beyond the .github/ directory, and no documented triage process in the README. If an issue that clearly belongs to gherkin is filed here, the README gives no described procedure for moving it. The maintainers presumably redirect it, but the documentation does not promise that, and a reader should not assume a fast handoff.
The upside is that the rule is easy to apply. Two questions decide it: does this reproduce inside exactly one of the six libraries, and do I know which one? If both answers are yes, file there. If either answer is no, this repository is the documented destination.
Filing your first issue when you cannot name the owning repo
The README gives no install command, no package name and no version pin, because there is nothing to install. The repository is an issue tracker with a README. If you arrived looking for a dependency, the README points you at the library you actually want, and the homepage at cucumber.io/docs is where the project directs readers for documentation.
The practical first use is filing an issue. The README does not document a command for this, so the work happens in the repository's issue interface on GitHub. The first step is reading the library table and deciding whether your problem maps to exactly one row. If it does, that row's repository is your destination and you can stop here.
If it does not, the second step is checking whether the problem has already been reported. The README does not describe a search procedure, so use the issue search in the repository you are considering, and in cucumber/common itself, before writing anything. A duplicate report in the shared tracker is harder to route than a duplicate in a library tracker, because there is no owning codebase to consolidate it against.
The third step is writing the report. Because the README documents no template, describe three things in the body: which of the six libraries you believe are involved, what you observed in each, and why you could not assign the problem to one of them. That last point is the justification the README's rule asks for. A report that names two libraries and shows the disagreement between them is actionable in cucumber/common. A report that names none belongs in one of the six repositories instead.
Where cucumber/common is the wrong place to file
The most common failure mode is filing here when you already know the answer. If a step pattern fails to match, that is cucumber-expressions. If a tag query returns the wrong set, that is tag-expressions. If a feature file fails to parse, that is gherkin. The README's own table gives you these mappings, and using the shared tracker for a single-library bug moves your report away from the people who maintain that code.
The second limitation is the absence of a stated triage or response commitment. The README does not describe how issues here are routed onward, how long that takes, or who is responsible. A reporter who needs a fix in a specific library gets no guarantee from this repository's documentation that the issue will reach that library's maintainers.
The third is that the repository carries no compatibility information. Nothing in the README says which versions of messages work with which versions of gherkin, or how a binding should pin them. If your question is a version-matrix question, the README does not answer it, and filing it here does not create documentation that does not exist. The last push to this repository was on 2026-05-17, so the tracker is live, but a live tracker is not the same as a maintained compatibility statement.
Alternatives: the library trackers and the Cucumber community channels
The obvious alternative is filing directly in the library repository, and the difference is not cosmetic. Each of the six repositories owns its own code, its own release tags and its own maintainer attention. An issue filed in cucumber/gherkin lands in front of people who read Gherkin parser code. An issue filed in cucumber/common lands in a repository whose only file of substance is a README that tells you to go to cucumber/gherkin. The approach is different because the audience is different: one tracker is scoped to a codebase, the other is scoped to a routing problem.
A second alternative is the documentation site at cucumber.io/docs, which the repository lists as its homepage. That is where the project sends readers who want to understand how the libraries fit together, as opposed to reporting a defect in one of them. If your question is conceptual rather than a bug, the README's own homepage link is a better first stop than either tracker.
Neither alternative covers the case cucumber/common was created for. A cross-library defect has no natural home in a single library tracker, and documentation sites do not accept bug reports.
Maintenance, licence and what upgrading means here
The repository is not archived, and the last push was on 2026-05-17. That is the only maintenance signal available. The README does not state a support policy, a release schedule or an issue-response target, so there is nothing to hold the project to beyond the fact that the tracker is open and has been touched recently.
The licence is MIT. For a repository that contains a README, a code of conduct and a .github directory, the licence has little practical effect on adopters, because there is no distributed artifact to license. If you are reusing text or configuration from this repository, MIT permits that with the usual attribution requirement. This is a description of the licence identifier, not legal advice.
Upgrade cost is close to zero in the software sense, since nothing here is versioned for consumption. The releases listed on the repository are gherkin/go module tags, not releases of cucumber/common itself. Treating a gherkin/go/v24.1.0 tag as an upgrade path for this repository would be a category error; that tag belongs to the gherkin library, which has its own repository, its own README and its own upgrade notes.
Editorial conclusion
File here only when an issue genuinely spans more than one Cucumber library or you cannot tell which repo owns it; if the bug reproduces inside a single library such as gherkin or cucumber-expressions, open it there instead, where the maintainers of that code will see it. Before posting, check the README's library table and search the target repo's existing issues, because cucumber/common has no code, no releases and no install path to fall back on. The repository layout is .github/, CODE_OF_CONDUCT.md and README.md, so the README table is the only routing document you get.
Frequently asked questions
What is cucumber/common used for?
It is the shared issue tracker for Cucumber's polyglot libraries. The README says to raise an issue here if you are not sure which repository it belongs under, or if it cuts across multiple repositories.
Do I need to install cucumber/common?
No. The repository contains only .github/, CODE_OF_CONDUCT.md and README.md, with no package manifest or build file, and the README gives no install command.
Which Cucumber libraries does cucumber/common cover?
The README table lists six: cucumber-expressions, tag-expressions, gherkin, messages, query and gherkin-utils. Each of those lives in its own repository.
Where should I file a bug in the Gherkin parser?
In the gherkin repository, which the README lists as the parser for Gherkin feature files. cucumber/common is only for issues you cannot place or that span several repositories.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/cucumber-common)