sveltejs / cli

The Svelte CLI
MIT License
244 stars 9 forks source link

Get rid of the `--community` flag #84

Open Rich-Harris opened 1 month ago

Rich-Harris commented 1 month ago

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 commented 1 month ago

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: https://github.com/sveltejs/cli/pull/47#discussion_r1780162746, also see #53

Rich-Harris commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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

Rich-Harris commented 1 month ago

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

benmccann commented 1 month ago

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

Rich-Harris commented 1 month ago

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: