Get Started
Warning: This is alpha software and the API will change. Please use if you like powerful tools, like scanning release notes for breaking changes, and like contributing to fix bugs. Please don’t use if you don’t like the above, but you can read the [Roadmap] for clues on when things will be more stable.
How to Add Kitbook to Your SvelteKit App
Kitbook has a lot of powerful features, but let’s start with the bare minimum to just get going:
npm install -D kitbook@alpha
orpnpm add -D kitbook@alpha
Add the
kitbook()
Vite plugin before yoursveltekit()
plugin:vite.config.jsjsimport {defineConfig } from 'vite'import {sveltekit } from '@sveltejs/kit/vite'import {kitbook } from 'kitbook/plugins/vite'export defaultdefineConfig ({plugins : [kitbook (),sveltekit (),],})You can pass optional configuration settings to the plugin. You will see them referenced throughout the docs and you can read the types if you want to utilize them.
Run your dev server as normal (
npm run dev
) and Kitbook will add asrc/routes/kitbook
folder to add a/kitbook
route to your app - leave these files alone.At this point you can navigate to the
/kitbook
route and see all your Svelte components, including+page.svelte
and+layout.svelte
files - they are also Svelte components with a very importantdata
prop.If you don’t have any app shell components in your root layout file, (e.g. a header), then your routes folder structure is probably good. However, if you have app shell components, then you’ll notice that your Kitbook is also inheriting them. This won’t work and you may need to adjust your folder structure to look like this:
txtsrc/routes/│ (app)/│ ├ dashboard/│ ├ item/│ └ +layout.svelte <-- add app shell components like headers and initialize app only items, like db connections (refers to all layout files like +layout.ts)│ kitbook/└ +layout.svelte <-- initialize everything both your app and Kitbook need, like i18nYou may find it a bit jarring to have your component workbench included in your main app. Kitbook originally worked as a companion app, like all previous art does, but this created a lot of friction I didn’t like.
- I don’t often take the time to start two dev servers and open two tabs. I often only worked in my Kitbook or only in my app, but not both which is the sweet spot.
- Another friction point, is the work required to set up the component workbench with just the right scaffolding to match the main app. It’s annoying to have to keep everything in sync (like i18n) for example. The layout structure above makes it easy to clearly specify what context is needed for components and what is app only.
- This avoids all the compatibility issues other tools have around trying to use SvelteKit specific imports.
Give the combined app and workbench approach a try and see if you like it. If you don’t need the workbench published you can also easily add a script to remove the
kitbook
route folder before building for production.
Let’s move on to learn about Kitbook’s [Viewer] tool which bridges the gap between our app and our component workbench.