Draft: Use cucumber/gherkin parser in Behat #1404
Conversation
ciaranmcnulty
force-pushed
the
cucumber-parser
branch
from
f4df0f2
to
0d1078f
Compare
ciaranmcnulty
force-pushed
the
cucumber-parser
branch
from
fe7aaee
to
b9aefab
Compare
| if: matrix.symfony-version != '' | ||
| run: | | ||
| composer config --global --no-plugins allow-plugins.symfony/flex true && | ||
| composer global require symfony/flex | ||
|
|
||
| - name: Temporary - add ciaran fork |
There was a problem hiding this comment.
DO NOT MERGE with this
|
|
||
| $definition = new Definition('Behat\Gherkin\Loader\CucumberGherkinLoader'); | ||
| $definition->addMethodCall('setBasePath', array('%paths.base%')); | ||
| $definition->addTag(self::LOADER_TAG, array('priority' => 100)); |
There was a problem hiding this comment.
Does it need to be 100? Could it be 50 as with the legacy parser?
There was a problem hiding this comment.
Probably. I think if we were doing 'auto' mode more cleanly we could register both but have older parser be higher priority?
There was a problem hiding this comment.
Should it be even possible to have two Gherkin parsers? How would that work together?
There was a problem hiding this comment.
The highest priority that supports() the resource being loaded wins
IRL the resource is always a file and both parsers will say they can load it
| @@ -97,6 +99,11 @@ public function configure(ArrayNodeDefinition $builder) | |||
| ->useAttributeAsKey('name') | |||
| ->prototype('scalar')->end() | |||
| ->end() | |||
| ->enumNode('parser') | |||
| ->info('Sets which gherkin parser to use if not specified at CLI') | |||
| ->values(['auto', 'cucumber', 'legacy']) | |||
There was a problem hiding this comment.
Yeah I don't like either name :)
Legacy is too harsh but 'behat' is confusing as the new one is used by behat too. Any suggestions?
There was a problem hiding this comment.
Yeah, behat is not my favourite too, but makes it consistent with cucumber? What about if we make it a package name? behat/gherkin or cucumber/gherkin - could be more discoverable this way.
There was a problem hiding this comment.
How about classic?
|
I want to come back to this and implement a CLI flag too; however it's not quite clear how to do that in the container so it might need to be reworked as a runtime switch |
| @@ -1,4 +1,4 @@ | |||
| default: | |||
| gherkin: | |||
| filters: | |||
| tags: ~@php8 | |||
| tags: ~@php8&&~@cucumber-parser | |||
There was a problem hiding this comment.
We should probably handle that with 2 suites running the same scenarios with each parser instead of having only a few scenarios running with the new parser. The tag would then be used only to tag scenarios that require the cucumber parser
There was a problem hiding this comment.
Hm how about a second profile too?
default - runs ~@php8&&~@cucumber-parser
cucumber - includes @cucumber-parser and also enables the config setting?
There was a problem hiding this comment.
yeah, a profile rather than a suite might do it.
This incorporates the compatibility layer from Behat/Gherkin#253 into Behat, as a configuration file flag
The expectation is that at some point in the future we could flip the default behaviour to be 'use the cucumber one if cucumber/gherkin is installed'