Delete duplicate copy of vite-plugin-svelte

[benmccann]

Should we delete this one or this one the official home now that the repo has been opened up? We probably don't need two copies 😄

CC @dominikg

[Rich-Harris]

i'll let @dominikg field that one — i think we're all on the same page that it would be ideal to have @sveltejs/vite-plugin-svelte, but whether it's easier to get there by deleting this one and bringing @svite/vite-plugin-svelte back in or updating the one in this repo is something Dominik would know best

[dominikg]

two copies are indeed not needed. But depending on how we proceed this directory could get updated instead of deleted.

I'll just add some thoughts here to start a discussion and get a better picture of what the final @sveltejs/vite-plugin-svelte picture will look like. Sorry, this could get long.

Currently @svitejs/vite-plugin-svelte lives in a monorepo set up after vites own repo structure so there are some differences that need to be taken care of if it was to move here

A) Move vite-plugin-svelte into kit

1. build

• change to rollup from esbuild (easy and already done in this directory)
• vite-plugin-svelte types are generated with "@microsoft/api-extractor" (maybe this could be something to adopt kit wide, or remove for manual types)

2. test

• jest setup with globals and test projects in playground subpackages isn't suitable in this repo, but there have to be generic tests for vite-plugin-svelte as it is general purpose and useful outside kit

3. release

• replace manual release script + changelog with conventional-changelog with changesets approach (not really sure how that works best, someone with experience in changesets chime in?)
• ensure vite-plugin-svelte can be released independently from kit

4. ci

• separate pipelines for kit and vite-plugin-svelte or always both

6. docs

• should there be a separate vite-plugin-svelte section in the dos or everything in the readme of vite-plugin-svelte

7. issue tracking

• as vite-plugin-svelte is general purpose, there will be issues not related to kit, tag them?

B) Create a separate sveltejs/vite-plugin-svelte repo (similar level as sveltejs/rollup-plugin-svelte)

• initialize it as a fork of svitejs/svite
• remove everything that's not related to vite-plugin-svelte
• update package.json with correct names and urls

Pros:

• separate issue tracker
• docs
• ci

Cons:

• differences in setup from kit are not great for maintainers working on both, but some like the changesets could easily be ported there
• requires linking when testing unreleased things (easier now that vite-plugin-svelte repo uses pnpm)

cool stuff that only exists in one of the monorepos and could be shared/reused

• kit release action (fully automated releases, wohooo)
• svite ci pipeline pnpm store caching
• svite prettier conf with .svelte support

crazy ideas

Instead of a separate monorepo just for vite-plugin-svelte it could be a shared monorepo for rollup-plugin-svelte too, that could enable to reuse some code between the two plugins @rixo

Disclaimer

I'm not trying to dictate anything here and i think we're all set on the goal that a canonical and officially maintained @sveltejs/vite-plugin-svelte is in the interest of both the svelte and the vite communities. I'm looking for the best way to provide this within the svelte org that enables independent development of both kit and vite-plugin-svelte without causing more friction than neccassary. Opinions welcome

[dummdidumm]

I'm in favor of having it in a separate repo after things have settled. Although Kit integrates it, it can be used alone and in separate use cases. I also don't think that after the initial phase the vite plugin would change that drastically that people need to test it with kit locally all the time (and if so, those would be rare cases).

[Rich-Harris]

I don't have strong opinions — since @dominikg is likely to be the most active contributor, at least in the near term, whatever is easiest for you is probably best.

The monorepo does have some nice things going for it...

• the automated release workflow is really nice (easy to do independent releases of kit/plugin, but also really easy to do synchronised releases for the cases where that's necessary)
• no need to link, which reduces friction particularly for more casual contributors
• the separate issue tracker could be a blessing and a curse — people won't always know where to file an issue, especially if they're experiencing a plugin issue via Kit. Having all issues be visible in one tracker might make it easier to avoid dupes etc, and probably gives us slightly better visibility.

...but as I say, I'm fairly indifferent

[benmccann]

I don't have any strong feelings on this either. I'd be inclined to say we make it a separate repo just because that's how it is now and I don't want to do any work of changing it 😄

[dominikg]

I'm leaning towards a separate repo aswell.

• it's less effort now, i can just push a cleaned up version of the svite repo there and it's even going to preserve the history thats already been made
• while the separate repo creates more friction for contributors from within svelte org, it is less friction for outside contributors who have usecases that do not involve kit.
• i'm going to adopt the release workflow and changesets for a more uniform release management within the svelte org if preferred

should we get this started then? someone creates the repo and i start the move?

[Rich-Harris]

@dominikg i just created https://github.com/sveltejs/vite-plugin-svelte and invited you — it's a private repo for now, i didn't know if you preferred that. if not we can just open it up

[benmccann]

In that case, I'll go ahead and merge this

[dominikg]

if testminutes are billed to the org, immediate public please, otherwise i can take my time to clean it up a bit there first