[RFC] Structure of a Webstone Plugin #271
Replies: 3 comments 4 replies
-
Some thoughts on the open questions:
Since these changes are in
I would keep PRs related to plugins open and update them once the changes we discuss here are implemented.
Yes, you are right. Nice catch!
That crossed my mind as well. The main change you made to it was to load the CLI from a specific sub directory. Since we move back to a standalone NPM package for the CLI, I think (but please correct me if you disagree) we can drop our fork and use the official gluegun package.
I like it! Webstone as a project is about best practices and outstanding developer experience, we may as well introduce changesets to plugin authors! Let's do it. |
Beta Was this translation helpful? Give feedback.
-
In the given scenario above we would have a rather big difference between generating a new plugin and generating a new app. (plugin is a monorepo, plugin requires |
Beta Was this translation helpful? Give feedback.
-
I've created a reference plugin.
|
Beta Was this translation helpful? Give feedback.
-
Context
Based on problems and issues we have in the current plugin setup we assume changing the structure of them again. There is one main issue we're facing currently: ESM and CJS The
CLI
requiresCJS
, while Sveltekit itself requiresESM
. This makes it quite painful writing a plugin because we need to support both Module-ArchitecturesGoal
The main goal is to find a plugin structure that makes it quite straightforward to develop a new plugin in terms of DevX on the one hand and resolves the issues we have with
ESM
andCJS
on the other.Proposed Solution
Project structure
The suggested folder structure is a mono-repo, having a dedicated project for the CLI-Extensions, and a dedicated Repo for the Sveltekit-Components
The structure of the
package.json
s in the monorepo would be the following:This Monorepo setup would require us the use
pnpm
for convenient monorepo-management.Creation Flow of a new plugin
When generating a new plugin we would have a template project that follows the following flow:
pnpm
setup is a templatecli
-directory is a template repo as well. We would need to think of making the package name dynamic based on the user input. We might want a templating engine here 🤔create-svelte
-package for this again.Use Cases
We're having two potential use cases that occur in plugins:
CLI
needs to be extendedCLI
doesn't need to extendThese scenarios could be handled by using the
private
-property in thepackage.json
of the two projects.Building the packages
We need to decide if we want to use
tsc
or a bundler in the build process.web
-package we can rely on the build-step from Sveltekittsc
because we need to ensure a given folder-structure.Open Questions
CLI
-package so we can callws rest create ...
, otherwise the commands will be added at the top level of the CLI?Next Steps
Additional Resources
Beta Was this translation helpful? Give feedback.
All reactions