As the title suggests, I thinksvelte-add needs some fundamental changes. It is not broken but also not in a good shape, take#312 or#285 for example, they can be fixed with little bit of logic here and there, but that will not fix the fundamental issue that is lack of project context in adders.

The Proposals

Here are some proposals I have, they are individually debatable and I don't expect everyone to agree on everything

Please move away from submodules

Git submodules aren't the best thing to work with. I have read#12 and understand the gist of it, still I think a monorepo would be the best thing. The last thing anyone want to do is deal with submodules shenanigans.
Also on a personal note, when I looked at thetailwindcss adder it took me way long to realized how it worked with only 3 js files and no package.json or anything. Then I opened__run.js and got more confused by the imports outside of the repo, until I realized I had to look fromsvelte-add to userstand what was happening.

my suggestion is to archive the other repos and move everything to this central repo. One of the closest match to this kind of setup can be found inhttps://github.com/catppuccin/userstyles

Better Adder API

Current implementation of adder with__run.js is lacking at many places, what I suggest is to separate out the core utilities in their specific packages like@svelte-add/core orsvelte-add-core and ship it as a dependency withsvelte-add with the Adders.I promise it will make more sense later.

Now for the adders, instead of exporting bunch of random const from bunch of random files, we can have only oneexport default defineAdder(), just like how vite does it.
Now to userstand how it helps here is a hypothetical implementation oftailwindcss adder.

import{defineAdder}from"@svelte-add/core";exportdefaultdefineAdder({name:"TailwindCSS Adder",description:"...",run:async({ args, installPackages, createFile, generateConfig, project})=>{installPackages({name:"tailwindcss",version:"^3.4",as:"dev"},{name:"autoprefixer",/*...*/},/*...*/);project.prettier.installed&&installPackages(/* prettier-plugin for tailwindcss */);args.typography&&installPackages(/* tailwindcss/typography */);/* Same with other options */createFile(`tailwindcss.config.${project.typescript.installed?"ts":"js"}`,awaitgenerateConfig(/*Some Kind of generator with AST manipulation support*/).getCode());/* Same with PostCSS *//* And we are done */}});

We just defined a set of instructions for the adder, now it's the job ofcore to handle everything. We don't need to handle any cases where there is changes in default svelte config, the user is in a monorepo or any other issues. Also the adder is just defining schema, it will not change anything on files. Thencore will look at the schema try to apply it, if anything goes wrong restore original files so that the user is not left with a half broken project.

Checkpoints

Checkpoints is just a fancy term for a test suite for the adder. If we want to check if A adder was run successfully we run this suite which will ensure it.

Fortailwindcss the suite may look like this.hasPackage("tailwindcss"),hasPackage(/*Other ones*/),hasConfigFile(/tailwindcss.config.m?(t|j)s/), etc.
Then for a adder likeskeleton.dev we can just slap it with adependsOn("tailwindcss"), it will ensure tailwindcss is installed before addingskeleton.dev other wise prompt the user to installtailwindcss and run it's adder.

Third-party Adders

Third party adders can be boiled down to just aexport default defineAdder(), We can show user a warning about the third party adder. Otherwise it should be pretty easy to get schema from any third-party adder and apply it.

Extras

• May be Typescript 😅, we might need to rewrite whole codebase, why not introduce Typescript. JSDoc are great but it may be difficult for new contributors. Also everyone is already more familiar with Typescript than JSDoc.

I might have some more ideas which I will edit in later. We can discuss and make changes to this proposal as you like.

Thanks ❤️