Lesson 5 of 9 beginner 4 min read

Shared Modules

$lib alias, server-only code security boundaries ($lib/server), and static asset hosting.

Interactive Laboratory

Live Runtime

Experiment directly with Shared Modules concepts in real time

SvelteKit Full-Stack Pipeline
1. Request
Hook
2. Loader
load()
3. Server
SSR HTML
4. Browser
Hydrate

Shared Modules and Security Boundaries

SvelteKit includes built-in module aliases and security fences to keep your codebase tidy and prevent sensitive backend logic from leaking into client-side bundles.


1. The #lib Alias

The #lib alias maps to src/lib/. It lets you import components and utilities from anywhere without complex relative paths (../../../):

<script lang="ts">
	// Clean import from src/lib/components/Button.svelte
	import Button from '#lib/components/Button.svelte';
	import { formatDate } from '#lib/utils.js';
</script>

2. Server-Only Security Boundary (#lib/server)

Any file placed inside src/lib/server/ or named with .server.ts is strictly prohibited from being imported by client-side code:

// src/lib/server/database.ts
import { Pool } from 'pg';
 
export const dbPool = new Pool({
	connectionString: process.env.DATABASE_PRIVATE_URL
});

If you accidentally import a server module inside a client component (+page.svelte or +page.ts), the SvelteKit compiler will fail the build with an immediate security violation:

Cannot import $lib/server/database.ts into client code

3. Static Assets in /static

Files placed in the static/ directory (e.g. favicon.ico, robots.txt, images) are served directly from the root URL (/favicon.ico).