Relax `sv add` requirements

[GauBen]

Hi there!

I'm trying to create a sv add addon for https://github.com/ota-meshi/vite-plugin-svelte-md but it would make my life simpler if some requirements were relaxed:

• The package being published as vite-plugin-svelte-md on npm, I would like npm i and sv add command to point to the same name, i.e. sv add vite-plugin-svelte-md

  Covered by npx sv create --template addon shouldn't require an organization #1101

• Allow a non-empty dependencies record in package.json. I know that they won't be installed, but the ./sv entrypoint will be self-contained. The dependencies record is for the root entrypoint.

  cli/documentation/docs/30-add-ons/99-community.md

  Line 153 in 78f6b7a

  Your add-on must have `sv` as a peer dependency and **no** `dependencies` in `package.json`:

  cli/packages/sv/src/core/fetch-packages.ts

  Lines 29 to 33 in 78f6b7a

  	if (Object.keys(deps).length > 0) {
  	throw new Error(
  	`Invalid add-on package detected: '${specifier}'\nCommunity add-ons should not have any 'dependencies'. Use 'peerDependencies' for 'sv' and bundle everything else`
  	);
  	}

  Also, as @sveltejs/sv-utils is a dependency of sv, it should be possible not to bundle it as well

You can find my WIP here: ota-meshi/vite-plugin-svelte-md#157

[jycouet]

Also, as @sveltejs/sv-utils is a dependency of sv, it should be possible not to bundle it as well

We have to make it more clear why we are doing this. It's to be able to have some breaking change in sv-utils without affecting your add-on. If you bundle sv-utils, you are sure it will work, if you use the one in sv, it's might work.

---

For the rest, yes let's see how to tackel them 👍

[GauBen]

Thanks for the swift reply!

It's to be able to have some breaking change in sv-utils without affecting your add-on

That makes sense. As of now the API is weirdly shaped, some things come from sv (e.g. sv.file, viteConfig) and others from sv-utils (e.g. transforms, svelteConfig) and as a consumer I don't clearly understand why (I first tried to import svelteConfig from sv and failed). The API is still WIP and things will get smoother over time.

As a breaking change in sv is likely to break my addon already, it could make sense to re-export @sveltejs/sv-utils as sv/utils so that this version check does the heavy lifting:

https://github.com/sveltejs/cli/blob/main/packages/sv/src/core/fetch-packages.ts#L39-L45

[sacrosanctic]

I would like to update the API as well, but even pre 1.0, its not nice to have so many breaking changes. So we'll gather more feedback and make 1 bigger breaking change.

I believe the 2 packages are explained somewhere in the docs. The gist is sv is the project and metadata about the project. sv-utils are functions that work on your project.

[sacrosanctic]

Another thing, make of the API's don't have jsDocs, so it's unclear what they do. I will try to add them over time.

[GauBen]

I've been thinking a bit more about this and here's another benefit of not bundling sv-utils. When support for svelte config in vite.config.js was added to the svelte ecosystem, had sv-utils been bundled, my addon would have needed to be updated and re-published to support this feature. If it imports from the sv-utils provided by sv, it gets the feature for free, no re-publication needed.

[sacrosanctic]

Allow a non-empty dependencies record in package.json

@GauBen Can you expand on this?

[GauBen]

I want to add sv add support to an existing library that uses dependencies in its main entrypoint, but not the ./sv entrypoint.

The goal being not having to publish vite-plugin-svelte-md and vite-plugin-svelte-md-sv or something similar

[sacrosanctic]

I see, maybe we can limit this restriction to only ./ entrypoints? Is that even possible, or do we just remove the restriction altogether. I'm not sure why it was there to begin with.

[sacrosanctic]

I have dug through this history and found this

Since we're manually downloading these packages, the one limitation is that we won't resolve any dependencies for these adders. That is to say that external dependencies outside of @svelte-cli/core will not be allowed...
#24

I think I know how to patch this.