GO — Healthy across the board

• Last commit today
• 27+ active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 63% of recent commits
• ⚠ Scorecard: default branch unprotected (0/10)

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests, cross-checked against dependency CVEs from deps.dev and OpenSSF Scorecard}

SolidJS is a declarative JavaScript UI library that compiles templates directly to DOM nodes and uses fine-grained reactivity instead of a virtual DOM. When state changes via createSignal(), only the code that depends on that state re-runs, eliminating the overhead of diffing and reconciliation. It's written in TypeScript (~464KB) with Babel preset support for JSX transformation. Monorepo (pnpm workspaces) with packages/ subdirectories: packages/solid-element/ wraps Solid for Web Components, packages/solid-ssr/ provides server-side rendering with async examples, packages/babel-preset-solid/ handles JSX compilation. Core reactivity engine lives in the root (not shown in truncated file list but referenced in package.json as 'solid-js'). Uses dom-expressions, babel-plugin-jsx-dom-expressions, and seroval for compilation and serialization.

Frontend developers building interactive web applications who want the ergonomics of reactive frameworks (like React's hooks via createSignal, createEffect) without the performance penalty of virtual DOM diffing. Contributors are typically developers optimizing for bundle size, runtime performance, and fine-grained reactivity patterns.

Production-ready and actively maintained (v1.0.0+ with semantic versioning, comprehensive CI via GitHub Actions, extensive TypeScript support). The repo uses Turbo for monorepo builds, Vitest for testing with coverage, and Changeset for release management. Active Discord community (722K+ members) and regular npm releases indicate ongoing development and user adoption.

Moderate risk: smaller ecosystem compared to React/Vue means fewer third-party integrations and Stack Overflow answers. The monorepo structure (Turbo-managed) requires careful dependency management across packages like solid-element, solid-ssr, and babel-preset-solid. Breaking changes possible during v1.x minor bumps; check CHANGELOG.md before upgrading. Single core team (Ryan Carniato as lead) with distributed contributors.

Recent fix for element owner markers (visible in .changeset/fix-element-owner-markers.md) suggests active bug fixes. Monorepo is using Changeset-based releases (bumps via .changeset/ directory). TypeScript ~5.7.2 and Vitest ~2.1.2 suggest recent dependency updates. The repo is actively maintained with pre-commit Prettier formatting hooks.

git clone https://github.com/solidjs/solid.git
cd solid
pnpm install
pnpm run build
pnpm run test

(Node version specified in .nvmrc; uses pnpm enforced by preinstall script.)

Daily commands:

pnpm run build          # Build all packages via Turbo
pnpm run test           # Run Vitest across monorepo
pnpm run test test-types # Also run TypeScript type checks
pnpm run coverage       # Generate coverage reports

No dev server started directly; this is a library, not an app. See packages/solid-ssr/examples/ for runnable demo apps.

• packages/solid/h/src/index.ts — Main JSX hyperscript entry point defining how Solid renders components and elements.
• packages/solid/package.json — Core package definition for the solid-js runtime, entry point for all consumers.
• packages/babel-preset-solid/index.js — Babel configuration for transforming Solid JSX syntax into runtime calls.
• .github/workflows/main-ci.yml — CI/CD pipeline defining test, build, and release workflows for all packages.
• package.json — Monorepo root configuration using turbo and pnpm for workspace management.
• packages/solid-ssr/package.json — Server-side rendering package integrating Solid with Node.js execution.
• packages/solid-element/src/index.ts — Custom Elements bridge exposing Solid components as Web Components.

• Reactivity System (Core) (JavaScript, TypeScript) — Manages signals, effects, and subscriptions to track and propagate reactive state changes.
  • Failure mode: Infinite loops or missed updates if dependency tracking is incorrect
• JSX Compiler (Babel Preset) (Babel plugins) — Transforms JSX syntax into h() calls and component function invocations.
  • Failure mode: Syntax errors or incorrect h() argument order if transformation logic is buggy
• Hyperscript & DOM Layer (DOM API, event listeners) — Creates and mounts DOM elements, binds event listeners, and applies reactive updates.
  • Failure mode: Memory leaks if event listeners are not cleaned up on unmount
• Server-Side Rendering (Node.js, streaming APIs) — Renders Solid components to HTML strings or streams for Node.js environments.
  • Failure mode: Missing content or hydration mismatches if SSR output does not match client markup
• Web Components Bridge (Web Components API, Shadow DOM) — Wraps Solid components as Custom Elements compatible with Web Components standard.
  • Failure mode: Style encapsulation failures or prop/event bridging issues if wrapper is incomplete

• Developer JSX code → Babel preset — JSX syntax is transformed to h() function calls and component functions
• h() function calls → Core runtime — Component creation and element definitions are processed by the reactivity engine
• Reactivity engine → DOM layer (hyperscript) — Signal updates trigger effect callbacks that invoke DOM mutation functions
• Browser events → Signal updates — User interactions trigger signal setters which propagate changes through effects
• SSR renderer → HTML string/stream — Server-side component execution produces serialized markup for initial page load

Add a new Solid core feature or API

1. Implement feature in packages/solid/h/src/index.ts or create new module in packages/solid (packages/solid/h/src/index.ts)
2. Export from packages/solid/package.json main entry point (packages/solid/package.json)
3. If JSX transform is needed, update babel preset in packages/babel-preset-solid/index.js (packages/babel-preset-solid/index.js)
4. Add test in packages/solid or relevant package with .test.ts suffix (packages/solid/package.json)

Add server-side rendering capability

1. Create new example in packages/solid-ssr/examples/ with index.js and rollup.config.js (packages/solid-ssr/examples/ssr/index.js)
2. Implement rendering logic using packages/solid-ssr/static/index.js utilities (packages/solid-ssr/static/index.js)
3. Reuse shared components from packages/solid-ssr/examples/shared/src (packages/solid-ssr/examples/shared/src/components/App.js)

Create a Web Component from a Solid component

1. Wrap Solid component using packages/solid-element/src/index.ts defineCustomElement export (packages/solid-element/src/index.ts)
2. Reference example pattern from packages/solid-element/sample.jsx (packages/solid-element/sample.jsx)
3. Export and register custom element following Web Components API conventions (packages/solid-element/package.json)

Release a new version

1. Run 'pnpm run bump' to create changesets in .changeset/ directory (.changeset/config.json)
2. Commit changeset files; CI will auto-publish via 'pnpm run publish' in main-ci.yml (.github/workflows/main-ci.yml)
3. Verify package.json versions and CHANGELOG.md updates post-release (package.json)

• Babel JSX transform — Converts JSX syntax to efficient runtime function calls without requiring React semantics
• Fine-grained reactivity (signals/effects) — Enables granular DOM updates without virtual diffing, reducing overhead compared to vDOM libraries
• Web Components (solid-element) — Provides standards-based encapsulation and interoperability with other frameworks
• Turbo monorepo — Orchestrates builds across core, SSR, babel-preset, and Web Components packages efficiently
• Changesets for versioning — Automates semantic versioning and changelog generation across monorepo packages

• Fine-grained reactivity instead of virtual DOM

  • Why: Reduces diffing overhead and enables smaller bundle sizes
  • Consequence: Developers must understand reactive dependencies; less familiar paradigm than React

• Monorepo structure with separate SSR, elements, babel packages

  • Why: Allows independent opt-in of features (SSR, Web Components, JSX compilation)
  • Consequence: Added complexity in dependency management and release coordination across packages

• Compile-time JSX transformation over runtime

  • Why: Enables optimizations and smaller runtime payload
  • Consequence: Requires build step; not suitable for REPL or eval-based environments without babel

• Not a state management library; does not provide Redux-like patterns or centralized store
• Not a router; routing is delegated to separate packages (e.g., solid-router)
• Not a server framework; SSR only handles rendering, not routing or middleware
• Not backwards-compatible with React; incompatible JSX semantics and API surface

• Avg cyclomatic complexity: ~6 — Reactivity system requires careful dependency tracking and effect scheduling; SSR adds serialization complexity; JSX compilation involves syntax transformation rules
• Largest file: packages/solid/h/src/index.ts (800 lines)
• Estimated quality issues: ~3 — Potential hydration mismatches in SSR, manual dependency management risks in reactivity, and performance pitfalls from over-subscription of signals

• Manual dependency tracking (Medium) — packages/solid/h/src/index.ts: Developers may manually manage effect dependencies instead of relying on automatic tracking, leading to stale closures.
• Missing SSR hydration markers (High) — packages/solid-ssr/examples/ssr/index.js: If SSR output markup does not match client-side rendering, hydration can fail silently or cause element mismatches.
• Excessive signal subscriptions (Medium) — packages/solid/h/src/index.ts: Creating too many fine-grained signals without batching can lead to excessive re-renders and performance degradation.

• packages/solid/h/src/index.ts (component execution) (CPU-bound reactivity tracking) — Each component function invocation traverses the full reactive dependency graph; no built-in memoization for expensive computations.
• packages/solid-ssr/static/index.js (string rendering) (I/O-bound serialization) — Server-side rendering to string requires full component tree traversal; streaming mitigates latency but adds complexity.
• .github/workflows/main-ci.yml (turbo build orchestration) (Build-time graph traversal) — Monorepo build times scale with number of packages; interdependencies may cause sequential bottlenecks.

pnpm required: preinstall script enforces pnpm; npm/yarn will fail. Turbo caching: clean build may be needed if cache is stale (use 'turbo run build --no-cache'). Node version: check .nvmrc (not shown in snippet but present in file list) before installing. Babel preset interdependency: babel-plugin-jsx-dom-expressions must be compatible with dom-expressions version (both vendored in node_modules). TypeScript paths: tsconfig-replace-paths used for monorepo path resolution; check tsconfig.json in each package if imports fail. Seroval version: pinned to ~1.5.0 for SSR serialization; upgrading may break hydration compatibility.

• Fine-grained reactivity — Core differentiator of Solid vs React; understanding that only dependent code re-runs (not component tree) is essential to writing performant Solid apps and debugging unexpected behavior
• Signals (createSignal, createEffect, createMemo) — Solid's primitive for state and side effects; hooks-like but with automatic dependency tracking and no dependency array; critical to learn before writing any Solid component
• JSX compilation to DOM (not Virtual DOM) — Solid templates compile to native DOM creation functions, not a Virtual DOM representation; understanding this explains why Solid is smaller and faster than React, and why babel-plugin-jsx-dom-expressions is required
• Hydration and SSR serialization (seroval) — Solid-ssr uses seroval to serialize server-rendered state; critical for isomorphic apps. Understanding how signals hydrate on the client prevents bugs like lost interactivity or double-rendering
• Web Components integration (solid-element) — Solid can wrap components as native CustomElements; essential for using Solid components in non-Solid contexts (other frameworks, vanilla JS) or distributing component libraries
• Monorepo with Turbo — Contributors must understand that solid-js, solid-element, solid-ssr, and babel-preset-solid are interdependent packages; changes in one may affect builds in others; Turbo parallelization is key to fast CI
• Changeset-based versioning — Solid uses Changesets (.changeset/) for semantic versioning and automated releases; contributors must document changes before merge; understanding this workflow is required for publishing updates

• facebook/react — Direct competitor using Virtual DOM + hooks API; Solid offers same mental model (signals as hooks) but with fine-grained reactivity instead of reconciliation
• vuejs/core — Alternative reactive framework with similar reactivity API (ref/computed); Solid's compilation-to-DOM approach differs from Vue's runtime reactivity system
• withastro/astro — Meta-framework that uses Solid as one of its supported UI library options (alongside React, Vue); common integration point for Solid users
• solidjs/solid-start — Official meta-framework built on Solid for full-stack apps (server + client routing); companion repo for Solid users building complete applications
• solidjs/solid-docs — Official documentation repo; source of truth for API docs and tutorial content referenced in README

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive E2E tests for solid-ssr package examples

The solid-ssr package has multiple examples (async, ssg, ssr, stream) in packages/solid-ssr/examples/ but no apparent E2E test coverage. These examples demonstrate critical server-side rendering patterns that should be tested to prevent regressions. A new contributor could create a Vitest-based E2E test suite that validates each example builds and renders correctly.

• [ ] Create packages/solid-ssr/examples/tests/e2e.test.ts
• [ ] Add tests for each example (async, ssg, ssr, stream) that verify: build succeeds, output matches expected HTML structure, and data hydration works
• [ ] Integrate tests into the main CI workflow in .github/workflows/main-ci.yml to run during PR validation
• [ ] Add coverage reporting for solid-ssr to existing coverage pipeline

Expand TypeScript definitions and add type tests for solid-element Web Component integration

The packages/solid-element/src/index.ts module lacks comprehensive type definitions for the Web Component integration API. There's a sample.jsx but no type test file. A new contributor could add proper .d.ts definitions and create packages/solid-element/tests/types.test.ts using vitest's type assertion utilities to validate the TypeScript API surface.

• [ ] Review packages/solid-element/src/index.ts and create detailed type definitions for all exported functions and interfaces
• [ ] Create packages/solid-element/tests/types.test.ts to test prop typing, event typing, and slot typing for Web Components
• [ ] Add JSDoc comments to packages/solid-element/src/index.ts documenting API usage with TypeScript examples
• [ ] Update packages/solid-element/tsconfig.json to ensure strict type checking

Add missing unit tests for babel-preset-solid plugin edge cases

The packages/babel-preset-solid/test.js file exists but appears minimal. This Babel preset is critical infrastructure used across the entire ecosystem. A new contributor could expand test coverage for JSX transformation edge cases, nested reactive scopes, and error handling by creating a comprehensive test suite that covers the babel-plugin-jsx-dom-expressions integration.

• [ ] Audit packages/babel-preset-solid/test.js and packages/babel-preset-solid/index.js to identify untested transformation scenarios
• [ ] Add tests for: nested components, conditional JSX, dynamic props, event handlers, refs, and reactive expressions
• [ ] Add tests for error cases: invalid JSX syntax, missing context, circular dependencies
• [ ] Integrate tests into CI/CD to run on every commit using the existing vitest setup

• Add Vitest unit tests for solid-element Web Components wrapper (packages/solid-element/src/) to increase coverage beyond existing sample.jsx; currently no test/ directory visible
• Document the JSX→DOM compilation pipeline by adding inline comments to packages/babel-preset-solid/index.js explaining plugin order and babel-plugin-jsx-dom-expressions configuration for new contributors
• Expand packages/solid-ssr/examples/shared/src/components/ with a new Profile detail component that fetches async data via createResource and test hydration with solid-ssr to validate SSR patterns

The SolidJS codebase demonstrates reasonable security posture with standard build tools and a monorepo structure. Primary concerns include: (1) potential XSS vectors through JSX-to-DOM transformation libraries that require regular auditing, (2) incomplete dependency override configuration that could affect version consistency, (3) minimal pre-commit security checks beyond formatting, and (4) absence of security policy documentation. The codebase uses reputable dependencies with active maintenance (TypeScript, Vitest, Rollup), but would benefit from enhanced security tooling in the CI/CD pipeline and clearer vulnerability disclosure processes.

• Medium · Babel Plugin for JSX DOM Expressions — packages/solid/package.json, devDependencies: babel-plugin-jsx-dom-expressions, dom-expressions. The babel-plugin-jsx-dom-expressions (v0.40.7) and dom-expressions (0.40.8) packages are used for JSX compilation and DOM manipulation. While these are reputable packages, JSX-to-DOM transformers have historically been vectors for XSS vulnerabilities if they don't properly sanitize output. The library should ensure all user-provided content is properly escaped. Fix: Regularly audit and update these dependencies. Implement Content Security Policy (CSP) headers to mitigate XSS risks. Review dom-expressions library code for proper escaping/sanitization of user inputs.
• Medium · Incomplete pnpm Overrides Configuration — package.json, pnpm.overrides section. The pnpm overrides section in package.json appears truncated/incomplete ('babel-preset-solid' has no value specified). This could lead to inconsistent dependency resolution and potential security issues if critical packages are not properly pinned. Fix: Complete the pnpm overrides configuration with proper version specifications. Ensure all critical dependencies like babel-preset-solid are explicitly versioned to prevent unexpected updates that could introduce vulnerabilities.
• Low · Missing Git Hooks Security Configuration — .github/workflows/main-ci.yml, simple-git-hooks configuration in package.json. The pre-commit hook only runs prettier formatting. While this maintains code style, it doesn't include security checks such as secret scanning, dependency audits, or ESLint security rules. Fix: Expand pre-commit hooks to include: secret scanning (husky + secretlint), dependency auditing (npm audit), and security-focused linting (ESLint with security plugins).
• Low · No SECURITY.md File — Repository root. The repository lacks a SECURITY.md file to provide security policy and vulnerability disclosure guidelines, making it harder for security researchers to responsibly report issues. Fix: Create a SECURITY.md file with: vulnerability disclosure policy, supported versions for security updates, contact information for security issues, and responsible disclosure guidelines.
• Low · Broad Prettier File Pattern — package.json, format script. The format script uses a wide glob pattern '**/*.[tj]s?(x)' which could potentially format configuration files or scripts that shouldn't be modified automatically. Fix: Refine the glob pattern to exclude configuration files, build artifacts, and node_modules: '--ignore "node_modules" --ignore "dist" --ignore "build"'
• Low · Transitive Dependency Risk - jsdom — packages/solid/devDependencies: jsdom. jsdom (v25.0.1) is a heavy dependency that simulates a DOM environment. While necessary for testing, it has had security issues in the past due to its complexity. The version constraint allows patch updates automatically. Fix: Consider pinning jsdom to a specific minor version and regularly audit for CVEs. Review test setup to minimize jsdom surface area exposure.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/solidjs/solid shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live solidjs/solid repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/solidjs/solid.

What it runs against: a local clone of solidjs/solid — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in solidjs/solid | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of solidjs/solid. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/solidjs/solid.git
#   cd solid
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of solidjs/solid and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "solidjs/solid(\\.git)?\\b" \\
  && ok "origin remote is solidjs/solid" \\
  || miss "origin remote is not solidjs/solid (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "packages/solid/h/src/index.ts" \\
  && ok "packages/solid/h/src/index.ts" \\
  || miss "missing critical file: packages/solid/h/src/index.ts"
test -f "packages/solid/package.json" \\
  && ok "packages/solid/package.json" \\
  || miss "missing critical file: packages/solid/package.json"
test -f "packages/babel-preset-solid/index.js" \\
  && ok "packages/babel-preset-solid/index.js" \\
  || miss "missing critical file: packages/babel-preset-solid/index.js"
test -f ".github/workflows/main-ci.yml" \\
  && ok ".github/workflows/main-ci.yml" \\
  || miss "missing critical file: .github/workflows/main-ci.yml"
test -f "package.json" \\
  && ok "package.json" \\
  || miss "missing critical file: package.json"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/solidjs/solid"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.