Skip to content
This repository was archived by the owner on Oct 20, 2024. It is now read-only.
This repository was archived by the owner on Oct 20, 2024. It is now read-only.

💫 A big rewrite #328

@BlankParticle

Description

@BlankParticle

As the title suggests, I think svelte-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 the tailwindcss 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 from svelte-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 in https://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 or svelte-add-core and ship it as a dependency with svelte-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 one export default defineAdder(), just like how vite does it.
Now to userstand how it helps here is a hypothetical implementation of tailwindcss adder.

import { defineAdder } from "@svelte-add/core";
export default defineAdder({
  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"}`,await generateConfig(/*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 of core 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. Then core 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.

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

Third-party Adders

Third party adders can be boiled down to just a export 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 ❤️

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions