Swap bootstrap-tagsinput to an alternative

[andreslucena]

The JavaScript library that we use for tags, bootstrap-tagsinput, isn't maintained anymore: for the last 5 years it isn't receiving any commit in the main branch, it wasn't updated to Bootstrap 4 (released in 2018), and it has a security vulnerability.

For mitigating the last issue, @alecslupu went ahead and proposed a fork (see #8672), but I don't like it as it doesn't have much traction:

I don't like it, as it doesn't seem to be getting much traction (100 weekly downloads 3 months after the fork/release vs 16K of the original NPM package), and as far as I see the organization and the author doesn't have much public record in GitHub.

So as I said there, I'm opening a discussion, so we can discuss alternatives.

---

Update for extra information about the vulnerability

This is what dependabot says:

All versions of bootstrap-tagsinput are vulnerable to cross-site scripting when user input is passed into the itemTitle parameter unmodified, as the package fails to properly sanitize or encode user input for that parameter.

Recommendation

This package is not actively maintained, and has not seen an update since 2015.

Because of this, the simplest mitigation is to avoid using the itemTitle parameter. With over 200 open issues and over 100 open pull requests as of 2/2018, it seems unlikely that the author has any intention of maintaining the module. If avoiding the use of itemTitle indefinitely is acceptable, this is a workable solution. If not, the best available mitigation is to use a fork of the module that is actively maintained and provides similar functionality. There are many such forks to choose from available on github..

As far as I see, we're not using the itemTitle parameter, but still we have an unmaintained dependency that we should change.

[alecslupu]

In some areas of our fork, we are sing https://www.npmjs.com/package/slim-select

Integration:

Expanded:

Collapsed:

Without values:

[ahukkanen]

Something like this would also help us improve the admin UX with the <datalist> component we built at #8524 to replace the secondary use case for replacing react-select as explained in the PR. It is used e.g. to select a survey template when creating a new survey.

I think this kind of library would provide much improved UX over the <datalist> component. The only reason we decided to use <datalist> was that we are not adding any extra dependencies than what was agreed for the implementation of #8524.

[andreslucena]

👍🏽 I was just skimming their docs and at least for our use case (text_fields in system for adding files extensions) it could be implemented with the "addable" option.

[andreslucena]

I just search where this is replaced, as far as I see, this is only being used by decidim-core/app/packs/src/decidim/input_tags.js which is only used by decidim-system/app/views/decidim/system/organizations/_file_upload_settings.erb. It's also in the decidim_app-design, but we can ignore that for now.

I don't like having a dependency for only this section, maybe we can find an alternative implementation for this one where we don't replace a dependency with another dependency? (Just thinking out loud)

[ahukkanen]

I support having a dependency for the tags input. It's pretty standard UI component we will need here and there sooner or later, if not only the system module. I think Slim Select (or similar) would be a good option for this.

We also have tag inputs (through the tags module) in our instances where we need a similar component. It's custom built right now on top of Tribute.js which is also still a core dependency. But the Tribute.js implementation needed some workarounds + it's not particularly meant for that purpose + we may want to drop Tribute at some point anyways.

So for me, having a dependency for the tags input would make a lot of sense.

But I support doing some research, evaluation and testing for the component before landing one one. Some options inlcude:

• https://github.com/brianvoe/slim-select
• https://github.com/yairEO/tagify
• https://github.com/okcoker/taggle.js
• https://github.com/bevacqua/insignia
• (...add other options here...)

Some criteria for comparison:

• Popularity (stars, forks, etc)
• Stability (amount of contributors)
• Maintenance activity (last release, last commit, amount of issues, amount of PRs, etc)
• Lines of code / amount of dependencies (how easy it is to bring to the Decidim core if the library is discontinued)

Sidenote, this is what happens to all (JS) projects at some point, don't blindly trust the popularity factors:
https://github.com/arendjr/selectivity

And as another sidenote, when we evaluated the different autocomplete options at #8235, it turned out that none of the available options were "perfect", so we just had to stick with what was the least bad option from Decidim's perspective.

[furilo]

In another project we have just migrated to https://github.com/orchidjs/tom-select (to get rid of jQuery).

[Crashillo]

I did both integrations (bootstrap-tagsinput and Tribute) 3-4 years ago. If I remember right, both were initially implemented at the filters sidebar (from the times where adding external libs was the top 😄). Whilst tagsinput and tribute are (or were) slightly different (features and styles), nowadays they should be merged.

I agree @andreslucena about having one dependency - one use is a total nonsense, but in this case, as @ahukkanen suggests, a autocomplete/multiselector library becomes a UX must. I'm saying to get rid of bootstrap-tagsinput and Tribute in favour of one unique lib. I'd say to power this feature also, for instance in the admin' search inputs. Eventually, merge it with autoComplete.js.

Regarding which lib to choose, recently I migrated a select2 to tom-select and it was quite straightforward. Besides, an extra point why I like tom-select is about styling: the search component in slim-select is separated, beneath the original input, unlike tom-select, what is integrated in the input. The least we've to custom the styles, the best.

[andreslucena]

Retaking this issue that I saw again the dependabot alert again.

These are the current contenders:

Name	URL Website	URL NPM	URL GitHub	Stars	Forks	Last release	Last commit	Amount of issues	Amount of Prs	scc Files	scc Lines	scc Blanks	scc Commens	scc Code	scc Complexity
Slim Select	https://slimselectjs.com/	https://www.npmjs.com/package/slim-select	https://github.com/brianvoe/slim-select	729	147	12/21/21	08/16/22	16 / 68	80 / 185	84	38579	682	269	37628	1178
Tagify	https://yaireo.github.io/tagify/	https://www.npmjs.com/package/@yaireo/tagify	https://github.com/yairEO/tagify	2734	383	09/03/22	09/03/22	61 / 939	4 / 131	60	21734	1961	1280	18493	1157
Taggle.js	https://sean.is/poppin/tags	https://www.npmjs.com/package/taggle	https://github.com/okcoker/taggle.js	663	120	01/08/20	03/02/22	4 / 108	1 / 60	27	5507	987	385	4135	267
Insignia	https://bevacqua.github.io/insignia/	https://www.npmjs.com/package/insignia	https://github.com/bevacqua/insignia	666	26	07/07/16	07/13/16	3 / 18	0 / 4	22	2817	438	13	2366	399
Tom Select	https://tom-select.js.org/	https://www.npmjs.com/package/tom-select	https://github.com/orchidjs/tom-select	853	55	10/12/22	10/12/22	4 / 188	5 / 63	122	37313	5723	2918	28672	3555

About the columns:

• Amount of Issues and PRs: Open / Closed
• CLOC (last columns), I used SCC.

Just by looking at the numbers:

1. Slim Select: OK
2. Tagify: OK, seems like the best ratio between popularity and lines of code
3. Taggle: KO, last release more than two years ago
4. Insignia: KO, it's not maintained anymore (from 2016)
5. Tom Select: OK, maybe too big

Just by this quick comparison, I like either Slim Select, Tagify or Tom Select.