CodeVetter · Repo Unpack evidence
solidjs/solid
github.com/solidjs/solid ↗ · 183 files · 861 KB
Website • API Docs • Features Tutorial • Playground • Discord Solid is a declarative JavaScript library for creating user interfaces.
Overview
Solid is a TypeScript and JavaScript UI library for application developers, combining reactive signals with compiled templates that update real DOM nodes. This repository contains the reactive runtime, browser and server component implementations, structured stores, a Babel preset, custom-element integration, and static-rendering utilities. Its distinctive architecture separates dependency tracking from rendering and selects browser, development, and server implementations through package export conditions.
System map
The repository distributes several packages around Solid's reactive runtime and rendering adapters. Browser, development, and server execution are separate build targets selected through conditional exports. pnpm and Turborepo coordinate compilation, declaration generation, testing, and publishing; the Express applications are examples of consuming the library.
- The root solid-js package is private and declares pnpm@9.15.0; the publishable packages/solid package declares solid-js version 1.9.15.
- The core entrypoint exports reactive primitives from reactive/signal.ts, observable and scheduler APIs, array helpers, and component/rendering APIs.
- Core conditional exports select dist/server for worker, deno, and node conditions, dist/solid for browser production, and dist/dev for development.
- Browser DOM operations and server HTML rendering cross an external implementation boundary: client.ts re-exports dom-expressions/src/client.js and server.ts re-exports dom-expressions/src/server.
- The server core has separate reactive and rendering modules; its createSignal stores a closure value, createMemo computes once, and createEffect is empty.
- Structured state is owned by store/src/store.ts and its mutable/modifier companions; web/storage instead provides Node AsyncLocalStorage request context.
- babel-preset-solid configures babel-plugin-jsx-dom-expressions; solid-element uses component-register to connect custom-element lifecycle callbacks to Solid roots.
- Rollup emits CommonJS and ES module targets for core, store, web, universal, html, and hyperscript; replaceDev substitutes the _SOLID_DEV_ and _DX_DEV_ build markers.
- Root build, types, test, and coverage scripts invoke Turbo; type tests depend on declaration generation, and integration import checks depend on the solid-js build and local link tasks.
- Distribution is organized around generated dist/types files and Changesets publishing; the SSR examples separately launch Express on port 3000, while SSG serves generated files on port 8080.
Feature catalog
Solid's public features center on reactive state, declarative control flow, asynchronous rendering, and lifecycle management. Consumers can use compiled JSX, hyperscript, tagged templates, custom elements, or custom host renderers. The repository also exposes server rendering and static generation, with a small routed example demonstrating Home, Profile, and Settings.
- createSignal returns an accessor and setter, accepts equality customization, and supports updater functions; createMemo exposes a derived accessor with its own comparator.
- createComputed, createRenderEffect, createEffect, and createReaction offer distinct execution and invalidation behavior; batch groups updates and untrack suppresses dependency collection.
- For maps by item identity with an index accessor, while Index maps by position with an item accessor; both accept fallbacks.
- Show supports keyed and accessor-based children; Switch selects the first matching Match and supports a fallback.
- createResource exposes state, error, loading, latest, mutate, and refetch, with initialValue, custom storage, SSR loading, and hydration callback options.
- lazy wraps asynchronous component imports and provides preload; Suspense renders fallbacks while resources are pending, and experimental SuspenseList coordinates reveal order and tail visibility.
- ErrorBoundary catches errors from its child scope, supports a fallback callback with reset, and participates in resetErrorBoundaries; createContext/useContext provide owner-scoped values.
- createRoot, onMount, onCleanup, getOwner, and runWithOwner expose lifecycle and scope control; mergeProps and splitProps preserve reactive property access, and createUniqueId uses hydration IDs or a client counter.
- createDeferred schedules deferred values, createSelector tracks subscribers by key, and useTransition returns pending state plus startTransition; observable/from bridge subscription-style producers.
- createStore offers path setters and partial merges; createMutable allows proxy writes, reconcile diffs incoming state with an optional key, and produce exposes mutation-style updates.
- Portal mounts content elsewhere in the DOM, optionally in a shadow root; Dynamic/createDynamic render either function components or named DOM elements.
- solid-js/h supplies a hyperscript factory and an optional jsx/jsxs/jsxDEV runtime; solid-js/html supplies tagged templates, with reactive expressions manually wrapped in functions.
Data flow
Reactive reads create dependency edges, and setters propagate invalidation through computation and effect queues. Stores translate property access and path updates into the same signal machinery, while resources translate asynchronous results into state and Suspense notifications. Server rendering uses hydration context to associate resources and fragments, and static generation adds a subprocess and filesystem output boundary.
- createSignal allocates SignalState with value, observers, observerSlots, and comparator; its getter binds readSignal and its setter delegates to writeSignal.
- readSignal records bidirectional dependency slots between the active Listener and the signal, resolves stale memos, and chooses tentative values during a running transition.
- writeSignal applies equality filtering, marks observers stale, queues pure computations separately from effects, and marks downstream memo consumers pending.
- runComputation installs a computation as Owner and Listener during its callback and restores both afterward; cleanNode removes dependency edges, child scopes, and cleanup callbacks.
- Store proxy reads lazily allocate per-property signal nodes only when tracking requires them; nested wrappable values receive proxies, while ownKeys subscribes to the self node.
- setStore batches updatePath/updateArray against the unwrapped object; setProperty mutates or deletes a property and notifies property, existence, array-length, and self observers.
- A resource source is memoized when callable; load obtains its current key, invokes the consumer fetcher untracked, records its promise, and sets pending or refreshing state.
- Resource loadEnd accepts a completion only when its promise matches pr, then completeLoad updates value/state/error and decrements subscribed Suspense contexts.
- Server resources are keyed by sharedConfig context IDs; asynchronous load stores resolved data in ctx.resources, calls notifySuspense, and passes values or promises to ctx.serialize.
- Hydration consumes deterministic context IDs: createComponent advances into a child context, client resources look up serialized values, and web hydrate first enables hydration behavior.
- provideRequestEvent stores an AsyncLocalStorage instance on globalThis under RequestContext and runs the supplied callback with its request event; it rejects non-server use.
- Static generation passes entry/output/url into a Node child process; writeToDisk dynamically imports the entry, calls its default export with the URL, creates the output directory, and writes returned HTML.
Behavior traces
Source inspection followed browser hydration and navigation, structured-state updates, asynchronous resource completion, and static HTML persistence. These traces name the local functions and identify external renderer boundaries explicitly. They describe implementation paths rather than runtime results observed during this investigation.
- Browser startup: the shared index calls hydrate(() => <App />, document); the web wrapper calls enableHydration before hydrateCore, whose implementation is imported through dom-expressions.
- Application initialization: App is wrapped by RouteHOC; the wrapper initializes a location signal from props.url or window.location.pathname, obtains useTransition, and provides location/pending/navigation helpers through RouterContext.
- Tab action: Link.navigate prevents default navigation, calls history.pushState, and invokes the context setLocation helper; that helper starts a transition, and App's matches predicates determine the Switch/Match branch.
- Profile loading: the wrapper creates a user resource with a 400 ms promise, creates an info resource sourced from user with initialValue [], and passes both accessors' values into a lazy Profile component containing a nested Suspense list.
- Signal update: createSignal's setter evaluates an updater and calls writeSignal; writeSignal queues invalidated computations within runUpdates, which calls completeUpdates and then runQueue/runTop/updateComputation.
- Structured-state update: createStore calls unwrap then wrap and returns setStore; setStore calls batch, selects updateArray or updatePath, and reaches setProperty, which emits signal-node notifications.
- Async completion: createResource.load calls fetcher and attaches promise handlers; loadEnd checks promise identity, completeLoad commits resource state, and Suspense.decrement clears its fallback when the pending counter reaches zero.
- SSR request: Express's catch-all handler passes req.url into App inside renderToStringAsync, awaits the result, and sends it; the rendering API crosses the web server re-export boundary into dom-expressions.
- HTML persistence: ssg/export.js maps index/profile/settings into entry/output/url records; renderStatic calls run for each, run spawns writeToDisk.js, and write calls the SSG entry before mkdir and writeFile.
- Custom-element lifecycle: customElement registers withSolid(ComponentType); withSolid creates a root and signal-backed props, inserts the component, updates props on property callbacks, and clears content/disposes on release.
- Server lazy rejection: load records a cast error and clears its cached rejected promise; the wrapper registers completion/error work with context.block, notifySuspense reaches completed, and Suspense routes errors toward an ErrorBoundary fallback.
Testing signals
Tests and CI were inspected, not executed; test existence supplies coverage intent rather than a passing result. Vitest separates jsdom client tests from Node server tests, with additional TypeScript checks and Node assertion/import checks. This inventory is bounded: inspected tests substantiate specific contracts, while coverage configuration and script selection identify limits without establishing exhaustive repository coverage.
- The client Vitest configuration uses jsdom, global test APIs, one fork worker, and isolate:false; it excludes test/server and resolves browser/development implementations.
- Server Vitest uses the Node environment, includes test/server/**/*.spec.ts, and aliases solid-js and solid-js/web to server source entrypoints.
- The solid-js test script runs both client and server Vitest configurations; its separate test-types script invokes tsc against tsconfig.test.json.
- Resource tests assert initial pending/loading state, out-of-order promise handling, and conversion of rejection values into Error objects.
- Store tests assert blocked direct mutation, reactive getters, key setters, and partial merges; prototype-guard tests cover __proto__, constructor.prototype traversal, unsafe merge keys, and permitted constructor/prototype leaf keys.
- Modifier tests check removal of omitted properties by reconcile and rejection of unsafe object keys while preserving safe data.
- External-source regressions cover normal tracking versus untrack, recreating transition-scoped sources after disposal, and retaining external updates after a memo is created during a transition.
- Server lazy tests assert stream termination and ErrorBoundary output on rejected imports, asynchronous string rendering, successful imports, and retry on a subsequent request.
- DOM Index tests inspect actual innerHTML after removals, swaps, rotations, reversal, replacement, and disposal; the transition regression checks committed memo values during pending resource work.
- Type tests use @ts-expect-error to specify invalid API combinations; the package type-check configuration includes core/web/store tests but excludes test/server.
- The Babel preset test is a Node assert comparison against one compiled JSX string; integration import checks intentionally suppress errors other than selected module-resolution/module-syntax failures.
- Downloaded integration tests pack packages, fetch aminya/solid-simple-table, install local tarballs, and run its test command; the package's default test selects test:imports rather than test:integrations.
Risk map
The strongest source-observed boundaries are configured code execution and output paths in static generation, external execution in optional integration tests, and shared runtime state. Package-condition mistakes and duplicated client/server behavior can affect broad portions of the public API. These are source observations or labeled hypotheses, not confirmed vulnerabilities or runtime failures.
- Static generation executes a caller-selected entry module and writes a caller-selected output path without repository-root confinement in the inspected runner; execFile uses a fixed Node executable and an argument array rather than shell interpolation.
- writeToDisk discards mkdir/writeFile callback errors and exits with status zero from the write callback; filesystem failures are not explicitly propagated by this source.
- The optional downloaded-test suite crosses network and shell boundaries, executes a downloaded project's tests, creates tarballs, and contains recursive cleanup operations; it is unsuitable for this read-only investigation.
- Conditional exports are behavior-sensitive: Node core signals do not build the client dependency graph, and browser renderToString/renderToStream mocks only log unsupported-use errors.
- Computations and cleanups created without an Owner receive development warnings that they will not be disposed/run; root ownership and disposal are explicit lifecycle responsibilities.
- Client tests share runtime state because isolate:false is enabled; the transition regression explicitly resets scheduling after another suite's enableScheduling call, documenting cross-test scheduler coupling.
- Unsafe-key handling must remain consistent across client store updates, server store updates, and reconcile: each has guards, and tests deliberately preserve constructor/prototype as final keys.
- Server rendering duplicates escape and resolveSSRNode logic, with an explicit source comment calling out duplication from solid-js/web; the external server implementation was not available as tracked source here.
- Server SuspenseList contains a TODO for revealOrder/tail and simply returns children after context handling, whereas the client implements reveal-order and tail policies.
- SSR example documentation has drift: it advertises localhost:8080 and Lerna commands, while inspected Express examples use port 3000 and manifests supply direct Rollup/Node scripts.
- Hypothesis: an application exposing store range setters to unchecked input could hang on a zero or backward by value, because the inspected client/server loops increment i by by without validating progress. (inferred)
- Hypothesis: renderer/compiler dependency changes can have a broad blast radius because DOM, SSR, tagged-template, hyperscript, and universal implementation adapters delegate to external expression packages; local adapters alone cannot establish their security properties. (inferred)
Extension points
Extension primarily happens through factory callbacks, renderer host operations, scoped providers, and compiler options. Development hooks expose graph and store updates, while external-source factories connect other reactive systems. Packaging and examples also contain explicit lists that must be extended when adding a new public entrypoint or sample route.
- createRenderer accepts RendererOptions<NodeType>, delegates to the expression renderer, and replaces its mergeProps with Solid's implementation; documented host operations include node creation, insertion, removal, traversal, and property assignment.
- The Babel preset merges caller options over default moduleName, builtIns, contextToCustomElements, wrapConditionals, and generate; custom-renderer documentation sets generate:universal and a host moduleName.
- enableExternalSource accepts a tracking/disposal factory and optional untrack function; repeated registrations compose factories and dispose both layers.
- enableScheduling accepts a custom scheduler, with requestCallback as the default; createDeferred routes delayed propagation through requestCallback.
- createResource accepts consumer fetchers and custom accessor/setter storage, plus SSR-load and onHydrated options, enabling data-source and state-storage adaptation without changing the resource runtime.
- createContext creates a unique provider key; useContext reads it from Owner.context with a default fallback, giving libraries a scoped service/state injection mechanism.
- DEV exposes reactive graph hooks and writeSignal/registerGraph; the store DEV export exposes onStoreNodeUpdate hooks and node inspection helpers.
- SolidStore.Unwrappable is an open interface whose property values become part of NotWrappable, allowing TypeScript declaration augmentation for excluded store value types.
- withSolid adapts component-register component types, and customElement supports either a component alone or a props-definition/component pair for new custom-element registrations.
- New published subpaths require coordinated package exports/files entries and Rollup build targets; declaration scripts also explicitly enumerate generated subpackages.
- The SSR example's route extension points are App's Link/Match entries and the SSG PAGES list; routing itself exposes RouteHOC, RouterContext, and Link.
- renderStatic accepts one configuration or an array, and each entry module supplies an async default function returning HTML; this makes the runner reusable with different rendering entrypoints.
Contributor handoff
Begin with package exports and build/test configuration before editing runtime behavior, because environment selection changes implementation semantics. Keep client/server parity, owner cleanup, hydration IDs, and store safety guards explicit in any proposed change. Tests and CI were inspected, not executed, and this brief is a bounded source inventory rather than exhaustive coverage or validation.
- Use the repository's pnpm/Turbo workflow: root scripts coordinate build, types, tests, and coverage, and CONTRIBUTING documents pnpm install/build/test for an executable development session.
- Before changing a public API, read its core export, conditional package map, and Rollup target; source tests alias implementations, while consumers load built artifacts selected by environment.
- Treat signal.ts as a shared runtime hotspot: Observer/Listener slots, Owner trees, tentative transition state, and cleanup are coupled across readSignal, writeSignal, completeUpdates, and cleanNode.
- For store changes, read store.ts, modifiers.ts, and server.ts together and preserve unsafe-key traversal/merge guards, deletion semantics, and permitted leaf keys.
- For asynchronous component changes, inspect both lazy implementations, resource/Suspense integration, and rejected-import regressions; the server test verifies a subsequent request retries the rejected module.
- In a separately authorized executable task, use the relevant Vitest file first, then the package test script for both environments and test-types for signature changes; these commands are recommendations, not results from this inspection. (inferred)
- Do not interpret inspected coverage as server validation: the client V8 report excludes server source, and the type-test configuration also excludes test/server.
- Respect test-global interactions: client isolate:false, the MessageChannel replacement, and explicit scheduler resetting in the transition regression can affect scheduling-focused tests.
- Avoid mistaking external adapters for local implementations: DOM, SSR, hyperscript, tagged-template, and universal expression engines are re-exported dependency code; fixes may require dependency-level investigation.
- Keep downloaded integration execution separate from routine import checking: the default integration test uses test:imports, whereas test:integrations invokes a suite with downloads, shell commands, packing, and deletion.
- Follow the established formatting and TypeScript configuration: two-space indentation, semicolons, double quotes, no trailing commas, strict NodeNext resolution, preserved JSX, and declaration generation.
- Release operations are explicit root scripts, and Changesets links solid-js with babel-preset-solid; publishing requires build/types and should not be conflated with local verification.
Languages
| Language | Files | Share of source |
|---|---|---|
| TypeScript | 70 | 62% |
| JavaScript | 43 | 38% |
| JSON | 33 | docs/config |
| Markdown | 22 | docs/config |
| YAML | 7 | docs/config |
| CSS | 1 | docs/config |
Start reading here
Probable source entrypoint: packages/ — inferred from the directory tree and manifest, not the upstream docs.
Source roots
packages/ (159 files)
Source layout — packages/
| Path | Files |
|---|---|
packages/babel-preset-solid/ | 5 |
packages/solid/ | 116 |
packages/solid-element/ | 6 |
packages/solid-ssr/ | 26 |
packages/test-integration/ | 6 |
Repository structure
| Top-level path | Files |
|---|---|
packages/ | 159 |
.github/ | 6 |
.changeset/ | 2 |
documentation/ | 1 |
Docs found: CONTRIBUTING.mdREADME.mddocumentation/resources/examples.md
Package
package.json — solid-js v1.0.0, 35 declared dependencies.
@babel/cli@babel/core@babel/preset-env@babel/preset-typescript@changesets/cli@rollup/plugin-babel@rollup/plugin-commonjs@rollup/plugin-json@rollup/plugin-node-resolve@rollup/plugin-replace@types/node@vitest/coverage-v8
CI & config entrypoints
README.md— Repository readme.github/workflows/cve-lite.yml— GitHub Actions workflow.github/workflows/main-ci.yml— GitHub Actions workflowpackage.json— npm scripts: build, bump, coverage, format, postinstall, preinstall, publish, release:onlypackages/babel-preset-solid/package.json— npm scripts: testpackages/solid-element/package.json— npm scripts: build, cleanpackages/solid-ssr/package.json— npm scripts: build:example:async, build:example:ssg, build:example:ssr, build:example:stream, clean, start:example:async, start:example:ssg, start:example:ssrpackages/solid/package.json— npm scripts: bench, build, build:clean, build:js, coverage, link, test, test-typespackages/test-integration/package.json— npm scripts: test, test:imports, test:integrations
Structural health signals
Average score 9.2/10 across 63 analyzed source files; 1 hotspot surfaced.
packages/solid/src/reactive/signal.ts— 1848 lines, score 5.7 (Large file, Deep nesting)packages/solid/src/server/rendering.ts— 736 lines, score 6.6 (Large file, Deep nesting)packages/solid/test/signals.type-tests.ts— 1129 lines, score 6.9 (Large file, High churn)
These are deterministic review leads — size, churn, and structural signals — not proof of a bug in this project.
Recent history
b25c557754f22026-09-04 — ci: bump cve-lite-cli action from v1.29.0 to v1.32.0 (#3273)f47845f9cc162026-08-17 — chore: refresh lockfile after 1.9.15 peer bumpa252c783b7092026-08-17 — chore: version packages for 1.9.15 release5aceb1c5e4c12026-08-17 — test: isolate transition #2046 from leaked enableScheduling954b968bfb052026-08-17 — Update DOM expression runtimes