cucumber
perl: Languages.pm is not mergable
🤔 What's the problem you've observed?
Currently the generated Languages.pm consists of a single line.
https://github.com/cucumber/gherkin/blob/1cc2ef0153603c5e51818b59ff6d632238491226/perl/lib/Gherkin/Generated/Languages.pm#L1-L7
As a result, when multiple contributors submit changes to gherkin-languages.json their PR's will always conflict. Because PRs are not often looked at this happens more often then you'd think.
✨ Do you have a proposal for making it better?
Consider changing build_languages.pl so it generates the file with some formatting.
Hmm. I actually chose this structure for 2 reasons: to make it as small as possible and, because it's generated, it's not the authoritative source. The other solution is to generate this file during CI and release runs instead of keeping it in the repo as a versioned resource (this is the strategy I use in other projects). Do we really have to generate these files as part of the language update? People seem to regularly submit language updates without regenerating the language files in all implementations anyway. That would kill 2 birds with one stone.
Do we really have to generate these files as part of the language update?
Unfortunately it depends.
For example for Go, yes we have to because it's consumed directly from Git rather than through a package manager. But on the other hand for Java this isn't nessesary, each time the project is build a file is generated using a build step in Maven.
If Perl has hooks to execute Perl code in the build step (I think it's dzil build) we can generate Languages.pm using only Perl.
I haven't tried this, but this does look promising
https://metacpan.org/pod/Dist::Zilla::Plugin::Run
Yes. We could run the "build languages" script just before running anything in the Makefile and include the file in our distribution build procedure.
That's not quite the right solution. Because then if you were to build the project without the make file, it wouldn't work. Using dzil build should produce a working project. Using mvn package for example does because generating the code is part of the build process in the build tool.
Hmm. How does Java deal with the need to have the file around in order to run the test suite? For Perl, I can (and need to) run the test suite straight out of the repository: only the most basic tests are being run after the "build" step, because otherwise the full test data would need to be included in the distribution archive. Which is rather useless, given that they are development time tests.
Maven (for Java) has a generate sources phases that executes before compiling code and running tests. We generate the classes from the languages.json in this phase.