SvelteKit’s Project Structure

Once you have installed a new SvelteKit project, open the project directory in your preferred editor. Within that folder, you’ll notice files that are commonly found in the root project folder of JavaScript applications such as package.json, .gitignore, and README.md, as well as configuration files pertaining to SvelteKit (svelte.config.js) and Vite (vite.config.js). You’ll also notice three subfolders: static/, tests/, and src/. Let’s look at them in detail in the following sections.

static/

This folder is where you may place static assets such as robots.txt (your guidelines for search engine site crawlers), static images such as favicons, or even a global CSS style sheet. These files should be able to be served “as is.” Files located in this folder will be available to your application logic as if they existed in the root folder of your project, that is, /robots.txt. You can also access them by prefixing the file path with %sveltekit.assets%. Note that if files here are changed, you may need to manually refresh the page to see changes. In some cases, you may even need to restart your development server as Vite has strong opinions about caching. You should not attempt to access files included in this directory programmatically. Rather, the paths should be “hardcoded” wherever the assets here are included.

tests/

Logically, tests from the Playwright package (included in the various prompts we said yes to) are located here. To run the Playwright browser test, use the npm script npm run test. Unit tests from Vitest will be included alongside your source code. For example, if you included a file called utilities.js, unit tests for it would live alongside it as utilities.test.js. Vitest is a package from the developers of Vite that enables simple testing for Vite-based applications. Test-Driven Development (TDD) is an excellent practice to follow to ensure code performs as it is expected to. However, it is beyond the scope of this book.

src/

You will be spending most of your time working in this folder as this is where the core logic for a SvelteKit application lives. There are a few files and directories that should be taken note of at this time:

• routes/
• lib/
• app.html

routes/

The first subfolder to take note of is src/routes/. This directory will contain most files necessary for managing SvelteKit’s file-based routing mechanism. Its sibling folder src/params/ will be covered later on, but for now, assume most logic related to managing the routes of your application is located here. As a brief example, if you’d like to add a static “about” page, then you would do so by creating src/routes/about/+page.svelte containing the appropriate markup and text.

lib/

Svelte components and various other utilities can be placed in the src/lib/ subfolder. This folder may not be present in the skeleton project template so you’ll have to add it on your own. It will be shown in the SvelteKit demo app. By placing your components here, you can easily reference them in import statements later on as the $lib/ alias will be available throughout the application.

app.html

There are more files to cover that we will address later on, but for now, the final mention is app.html. This file serves as the base for the rest of your application to build off of. When opened, you’ll notice it contains references to %sveltekit.head%, which SvelteKit uses for injecting various script and link tags, and %sveltekit.body%, which is used for injecting the markup generated for the application.

To recap, the static/ directory contains files that don’t frequently change, tests/ contains tests from the Playwright package, and src/ contains the source code of your project. Most Svelte components and other utilities you create can be placed at src/lib/ so as to be easily accessed via the $lib/ alias in import statements. If you’d like to add a new route to your application URL, you can do so by creating a +page.svelte file inside a directory with the corresponding name at src/routes/. And finally, your application will need a base to build off. That’s where app.html comes in. I’m sure you’re eager to finally build something, so let’s do it.