Conversation
commit: |
🦋 Changeset detectedLatest commit: 6837ecc The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
experimentalexperimental
| @@ -2,5 +2,261 @@ | |||
| title: [create your own] | |||
Co-authored-by: Tee Ming <chewteeming01@gmail.com>
Co-authored-by: Tee Ming <chewteeming01@gmail.com>
Co-authored-by: Tee Ming <chewteeming01@gmail.com>
Co-authored-by: Tee Ming <chewteeming01@gmail.com>
Co-authored-by: Tee Ming <chewteeming01@gmail.com>
Co-authored-by: Tee Ming <chewteeming01@gmail.com>
Co-authored-by: Tee Ming <chewteeming01@gmail.com>
… feat/community-add-ons
Current
Proposal 1
Proposal 2
|
| > [!NOTE] | ||
| > Svelte maintainers have not reviewed community add-ons for malicious code! | ||
|
|
||
| Community add-ons are npm packages published by the community. Look out for add-ons from your favourite libraries and tools. _(soon)_ many developers are building `sv` add-ons to make their integrations a one-liner. You can find them [on npm](https://www.npmx.dev/search?q=keyword:sv-add) by searching for the keyword: `sv-add`. |
There was a problem hiding this comment.
I have never opened a sentence with a bracket before. How does capitalization rule work? Is that even allowed? 😅
There was a problem hiding this comment.
Is that even allowed
You know, in France, we take the right 😅
I was thinking it's a nice "didascalie"
|
|
||
| ### Naming convention | ||
|
|
||
| If you name your package `@your-org/sv`, users can install it by typing just the org handle: |
There was a problem hiding this comment.
| If you name your package `@your-org/sv`, users can install it by typing just the org handle: | |
| Name your add-on as either a sub-package `@your-org/sv` or as a dedicated package `@your-org`. Your users can install it by typing the org handle: |
There was a problem hiding this comment.
I think that the previous sentence was better.
There was a problem hiding this comment.
We can mention it can't be the root package here.
|
|
||
| ```sh | ||
| # npm package: @your-org/sv | ||
| npx sv add @your-org |
There was a problem hiding this comment.
| npx sv add @your-org | |
| npx sv add @your-org | |
| # npm package: @your-org | |
| npx sv add @your-org |
There was a problem hiding this comment.
If you publish your sv addon as @your-org (I do'nt know if it's possible). sv will not pick it up.
you can publish:
# you can publish
@my-org/sv # and you have a shorcut to do "npx sv add @my-org"
# you can publish
@my-org/my-super-cool-stuff # can users will be able to add "npx sv add @my-org/my-super-cool-stuff"There was a problem hiding this comment.
I misunderstood how it works.
| > [!NOTE] | ||
| > Unscoped packages are not supported yet | ||
|
|
||
| ### Export options |
There was a problem hiding this comment.
This section and naming convention could be combined.
There was a problem hiding this comment.
There's 2 sections, "naming convention" and "export options". They feel very similar to me and couldn't refactored together.
|
|
||
| `sv` first tries to import `your-package/sv`, then falls back to the default export. This means you have two options: | ||
|
|
||
| 1. **Default export** (recommended for dedicated add-on packages): |
There was a problem hiding this comment.
| 1. **Default export** (recommended for dedicated add-on packages): | |
| 1. **Default export** (for dedicated add-on packages): |
Who's an example that would do this?
There was a problem hiding this comment.
I thought you could publish to root. You meant having a dedicated repo that publishes to @your-org/sv
| npm login | ||
| npm publish |
There was a problem hiding this comment.
I don't publish, but is there a command we can add here to slightly nudge people to use trusted publishing (and related security features).
There was a problem hiding this comment.
I think it's a bit "out of scope" atm, we already tell a lot. No?
I mean, with pnpm we can also do a few things differently. we can setup changeset, we can setup OICD, we can setup pkg, ...
I think that we show already a lot, so showing the "raw npm" way is already good enough IMO
|
|
||
| See the [official add-on source code](https://github.com/sveltejs/cli/tree/main/packages/sv/src/addons) for some real world examples. | ||
|
|
||
| ## Architecture |
There was a problem hiding this comment.
combine with project structure
There was a problem hiding this comment.
You think so?
I link it to be a bit separate... but maybe it's too much down atm?
But why not merging under the project structure?
There was a problem hiding this comment.
incase i messed it up again, im talking about architecture+project structure
Co-authored-by: Scott Wu <sw@scottwu.ca>
Co-authored-by: Scott Wu <sw@scottwu.ca>
Co-authored-by: Scott Wu <sw@scottwu.ca>
… feat/community-add-ons
I think that proposal 2 would be great 👍 |

Closes #184
Description
experimentalphase!Checklist