CodeVetter · Repo Unpack · System map
sveltejs/svelte
The repo is a pnpm workspace (`pnpm-workspace.yaml` globs `packages/*` and `playgrounds/*`) with exactly one real package, `packages/svelte`, plus a Vite sandbox playground and a Node benchmarking harness at the root. The package has two runtime boundaries encoded in its `exports` map — `browser`/`worker` conditions split every entry into client and server implementations — and a third, the compiler, which is deliberately firewalled from runtime code by a custom ESLint rule. Storage is entirely file-based: there is no database; the only persistent artefacts are compiled test fixtures under `tests/*/samples/*/_output/`, generated docs under `documentation/docs/98-reference/.generated/`, and the checked-in `types/index.d.ts`. External integrations are all build-time libraries (acorn, zimmerframe, esrap, magic-string, devalue) rather than services. Deployment is npm publish via Changesets on push to `main`.
- The published artifact is unbundled ESM source: `packages/svelte/package.json` sets `"main"`/`"module"` to `./src/index-client.js` and its `files` array ships `src` directly, so consumers import the raw runtime sources rather than a bundle.
- Client/server split is done entirely through export conditions — `.`, `./legacy`, `./reactivity`, and `./store` each map `worker` and `default` to `*-server.js` and `browser` to `*-client.js` (e.g. `./src/index-server.js` vs `./src/index-client.js`).
- The compiler's public surface is five functions exported from `src/compiler/index.js`: `compile` (L23), `compileModule` (L69), `parse` (L117), `parseCss` (L131), plus re-exported `preprocess`, `print`, and `migrate` (L202).
- Compilation is a fixed three-phase pipeline — `_parse` from `phases/1-parse/index.js`, then `analyze_component` (2-analyze/index.js:333), then `transform_component` (3-transform/index.js) — with `state.reset()` called first to clear module-global compiler state.
- Codegen forks per target inside `transform_component`: `options.generate === 'server'` dispatches to `server_component` in `3-transform/server/transform-server.js`, otherwise `client_component` in `3-transform/client/transform-client.js`; both emit an ESTree program that `esrap`'s `print` serialises with a source map.
- The runtime reactivity core lives in four files — `internal/client/runtime.js` (866 lines: `get`, `update_reaction`, `update_effect`, `is_dirty`), `reactivity/sources.js`, `reactivity/deriveds.js`, and `reactivity/batch.js` (1475 lines, the `Batch` class and `flushSync`).
- Signal identity and lifecycle are encoded as bitflags in `internal/client/constants.js` — `DERIVED`, `EFFECT`, `RENDER_EFFECT`, `BLOCK_EFFECT`, `BRANCH_EFFECT`, `BOUNDARY_EFFECT`, `CLEAN`/`DIRTY`/`MAYBE_DIRTY`, `ASYNC`, `ERROR_VALUE` — rather than as distinct classes.
- Server rendering is a string-accumulating `Renderer` class (`internal/server/renderer.js`) with a private `#out` array and a separate `head` sub-renderer; `render()` in `internal/server/index.js:71` is a thin wrapper over `Renderer.render`.
- Build commands: `pnpm build` at root fans out to `packages/*`; inside `packages/svelte`, `build` = `rollup -c && pnpm generate && node scripts/check-treeshakeability.js`, where rollup produces only the UMD `compiler/index.js` for CommonJS/browser consumers.
- `pnpm generate` is a three-step codegen chain: `scripts/process-messages` (markdown → `errors.js`/`warnings.js` + docs), `scripts/generate-types.js` (dts-buddy), and `scripts/generate-browser-support.ts` (web-features → docs page).
- Tests run from the repo root via a single Vitest config that aliases every `svelte/*` import back to `packages/svelte` source using the package's own `exports` map, and picks the `server` export when the importer path contains `_output/server`.
- Deployment shape is npm publish driven by Changesets: `.github/workflows/release.yml` runs on push to `main`, calls `changesets/action` with `pnpm changeset:version` / `pnpm changeset:publish`, and sets `NPM_CONFIG_PROVENANCE: true` with `id-token: write`.
- The only non-library workspace member is `playgrounds/sandbox`, a Vite + `@sveltejs/vite-plugin-svelte` app that consumes `svelte` as `workspace:*` and excludes it from `optimizeDeps` so source edits are picked up without a dev-server restart.
- Benchmarking is a separate root-level Node harness (`benchmarking/run.js`) that forks each benchmark into its own child process 'so that heap/GC/JIT state from one benchmark cannot contaminate the others', across compiler, reactivity, and SSR suites.
- There is no persistent datastore anywhere in the repo; the closest thing to a storage layer is `compile_directory` in `tests/helpers.js`, which wipes and rewrites `<sample>/_output/{client,server}` on every test run.