Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extract compiler #108

Closed
wants to merge 4 commits into from
Closed

Extract compiler #108

wants to merge 4 commits into from

Conversation

aslakhellesoy
Copy link
Contributor

🤔 What's changed?

Compilation of a Cucumber Expression AST to a RegExp is extracted to two separate classes:

  • AbstractCompiler
  • RegExpCompiler

⚡️ What's your motivation?

In order to fix cucumber/language-service#16 we need to be able to generate a Gherkin step text from a Cucumber Expression. For example, we should be able to generate I have 0 cukes from the Cucumber Expression I have {int} cukes.

This can be done by subclassing AbstractCompiler and generating steps instead of regexps.

🏷️ What kind of change is this?

  • 🏦 Refactoring/debt/DX (improvement to code design, tooling, documentation etc. without changing behaviour)

♻️ Anything particular you want feedback on?

I don't think this is necessary to port to the other languages. Being able to extend the compiler in this way is only needed by the language server.

@@ -10,6 +11,7 @@ import RegularExpression from './RegularExpression.js'
import { Expression } from './types.js'

export {
AbstractCompiler,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we could also export RegExpCompiler? That may be useful sometime?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's only used internally, so I'd rather not. By exposing as little as possible we minimise the API surface to maintain.

Copy link
Contributor

@aurelien-reeves aurelien-reeves left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well done!💪

I guess at the moment, tests relies on former CucumberExpressionTest ones?

Would it worth the cost to refactor the tests in the same way the code has been refactored?

@aslakhellesoy
Copy link
Contributor Author

Well done!💪

I guess at the moment, tests relies on former CucumberExpressionTest ones?

Would it worth the cost to refactor the tests in the same way the code has been refactored?

I don't think it's needed - it's a bit tricky to do since CucumberExpressionTest uses shared test data, and I don't want to port this to the other languages.

@mpkorstanje
Copy link
Contributor

mpkorstanje commented Apr 20, 2022

This doesn't look like a well thought out addition to the public API. Though It's a bit hard to provide constructive criticism, there are no examples of how this would be used.

I don't believe the compiler contains anything that could be reused for this use case. It recursively invokes compile on all nodes of the AST. This is something that could be duplicated relatively easily in another project and would instead depend on the AST rather then an adhoc defined abstract compiler.

Perhaps the language service needs valid ASTs? If so then it might be worth splitting of the validations from the compiler. But again hard to say.

@aslakhellesoy
Copy link
Contributor Author

aslakhellesoy commented Apr 20, 2022

Fair point. The thing I wanted to reuse from the compiler is the traversal and validation, but I'm happy to reimplement the traversal in the language service. The validation isn't needed - it's already done when the CucumberExpression is created.

The only thing I need is to expose the AST. I've expressed some reservations against this in #51 (comment), but it looks like #41 might take a while, so I think we should do it anyway.

What do you think about an updated PR where I just expose the AST?

@mpkorstanje
Copy link
Contributor

mpkorstanje commented Apr 20, 2022

I don't expect #41 to happen anytime soon. I'm less opposed to exposing the AST then you. But it might need some prettying.

@aslakhellesoy
Copy link
Contributor Author

I'm not worried about exposing the AST anymore since 41 has been quiet.

What kind of prettying did you have in mind for the AST?

@aslakhellesoy
Copy link
Contributor Author

Superseded by #109

@luke-hill luke-hill deleted the extract-compiler branch September 1, 2023 11:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Create step documents from steps even if there are no matching step definitions
3 participants