Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

allow set configable features for install/uninstall a plugin #239

Open
bluelovers opened this issue Apr 24, 2018 · 3 comments
Open

allow set configable features for install/uninstall a plugin #239

bluelovers opened this issue Apr 24, 2018 · 3 comments

Comments

@bluelovers
Copy link

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
Copy link
Collaborator

josephfrazier commented Apr 24, 2018

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
Copy link
Owner

slevithan commented Apr 25, 2018

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 Ruby -> JavaScript regexp support judgegem/judge#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
Copy link
Collaborator

josephfrazier commented Apr 26, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants