feat: support for lookarounds and non-capture groups

[PaulJPhilp]

Summary

Adding support for look-arounds:

• positiveLookahead
• negativeLookahead
• positiveLookbehind
• negativeLookbehind

Adding support for non-capture groups.

Checklist

• Implementation
• Tests (pattern and matching)
• API docs
• README docs
• Example docs & tests

Test plan

Adding one test file for each function:

• positive-lookahead.test.ts,
• positive-lookbehind.test.ts,
• negative-lookbehind.test.ts,
• negative-lookahead.test.ts,
• non-capture-group.test.ts

[mdjastrzebski]

@PaulJPhilp Do you think we need explicit nonCaptureGroups as a feature. We already do it implicitly when needed (e.g. applying quantifiers like zeroOrMore) to non-atomic values. What would be the benefits of having this as an explicit feature?

[mdjastrzebski]

How about lookahead for positive one and negetiveLookahead for negative one, mimicking Swift Regex Builder in naming?

[mdjastrzebski]

@PaulJPhilp awesome that you contributed this PR. I've left some comments.

Could you also prepare some meaningful, real-life example of usage for lookaheads/look behinds? Like we have in Examples.md and example-xxx.test.ts.

[PaulJPhilp]

My preference is to keep noncaptureGroup. It's in most RegEx docs and examples. I think less experienced coders will be confused by it's absence.

[mdjastrzebski]

@PaulJPhilp before making a call on this I want to clarify the reasoning behind adding nonCaptureGroup is only to have it as explicit construct because people referencing regex expressions might be looking for it? Is there any other benefit for having it?

BTW thx for adding examples 🔥

[PaulJPhilp]

I use it for structuring and debugging. A form of a no-op. I prefer it to using '[Element1, Element2]' form but this is just a personal preference. The main documented use case (which I haven't used) is for asserting a repeated pattern which, as you say, can be accomplished in other ways. I can support either decision but prefer completeness. If it's not kept, I think a note on alternatives would be helpful. Paul

…

On Tue, Feb 27, 2024 at 4:05 AM Maciej Jastrzebski ***@***.***> wrote: @PaulJPhilp <https://github.com/PaulJPhilp> before making a call on this I want to clarify the reasoning behind adding nonCaptureGroup is only to have it as explicit construct because people referencing regex expressions might be looking for it? Is there any other benefit for having it? — Reply to this email directly, view it on GitHub <#64 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BA6V6ZWHA6D3NYEMBF62DULYVWOVDAVCNFSM6AAAAABDNUPAQGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRWGA4DGNRWGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.39%. Comparing base (5a56d68) to head (187bfc6).

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #64      +/-   ##
==========================================
+ Coverage   99.32%   99.39%   +0.06%     
==========================================
  Files          10       14       +4     
  Lines         149      165      +16     
  Branches       40       40              
==========================================
+ Hits          148      164      +16     
  Misses          1        1              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mdjastrzebski]

Looks great! 🔥

I've decided to remove nonCaptureGroup but to specifically note in the docs that this is not needed, on order to resolve potential issues from people looking for it.

Huge thanks especially for really advanced examples.