Development workflow

Active contributors: Ryan Carniato, Damian Tarnawski

Branching

The default branch is main. The CI workflow .github/workflows/main-ci.yml runs on pull_request (any branch) and on push to main only. There is no protected dev or next branch — feature work happens in topic branches that target main directly.

Tags follow v<semver> and are pushed automatically by pnpm release:only (@changesets/cli).

Edit cycle

The most efficient inner loop is:

1. pnpm install once after pulling.
2. Edit source under packages/solid/src/, packages/solid/web/src/, packages/solid/store/src/, etc.
3. Run the tests for the package you touched:

   pnpm --filter solid-js test
   pnpm --filter solid-element test
   pnpm --filter babel-preset-solid test

4. If you touched anything that changes the published artifact (entry exports, types), run a full build before opening a PR:

   pnpm build
   pnpm --filter test-integration test

The Vitest config (packages/solid/vite.config.mjs) aliases solid-js, solid-js/web, solid-js/jsx-runtime, and rxcore directly to source files, so you do not need to rebuild between edits when you are running the test suite — only when you are exercising the integration harness or an external app.

Commit conventions

Browse git log --oneline and you'll see a mostly informal style:

• Bug fixes use fix: ... or Fix ... (e.g. fix: prevent createDeferred from keeping Node.js process alive (#2588)).
• Features use feat: ... (e.g. feat: add enableExternalSource for reactivity interoperability (#739)).
• Maintenance commits often have no prefix (Update dom-expressions/seroval to latest).

There is no enforced commitlint config; consistency is preferred but not required.

Pre-commit hook

package.json declares:

"simple-git-hooks": { "pre-commit": "pnpm run format" }

simple-git-hooks is installed by the root postinstall script, so once you have run pnpm install your commits will run Prettier across the entire repo before being recorded. To bypass for an in-progress commit, use git commit --no-verify, but expect CI / Prettier diffs if you do.

Pull request template

.github/PULL_REQUEST_TEMPLATE.md asks for:

• A description of the change.
• Linked issue numbers if applicable.
• A note on whether tests have been added or updated.
• Confirmation that documentation has been updated where necessary.

Releases

Releases are driven by changesets:

pnpm bump            # opens an interactive prompt; writes .changeset/<name>.md
git add .changeset/<name>.md && git commit -m "Add changeset for ..."

When a release is cut, a maintainer runs pnpm publish which chains pnpm run build && pnpm run types && pnpm run release:only (the last invokes changeset publish). The package versions are bumped, tags are pushed, and the relevant dist/ and types/ directories are uploaded to npm. CI does not auto-publish.

Beta and experimental builds use the same machinery — see the v2.0.0-experimental.* tag history.

CI

.github/workflows/main-ci.yml runs on every PR:

- run: pnpm install
- run: pnpm run build
- run: pnpm run test
- run: pnpm run coverage
- coverallsapp/github-action # uploads packages/solid/coverage/lcov.info
- actions/upload-artifact # uploads dist + types as build artifact

There is exactly one workflow file. There is no separate lint job — Prettier is the only "linter" and it runs in the pre-commit hook, not in CI.

The Coveralls badge in README.md reflects the lcov coverage report from packages/solid/coverage/lcov.info.

Tips for productive iteration

• Run a single test: cd packages/solid && pnpm vitest run signals.spec.ts -t "createSignal allows null".
• Filter specs by name: Vitest supports -t "<pattern>" to skip everything else.
• Watch mode: Vitest's watch mode is not the default in this repo (vitest run is configured), but you can run pnpm vitest (no run) inside packages/solid for a watcher.
• TypeScript-only work: For surface-area changes you can iterate against pnpm --filter solid-js test-types which only runs tsc --project tsconfig.test.json.

For deeper guidance on the kinds of changes that land smoothly, see Patterns and conventions.