Proposal: include support for plugins

It would be nice to support user-definable plugins, i.e. “Phone Number”

Something like:

const myRegex = SuperExpressive({ plugins: [ phoneNumber ] })
  .startOfInput
  .optional.string('0x')
  .capture
    .exactly(4).group
      .plugin.phoneNumber()
      .newline
    .end()
  .end()
  .endOfInput
  .toRegex();

[francisrstokes]

@jcao219 @floriancargoet @puf17640 I’ve added support for subexpression based modularity in PR #17. It was kind of tricky, but I think I managed to get something that behaves sensibly in a flexible way, and hopefully still quite easy to use.

I’ve written a set of tests which outline the edge cases I could think of. If you notice more, or have an other kinds of feedback, please let me know. I’ll keep the PR open for a little while.

[francisrstokes]

Interesting idea! I’ve been thinking a bit about how this could work, and there would be some challenges

In merging two SuperExpressive instances, as @floriancargoet mentioned, you would have to address some sticking points.

• How do you deal with flags? Are sub expressions able to assert that the entire expression should become global, case insensitive, etc?
• How do you deal with capture groups and back references?
  • Avoiding naming collisions
  • Avoiding indexing collisions, where the primary expression uses capture groups and indexed backreferencing, but the plugin/module does too

// a modular SuperExpressive...
const modularExpression = SuperExpressive()
  .exactly(3).digit
  .capture
    .zeroOrMore.anyChar
    .string('!')
  .end()
  .backreference(1);

// using the module
const mainExpression = SuperExpressive()
  .startOfInput
  .capture
    .range('a', 'z')
  .end()
  .subexpression(modularExpression)
  .backreference(1);

// The module expression creates and backreferences to index 1, but it would actually be index 2 in the main expression

With a plugin based architecture, there would be similar kinds of concerns I imagine that the plugin would be an extension of another class like SuperExpressivePlugin, which would provide a (perhaps more limited) interface. That limited interface might even allow the plugin author to describe that they’d like to modify a flag, or create an explicit capture group namespace, etc.

Personally I’m more inclined to go with merging SuperExpressive instances, because that would allow people to very easily organise their own code in a modular way, and one interface to maintain is always better than 2!