/x/ should be curated

In my opinion, /x/ should be a strictly curated list of modules, instead of “all” modules being accepted. Due to the nature of deno modules - which is importing by URL - this wouldnt be an issue at all, and would also help keep things decentralized, which is one of deno’s main points. If this isn’t wanted, we should then have something along the lines of /curated/.

[Yamboy1]

+1 That’s what I had originally thought deno /x/ was, a more curated list of modules. Personally I’m not a big fan of the whole nodejs philosophy of lots of micromodules that everyone uses, is-number, is-promise etc come to mind, many of which are already on deno.This caused the issue with left-pad, as well as issues with outdated modules using vulnerable dependencies. I also don’t believe these are in line with the deno philosophy, but please correct me if i’m wrong here.

My proposal with /x/ is that it should be more curated. Part of the reasoning behind this is because /x/ at the moment is hosted directly on deno.land, making it seem official, even though it is just a github mirror. On an official site I would expect the list to be more select, with packages that both align with the deno philosophy, and just nicely accompany the stdlib (i.e. not too many unnecessary external dependencies).

Another important feature to me is maintainability. I’m thinking that /x/ should be like a secondary, community based stdlib, with more high level packages, for example, discord clients, web frameworks, moment, more complex logging frameworks, etc etc. Just like the stdlib, these should be maintained, and stay maintained throughout their time in /x/, just like the stdlib are. Otherwise, we end up with outdated modules with security dependencies that can’t be easily fixed. Or if they are fixed, a new fork of the module is required, and the original still stands…

My next point is to do with namesquatting and the perceived officialness (is that a word lol) of /x/. Because /x/ is hosted on the official deno website, it has a reputation to stand up to. If deno.land keeps going at the rate it is, it’s literally just a mirror for all of github, and there are other services out there to do that, such as https://denolib.com and even just using github raw files. These services exist, why should the official deno /x/ replicate these, especially as I can imagine people complaining about name squatting. Name squatting wouldn’t be an issue with this curated repository, because only packages that will be maintained in the future will end up on there.

[ry]

Won’t fix. We want to allow an open module registry like NPM. We can provide a curated list elsewhere.