Feat - Community add-on #684
Conversation
🦋 Changeset detectedLatest commit: 2fbd7ea The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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 |
commit: |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
0630be5 to
7cf5b27
Compare
This comment was marked as outdated.
This comment was marked as outdated.
manuel3108
left a comment
There was a problem hiding this comment.
Rest will come at a later point.
| title: sv | ||
| --- | ||
|
|
||
| TODO... Yes, I know it's empty, but it's a work in progress! |
manuel3108
left a comment
There was a problem hiding this comment.
This is so cool finally seeing progress in that direction!!! At this point this is only a code review, I havn't tested or played around with anything yet.
Random thought: Addon's for migrations? Obviously not something we should implement here, but we should check that we don't block any imports. But using sv/core and sv/testing seems totally future-proof, so we should be good to go.
Automated testing for community addons? How can we check that we don't break anything for community addons? We should be pretty fine as they are using more or less exactly the same api as the official addons, but maybe you have a crazy idea that could help with that. (I saw the snapshot test, I think im currently more concerned about type missmatches and stuff, although this is a great starging point)
| 'sv': minor | ||
| --- | ||
|
|
||
| feat: community addons are now in preview |
There was a problem hiding this comment.
Are we already at the point where we want to publicize this? I was wondering if we should hide it away for a few releases, so that we can sneak in a few api changes before making that public. Not sure what those are exactly, but i'm sure we will find something.
Apart from that we should consider hiding the create template for community addons. Although I wouldn't consider this that important.
There was a problem hiding this comment.
I was thinking "preview" with "minor" to really state that stuff can still change (Maybe we can update the message?).
All this having in mind that a lot of stuff are already taken care of in this PR.
But we can also do a silent merge (later), and continue tweaking before saying it's preview.
In that case, I would hide the community add-on in prompt not in args, like this we can still play :)
| - run: pnpm exec playwright install chromium | ||
| - run: pnpm build | ||
| - run: pnpm test | ||
| preview-release: |
There was a problem hiding this comment.
I think we should revert this here. I found it always helpful that the preview release get's published before all of the testing is completed after roughly 5 minutes. Also has nothing to do with community addons.
There was a problem hiding this comment.
+1 it's not directly linked with community addons 🫣
It's not after all tests, Just after build & lint (1min)
Because I had a few update of pkg while it was not even building... so everything was broken in pkg
Maybe was just unfortunate?!
revert? no revert? Let me know
| - [`tailwindcss`](tailwind) | ||
| - [`vitest`](vitest) | ||
|
|
||
| ## Community add-ons |
There was a problem hiding this comment.
We should consider extracting this into a separate page, as most of this is relevant for sv add as well.
Also, the docs about the file: protocol should be in the creating addons developer section, not in the user section.
There was a problem hiding this comment.
I'm not sure how to organise all this! :o But yeah, we can move things 👍
I'm using file: protocol as a scaffolding tool. It's not "all users", but I'm sure some people could find this cool and have some usecases. No?
| title: add-on | ||
| --- | ||
|
|
||
| Typically, an `add-on` looks like this: |
There was a problem hiding this comment.
You showed a recording that displayed a lot more info than this is currently doing. I guess you still have some additional progress locally?
There was a problem hiding this comment.
The rest is more in svelte.dev repo.
One thing is sveltejs/svelte.dev#1720 as a minimal step.
Other thing are locally in my svelte.dev repo... We need to speak ;)
Let's keep it open
| // from internals | ||
| export { defineAddon, defineAddonOptions } from './core/addon/config.ts'; | ||
| export { color } from './cli/add/utils.ts'; | ||
| // TODO JYC: move to utils all these bellow? |
| export const svelte = { | ||
| ensureScript: ensureScript as typeof ensureScript, | ||
| addSlot: addSlot as typeof addSlot, | ||
| addFragment: addFragment as typeof addFragment | ||
| }; |
There was a problem hiding this comment.
Why is this not the same as for the other langs? I thought they were setup identically
There was a problem hiding this comment.
It was a test, yes!
Doing this enable to have JSDoc comments that can be used in doc! and in code when user will import svelte 👍
So in core.ts we should never export *. I did only a few JSDoc test and wanted to speak with you do to more ^^
| * const { ast, generateCode } = parse.toml('name = "John"'); | ||
| * const { ast, generateCode } = parse.yaml('name: John'); | ||
| * ``` | ||
| * @jsdocfocus |
There was a problem hiding this comment.
Not sure what this is? I couldn't find any information on this online.
There was a problem hiding this comment.
Very good that you spoted this!
It's also a tentative that I did for doc. When type doesn't really help, I wanted to have a special tag to tell svelte.dev to not display the type, but just the JSDoc.
I didn't manage... But now that I did more on svelte.dev I think I would do it.
Now... Is it useful?! I don't really know :D
Co-authored-by: Manuel <[email protected]>
Co-authored-by: Manuel <[email protected]>
Co-authored-by: Manuel <[email protected]>
Co-authored-by: Manuel <[email protected]>
Main topic
Links & notes along the way
esrap#620parse&printfromsvelte/compiler#751--communityflag #84@sveltejs/cli-core#55tar-fs#577) or some alternativecommunity-addonsfoldersv/coreDo this only for npm addons-> so that things are preparedNext step?
dependOnnot only officials?