maybemaby/Kitted

My personal opinionated SvelteKit starter.

Features:

open-props for styling
@testing-library/svelte for unit testing
class-variance-authority for design systems
Dark/light themes
Server stuff:
- pino for logging
- inngest for serverless queueing
- bullmq for serverful queueing
- oauth4webapi and some wrapper code for OAuth.
  - Github and Google providers included

Developing

Once you've created a project and installed dependencies with npm install (or pnpm install or yarn), start a development server:

npm run dev

# or start the server and open the app in a new browser tab
npm run dev -- --open

To run Inngest local dev:

npx inngest-cli@latest dev

# pnpm
pnpm dlx inngest-cli@latest dev

Building

To create a production version of your app:

npm run build

# Node Adapter
npm run build:node

You can preview the production build with npm run preview.

To deploy your app, you may need to install an adapter for your target environment.

To build the bullmq worker:

npm run build:worker

To build the app container

docker build . -t kitted
# if you want to access localhost databases from the container
docker build . -t kitted --add-host host.docker.internal:host-gateway

Running

Node app:

npm run start:node

Worker:

npm run start:worker

Theming

Theming is done using CSS variables. You can find global variables in routes/+layout.svelte

Environment Variables

SESSION_KEY
GITHUB_CLIENT_ID
GITHUB_CLIENT_SECRET
GOOGLE_CLIENT_ID
GOOGLE_CLIENT_SECRET
INNGEST_EVENT_KEY
NODE_ENV
USE_NODE - Flag for using node adapter

Design Decisions

Why use Open Props and not Tailwind?

There's a lot of starters with Tailwind at this point. I don't mind Tailwind but I think the main part I liked about Tailwind was the nice defaults it gave me while being easy to customize. Open props also provides nice defaults but uses normal CSS (which I like).

Why not use Auth library xyz? (i.e NextAuth, Lucia, Supabase, etc.)

Personal preference, I don't like the APIs these libraries that require integrating with an ORM/Database have. Too much abstraction if all you want is sessions, OAuth, and want custom logic.

Trying to avoid creating a starter kit that requires signing up for too many services. (See reasoning for inngest below.) Anyway, my auth decisions are pretty easy to rip out and override so go wild.

Why use Inngest?

If you go the node hosting route, there's plenty of queueing options available (SQS, bullmq, RabbitMq, etc.) Although you'll have to add a separate worker process.

Of the serverless options, Inngest seemed to be nicest to integrate with, offers a generous free plan, works fine even if you're not serverless, and has local development.

maybemaby / kitted