Get rid of the --community flag

[Rich-Harris]

It seems to me that a protocol like npm: or file: (or git:?) already communicates 'not part of sv itself' adequately, we don't need to add a flag as well. In other words why not just do this?

npx sv add npm:your-npm-package
npx sv add file:./path-to-your-adder

(In the file: case it's nonsensical — it's not from the 'community' if it's only on my local machine. The same applies to things that only exist within an organisation.)

The other example in the docs currently is npx sv add --community supabase. But that feels like a trap: do we award the supabase entry in the registry to the first Supabase integration that someone registers, or do we reserve it for one maintained by Supabase themselves? What if someone comes along with another Supabase integration that is better or more complete in some way — are we stuck with our original choice? How do we resolve conflicts?

It's fine for us to maintain a registry that's just a list of npm packages that happen to be sv integrations. But maintaining a registry that allows for entries like supabase is just a guaranteed source of pain. npm already has a way to solve these problems, up to and including support staff who will step in if someone accuses someone else of squatting on a package name.

[manuel3108]

Another thing that has not been mentioned here is that running npx sv add --community will bring up an interactive prompt to select between different community adders. This could be handled like something in this comment: #47 (comment), also see #53

[Rich-Harris]

Do we really need to list them? Imagine a future in which there are 731 different integrations for everything under the sun, including some duplicates. Listing them on the command line would suck. I'd argue it's much better to list out the built in ones and have a link to a page where people can search through the registry

[benmccann]

One of the other CLIs that I tried (Nuxi perhaps?) had a searchable CLI interface that was pretty slick. Much nicer than having to pull up a website and copy/paste package names.

But I still think we could remove the --community flag. E.g. @AdrianGonz97 had a mock where you pressed C to enter a community screen.

[Rich-Harris]

where you pressed C to enter a community screen

can we maybe treat that as a future nice-to-have? We absolutely don't need to launch with it

[benmccann]

Agreed such a thing is not a launch blocker. I think we should remove the community aspect from the CLI pre-launch.

[Rich-Harris]

This would also give us more space and time to design the right API

[benmccann]

Yeah, that's my main motivation. Coupled with there not actually being any community adders at the moment...

[Rich-Harris]

Alright, sounds like a plan. Recapping conversation from Discord, for when we do get back around to this:

We really don't want to be responsible for maintaining a registry. Even if it's 'light touch' it will be a huge burden — I guarantee it. Instead, we should generate the list automatically from npm, and enforce that people use scopes to publish:

• mitigates potential spam problem because we can easily block bad actors at the scope level
• makes it clear where packages come from, and that they're not our problem
• would allow us to get rid of the npm: prefix — sv add @supabase/svelte-kit. Or if we settled on a default package name like sv we could even do sv add @supabase to install @supabase/sv