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.
It seems to me that a protocol like
npm:orfile:(orgit:?) already communicates 'not part ofsvitself' 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 thesupabaseentry 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
svintegrations. But maintaining a registry that allows for entries likesupabaseis 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.