fix(addon): relax community addon requirements - #1224
Conversation
|
Install the latest version of pnpm add https://pkg.svelte.dev/sv/c/93f2002da43d3ca0e2469f34fb61ce1aa3d83cc6Open in Note This PR is from a fork. A maintainer must approve approve each commit before it can be built and installed. |
🦋 Changeset detectedLatest commit: 93f2002 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 |
| `Invalid add-on package detected: '${specifier}'\nCommunity add-ons should not have any 'dependencies'. Use 'peerDependencies' for 'sv' and bundle everything else` | ||
| dedent` | ||
| Invalid add-on package detected: '${specifier}' | ||
| Standalone add-ons must not have 'dependencies' in package.json. Everything should be bundled with your add-on.` |
There was a problem hiding this comment.
This check long predates the ./sv export condition. Now that add-ons can co-exist with other libraries in the same package, this check is very much out-of-date.
I think it would be best to just remove this check altogether. However, it would also be nice to add it elsewhere. Perhaps our add-on template can have a post-build check built into it to help guide add-on devs in the right direction?
There was a problem hiding this comment.
a post-build check
like a warning? I was thinking we could have an sv validate cmd for this
|
@sacrosanctic opened #1225 as an alternate way of checking for unbundled deps. this is a different approach from #1224 (comment) |
2 participants
Closes #1210
Description
My initial take is to just relax the check for multi export repos. This doesn't really flag the problem if the addon dev decides to use those dependencies.
I considered static analysis, but it seems complicated to do.
Checklist