Open Rich-Harris opened 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
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
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.
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
Agreed such a thing is not a launch blocker. I think we should remove the community aspect from the CLI pre-launch.
This would also give us more space and time to design the right API
Yeah, that's my main motivation. Coupled with there not actually being any community adders at the moment...
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:
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
It seems to me that a protocol like
npm:
orfile:
(orgit:
?) already communicates 'not part ofsv
itself' adequately, we don't need to add a flag as well. In other words why not just do this?(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 thesupabase
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 likesupabase
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.