allow set configable features for install/uninstall a plugin

[bluelovers]

current XRegExp can't check a plugin already install or not and only can addToken, but can't remove token

hope can have a configable for check plugin is installed and disable or uninstall

[josephfrazier]

Thanks for the report! Since you also opened #240 recently, I assume you're talking about custom plugins like your xregexp-plugin-hanzi-cjk.

You're right in that XRegExp doesn't have any mechanism to manage third-party plugins like this, but you should be able to do it in the plugin itself, by keeping the instance in a cache somewhere (it looks like you're already doing this here?).

I think you can take a similar approach for disabling plugins: Have the plugin export an "uninstall" function that takes XRegExp and removes it from the cache. Then, in your addToken callback, check isInstalled to determine whether the plugin should work or not.

Hope this helps!

[slevithan]

That's a clever workaround, @josephfrazier. Extending on that, multiple custom tokens can check whether the same feature (e.g. Ruby regex syntax) is installed or not, so they can be installed/uninstalled together.

I haven't had much signal on whether custom syntax tokens are useful to people, hence the very minimal controls around them. It would not be difficult to create a removeToken method--you'd just need to introduce a new way to reference tokens such as by allowing them to be given a name when first added. But IMO it might be bad practice to use custom tokens at all without also renaming XRegExp, since otherwise they introduce ambiguity about what syntax and flags are enabled across different projects.

A couple of related things I've considered in the past that would improve the management of custom syntax tokens and flags:

• Allow multiple non-conflicting XRegExp classes. See the related discussion at https://github.com/joecorcoran/judge/issues/6.
  • Ex: const RubyRegex = XRegExp.gimmeAFreshXRegExpYo(); RubyRegex.addToken(…);
• At least allow resetting to factory tokens, using a new XRegExp.resetTokens() or perhaps an undocumented XRegExp._resetTokens().
  • If undocumented, it would still be nice to have this for XRegExp's tests, where it could be run before or after each spec runs to avoid altering syntax and flags for all subsequent tests.
  • To maintain support for Unicode Base’s \p token, we would then need to do one of (1) put Unicode Base’s \p token behind a new method so it can be manually reapplied after calling resetTokens, (2) have Unicode Base override resetTokens so that calling it always reapplies support for \p, (3) have xregexp.js whitelist the Unicode addon as part of the core set of tokens, somehow, or (4) move the definition of \p from Unicode Base to the main library in xregexp.js.

[josephfrazier]

• Allow multiple non-conflicting XRegExp classes. See the related discussion at https://github.com/joecorcoran/judge/issues/6.
  • Ex: const RubyRegex = XRegExp.gimmeAFreshXRegExpYo(); RubyRegex.addToken(…);

I like this idea! It feels cleaner than continuing to keep a shared XRegExp instance even despite having resetTokens. Not exactly sure what the best way to go about it is, though...

---

EDIT: I also realized that for this part to work:

Then, in your addToken callback, check isInstalled to determine whether the plugin should work or not

we'll probably need to add XRegExp to the context that the token handler is called with.