Feat - Community add-on

[jycouet]

Let's draft something, and add notes... along the way.
Link with: #184

---

First thing first, I managed to have a local community add-on up and running locally 🎉

So, a lot of things are already in place, we "just" need to tweak and allign things.

---

Todo...

A/ distribute community add-on

sv can scaffold a lot of things... Why going through degit when we could have it in sv itself, and do something like:

• With just the name of the project, we can tune already a lot of things
• workspace:* deps would be easier to overcome

B/ publish @sveltejs/cli-core

• Maybe we can start with a pkg.pr.new only as "beta" ?
• finish PR with svelte parser and serializer (cc @manuel3108)
  • chore: update esrap #620
  • chore: use parse & print from svelte/compiler #568
• publish on npm

C/ Check Windows

• Failed linking community add-on template #63

D/ create & add & --community flag

• Get rid of the --community flag #84
  • As suggested npx sv@latest add @supabase could install @supabase/sv
  • could probably check also for sv-[PACKAGE_NAME], similar to create-[PACKAGE_NAME]
  • still have to conclude about npm: prefix. (file: is also really nice for testing purposes)
• mix official & community should probably work as well: npx sv@latest add vitest @supabase
• maybe let's keep create & add as separate cmd for now (not part of this effort)
  • create & add in one go #689
• Improvements for choosing community adders #53
  • maybe this issue is a bit outdated at this stage
• protocol file: is quite usefull for local testing

E/ Loading community adders & cli-core version

• Investigate loading community adders from CDN or with npx #77
• Validate community adder's version of @sveltejs/cli-core #55
• re-add tar-fs (chore: remove tar-fs #577) or some alternative

F/ Check for TODO JYC

• addon project type: ts / JSDoc / none
• remove community-addons folder ?

=> Let's see what to do there.

---

My steps for now

pnpm build && rm -rf temp/new-add-on && pnpm sv create temp/new-add-on --template addon --no-add-ons --install npm
cd temp/new-add-on
npm run create
npm run add
cd demo
npm run dev

[changeset-bot]

⚠️ No Changeset found

Latest commit: 0630be5

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[pkg-pr-new]

Open in StackBlitz

npx https://pkg.pr.new/sveltejs/cli/sv@684

npx https://pkg.pr.new/sveltejs/cli/svelte-migrate@684

commit: 0630be5

[svelte-docs-bot]

Preview: https://svelte-dev-git-preview-cli-684-svelte.vercel.app/

[manuel3108]

First of, thanks for making the effort and putting everything together. I made some really minor changes to the PR description (such as linking issues / prs)

A/ distribute community add-on

I love a). Not sure why didn't had the idea earlier, but this seems to be a pretty clean way.

B/ publish @sveltejs/cli-core

There were some concerns (I think from Ben and Rich) if this is really necessary. There was a thought about maybe re-exporting this from sv and only publishing sv (as we do now)

C/ Check Windows

Yes. Windows....

D/ create & add & --community flag

I do think this one of the important parts. Especially if you think what i.e. mdsvex should put in the docs for creating / adding that tool.

E/ Loading community adders & cli-core version

This is another discussed topic. Currently we are basically downloading and extracting community addons by hand (thus the two dependency requirement: sv and @sveltejs/cli-core I think), so that we don't need to bother ourselves about installing further deps.

In the past we discussed if community addons should be self-executing. So should @storybook/sv directly execute prompts? But we decided against it, as the core addons would become out of date to easily.

Considering that those two points are both non-optimal, is there another way we should consider?

Further thoughts

• Considering that we are more and more becoming a library, we should re-consider #80 (svelte motive: TS for apps, JS for libs). Ben was hoping that nodes strip types feature could help us out here, but I did not have the ability to check it
• Another thing that has come up in the past is the style guide. As long as our public stuff aligns (which i think it should) we can do this at a later point