How to contribute

Active contributors: Ryan Carniato, Damian Tarnawski, Dan Jutan

This section is the orientation pack for someone who wants to work in the solidjs/solid codebase. Build, test, lint, and PR mechanics live in dedicated sub-pages:

• Development workflow — branching, commit hygiene, PR expectations.
• Testing — Vitest, type tests, integration imports, benchmarks.
• Debugging — running dev builds, reading the DEV hooks, common gotchas.
• Patterns and conventions — coding style, types, error handling, and the conventions that show up across the runtime.
• Tooling — Turborepo, Rollup, Babel preset, Vitest, Prettier, changesets.

Picking up work

CONTRIBUTING.md is the canonical statement on how the SolidJS organisation accepts contributions. The short version:

1. Submit a proposal first. The maintainers prefer a discussion before code lands so that effort aligns with current direction.
2. Most ecosystem-shaped contributions belong in solidjs-community/*, not in this core repository. CONTRIBUTING.md lists projects looking for help (Solid Aria, Solid Examples, Solid Codemod, Solid Snippets, Solid DSL, Solid Primitives).
3. Documentation contributions go to solidjs/solid-docs-next.
4. SolidStart issues belong in solidjs/solid-start.

That leaves this repo for: reactive runtime fixes, compiler preset adjustments, store internals, SSR rendering, and the solid-element / solid-ssr packages.

Definition of done

Before opening a PR, run:

pnpm install
pnpm build
pnpm test

If your change touches the runtime, also run the type tests (they are part of pnpm test via the test-types Turbo pipeline). If it touches publishing or imports, the integration smoke test in packages/test-integration/test-imports.mjs exercises every published entry point and must still pass.

Finally, add a changeset:

pnpm bump

This invokes @changesets/cli (packages/solid/package.json scripts) and writes a markdown file under .changeset/ describing the version bump and the user-facing release note.

Code review expectations

Pull requests are reviewed by the core team — primarily by Ryan Carniato. Expect:

• Reviews focus on whether the change is a net improvement to the runtime's invariants (no extra allocations in the hot path, no new ways for Owner / Listener to leak across boundaries).
• Tests are required for behaviour changes. Type-tests are the right home for surface-area changes (packages/solid/test/*.type-tests.ts).
• Performance-sensitive changes are usually validated against packages/solid/test/component.bench.ts and packages/solid/bench/ before merge.

Where the codebase lives

A short directory map for orientation:

Path	What it is
packages/solid/src/reactive/	The reactive runtime (signals, memos, scheduler, observable, array reconcilers)
packages/solid/src/render/	Component layer: createComponent, <For>, <Index>, <Suspense>, hydration context
packages/solid/src/server/	Server reactive runtime + createComponent / control flow / escape
packages/solid/web/src/	Browser DOM renderer entry; thin layer over dom-expressions core
packages/solid/web/server/	SSR renderer entry; uses seroval for streaming serialization
packages/solid/store/	createStore, createMutable, produce, reconcile
packages/solid/web/storage/	provideRequestEvent for SSR AsyncLocalStorage
packages/solid/h/ and packages/solid/html/	HyperScript and tagged-template factories
packages/solid/universal/	Custom-renderer entry
packages/babel-preset-solid/	The Babel preset that wires up babel-plugin-jsx-dom-expressions
packages/solid-element/	Web Components wrapper
packages/solid-ssr/	Static SSR helper plus four runnable example servers
packages/test-integration/	Smoke-tests CJS/ESM imports across the published surface
documentation/resources/examples.md	Curated index of example apps
.changeset/	Pending version bumps
turbo.json, pnpm-workspace.yaml	Build orchestration