[FEAT] Modernization - Add categories to better filter packages

[kaosine]

Is this feature Currently Implemented in any way with the upstream API Server

• [ ] Yes
• [X] No

Is your feature request related to a problem? Please describe. This is a modernization that would be greatly beneficial to users to filter packages better. It needs to be implemented here first.

Describe the solution you'd like In order to implement this we need to both categorize packages in some way. This would likely rely on services used by these packages or some other manner. See below example of categories:

As well would need language tags attached. The only issue w/this portion is some target multiple or are independent(see Hydrogen and the terminal package maintained by spiker).

This would greatly benefit users looking for specific packages allowing greater filtering to find desired packages. This would then be connected to the UI in some manner of a redesign to be proposed after this is implemented to be discussed upon after the fact.

[confused-Techie]

I know when this was originally brought up on Discord there was some serious talk about some very complex ways to accomplish this task. With my personal favourite being something along the lines of allowing community votes to adding categories to packages.

But I've just realized something, there's a much easier way to accomplish this, that should already be somewhat doable today!

We simply take advantage of the tags that already exist in every package's package.json via the keywords property. Now obviously this isn't perfect, and it has never been used that way before for Pulsar package's, but it would possibly be the easiest way forward to accomplish this task without any huge rewrites or changes.

We just allow these categories to be free form, whatever keywords a package has now become it's tags that enable it to be discoverable via categories.

But while this method is dead simple requiring very little new code, there's a few rather big problems:

1) Since package's have never been published with this usage in mind, the existing keywords may not be helpful to this cause. This means that keywords may be underutilized or otherwise may be useless. Such as keywords like atom or pulsar, which are painfully obvious in this case. 2) If keywords (and thus categories) are totally free form by community members, whose to say we don't have dozens of variations of the same item, such as Snippets, snippets, snippet package, snippetss. 3) This one goes back to the fact that many packages have no active maintainers, proper utilization of this feature would likely never be applied to a large portion of our packages.

---

With those above issues in mind, here's a game plan I think may work to try and address this as much as possible:

To cover future usage:

• We first implement the basic behavior. You can search packages based on Tags or otherwise on the keywords that are available in the package.json. The vocabulary for this data should be tags, as that's essentially what it is.
• Once implemented new packages can take advantage of this new feature. Covering the future usage very well

But to cover the issue of it's free form nature:

Once this feature is established, what we can do with moderate amounts of new code, is stop searching tags directly in the package.json, instead we add another post publish task (like feature detection) that will analyze the tags available and add them to a global tag list.

• This global tag list can then be what's actually used later on for searches by users. Plus would mean we are able to offer a list of tags to casually look through rather than search for.
• When adding new items we can also filter the tags we add, as such to avoid tags like pulsar or atom, but also would allow us, with some effort, to try and reduce similar duplicates like Snippets or snippets. Cases like shown are simple, but become much more difficult if we start to worry about synonyms.

Finally, to cover the package's that won't be updated:

Once there is a global list of tags, and the backend knows how many packages use which tags, we will be able to easily identify the most popular tags on the platform. With this short popular list, then we could do the complex task of enabling community votes. For example, a user views a package on the PPR Website, this package has no tags currently, they could then be given the ability to vote on what tag fits this package best. Then once a package has gotten so many recommendations for the same tag, it could then be added in automatically, which would allow the most popular packages to eventually receive tags.

---

While what I mentioned ends up still being extremely complex, it gives us a few key benefits that I think are undeniable:

• It starts small, allowing the feature to natural expand as time permits, not requiring a huge cost upfront.
• The simplest implementation is also what is recommended in the future, with the focus of future forward enhancements it prioritizes the new packages, as any features of the backend should.
• It also puts to use data that we already have, which I love doing on the backend. As such I'm always finding myself very glad we opted to collect complete package.jsons for every package, instead of a normalized only version.