Selectize.js: Is this library dead?

[hdodov]

After seeing the amount of issues, PRs and the latest commit, I got worried. What's the current state of Selectize? Forgotten? If I make a PR, will it _ever_ have a _chance_ to be merged?

It's not like I need to change any core functionality at all. I just need a few more options that allow me to disable some features.

[Pictor13]

(I think) it was not maintained by the author @brianreavis since some time but others were delegated. Not being these latter the authors they need more time, to verify that everything is fine and nothing breaks, before merging pull-requests.
But the library is maintained & fixed by the community. And @brianreavis did the last merge requests so maybe he is putting again some energy on it.
Except for that, I don't think he plans to implement the library any further.
But a plugin system is supported, to customize quite deeply the behaviour.

[TakesTheBiscuit]

As Pictor13 says it uses microplugin which imo was a great fore-sight by brianreavis!

check it out;
https://github.com/brianreavis/microplugin.js#loading-plugins

you should be able to do most things by writing your own plugins and either dropping them into the plugins directory and mixing them in or putting into your own release/code

[Pictor13]

Yes, the main limit of it is that (at the moment) you cannot add plugins external to the repository, as plugins can only reside in the selectize.js/src/plugins/ folder. So if one wants custom plugins has to diverge from official release.
Unfortunately the Microplugin, for how good it is (!), doesn't give total overriding freedom, when the plugins are loaded from outside the library: the plugin won't have access to all the Selectize private methods/properties.
But this is due to how selectize is built, and is more a Javascript scope limitation more than a limitation of the library.

Actually I was thinking to see if it's possible to add support for some kind of runtime plugin loading so to allow a configurable path for external plugins. But I am not sure whether it is possible, especially in regards of running tests for the external plugins.
It was just an idea, I didn't really think about its details...

[TakesTheBiscuit]

@Pictor13 I think you're wrong about where a plugin can be loaded from? I'm including my own plugins with the official release with no problem, i simply include them before i instantiate my selectize instances but _after_ i've included the selectize library.

Then when it all gets minified by my gulp file it ends up making no difference where the plugin is stored, to be honest it's not different to just putting the plugin code in my main app.js code before i instantiate selectize

You make a good point about private methods but for the most part it seems to do a pretty good job of fixing minor problems or tweaks

[TakesTheBiscuit]

So pseudo code:

<script src="selectize.min.js"></script>
<script>
Selectize.define('my_plugin_name', function(options)
    {
       ...
   });
</script>
<script src="my_app_main_code.min.js"></script>

Where my_app_main_code.min.js may contain similar to:

var $select = $('#select-something').selectize({
            create: false,
            allowEmptyOption: true,
            plugins:['clear_on_type'],
            onChange: function(value) {
                if (!value.length) return;
            }
        });

[Pictor13]

Yes, you are right; I badly explained what I meant.
My argumentation was referring specifically to the issue with private methods and properties, but I wrote as if the scope-issue was broader; while actually Microplugin does a good job in most of the cases.

I wanted to write a plugin that needed, in the main selectize() method, to reuse and override private methods for taking care of the original input ($input) and I found myself quite limited, or forced to redefine a lot of stuff, not staying DRY.

But maybe not being able to modify the library so deeply was the precise intention of its author.

[pm64]

Getting back to the OP's question as to whether this library is dead .. @brianreavis can you please chime in here? Lots of people count on this amazing library and we'd just like to know where it stands.

[Pictor13]

@pm64 Take a look to #752, the status is explained there.
The author is not going to maintain it or develop it further. But some pull requests are evaluated (see commit history); it just takes time (free time).

Personally, I made a fork, did my changes/fixes, added a pull request, and refer my repository as long as it is not merged.

[joallard]

Closing in favor of #752, thanks for your patience folks