Circular dependency between the cli and @cucumber/gherkin?

[temyers]

I think there's a circular dependency for the CLI between this package and @cucumber/gherkin.
Should the CLI be moved to be co-located?

👓 What did you see?

cucumber/gherkin#64

During the implementation of the above, I was attempting to update ast.ndjson generated files for python and javascript versions.
Updates to the Javascript token matcher were not reflected in the acceptance tests.

✅ What did you expect to see?

📦 Which tool/library version are you using?

• See above branch for Gherkin version
• Running using the cucumber/cucumber-build:latest docker container for development environment (using VSCode devcontainers)

🔬 How could we reproduce it?

Steps to reproduce the behavior:

1. Checkout the Python enable markdown acceptance tests gherkin#64
2. cd javascript
3. make acceptance

📚 Any additional context?

Extensive comments in the referenced pull request.

---

This text was originally generated from a template, then edited by hand. You can modify the template here.

[mpkorstanje]

Well. This is a pickle...

[mpkorstanje]

@mattwynne the acceptance tests for Gherkin use npx gherkin-javascript which pulls in the Gherkin version from NPM rather then the one being build locally.

It looks like Gherkin Streams was extracted so it could provide a CLI for Gherkin without being bundled with Gherkin. And so I don't think this module needs to exist. @mattwynne I reckon merging this back into Gherkin makes most sense, but it shouldn't be published. Do you know how to to do that?

[mpkorstanje]

Does look like at least the html formatter is using gherkin-streams. Might be worth to check out what the dep tree looks like.

[temyers]

@mpkorstanje any updates on this one?

[mpkorstanje]

No, I'm too backlogged too look into this right now. Trying to offload a bit of work to other people.

[mattwynne]

@davidjgoss do you have any capacity to get your head around this?

[davidjgoss]

IIRC the motivation for splitting this out wasn't so much to make a CLI separate, but to uncouple Gherkin itself from Node.js streams so that the core Gherkin functionality could be used in a browser (or Deno now, I guess) environment. @aslakhellesoy tell me if I'm making things up!

I'll take a look at this later and see if we can get rid of the circular dep without merging the packages.

Note that eventually we should be able to pivot to WHATWG streams and thus get rid of the Node.js specificness.

[aslakhellesoy]

That’s right. Breaking the node dependency so it can run in a browser (html reports) was the motivation.