Use RegExp.source to represent regular expression in messages

[mpkorstanje]

⚡️ What's your motivation?

The forward slash is used to denote the start and end of the regex expression in TypeScript, but isn't part of the regular expression itself.

Fixes: cucumber/compatibility-kit#153

🏷️ What kind of change is this?

• 🐛 Bug fix (non-breaking change which fixes a defect)

♻️ Anything particular you want feedback on?

Reading MDN RegExp I see that the string representation also includes flags such as case in sensitve and global. e.g: /pattern/ig. So we are losing some information here.

Are flags allowed when using Cucumber JS? If so, what would that impact?

📋 Checklist:

• I agree to respect and uphold the Cucumber Community Code of Conduct
• I've changed the behaviour of the code
  • I have added/updated tests to cover my changes.
• My change requires a change to the documentation.
  • I have updated the documentation accordingly.
• Users should know about my change
  • I have added an entry to the "Unreleased" section of the CHANGELOG, linking to this pull request.

[davidjgoss]

This is a tricky one.

Flags are allowed and the RegExp is used as-is so they are honoured - I did a quick test to confirm with the case insensitive flag. Editors aren't necessarily aware of this though e.g. IntelliJ didn't recognise it as a matching step.

Just using the pattern rather than the whole literal in the message would have no impact functionally as we still use the original RegExp for actual work. It would make the messages a bit incomplete but seems like an edge case to me. To address the gap we could add a flags field to this object in the schema but I'm not sure it's worth it, and we'd just be moving the "cross platform consistency" problem over to that field.

[mpkorstanje]

Yeah. That's fairly fundamental, each language has a different regex engine. We can't make that consistent.

Can we omit the slashes if there are no flags? Or come up with a CCK specific solution?

[davidjgoss]

Can we omit the slashes if there are no flags?

I think that's a good compromise.

We could check the flags prop of the RegExp and if truthy use the full string, otherwise just the pattern.