@solidjs/vite-plugin weekly downloads statistics

⚡ @solidjs/vite-plugin

Renamed from vite-plugin-solid. This package was previously published as vite-plugin-solid. To migrate, swap the dependency and the import — npm install -D @solidjs/vite-plugin and import solid from '@solidjs/vite-plugin' — nothing else changes.

A simple integration to run solid-js with vite

Got a question? / Need help?

Join solid discord and check the troubleshooting section to see if your question hasn't been already answered.

Features

• HMR with no configuration needed • Drop-in installation as a vite plugin • Minimal bundle size • Support typescript (.tsx) out of the box • Experimental TypeScript TSRX (.tsrx) support out of the box • Support code splitting out of the box

Requirements

This module is 100% ESM compatible and requires Node.js >=22.12.0 (the same floor as the solid-js 2.0 runtime packages).

You can check your current Node.js version by running node -v. Use a version manager such as Volta or nvm to update it.

Supported Vite versions: Vite 8 and 9.

Quickstart

You can use the vite-template-solid starter templates similar to CRA:

Installation

Install vite, @solidjs/vite-plugin as dev dependencies.

Install solid-js as dependency.

You have to install those so that you are in control to which solid version is used to compile your code.

Add it as plugin to vite.config.js

Run

Just use regular vite or vite build commands

API

options

• Type: Object • Default: {}

options.include

• Type: (string | RegExp)[] | string | RegExp | null • Default: undefined

A picomatch pattern, or array of patterns, which specifies the files the plugin should operate on.

options.exclude

• Type: (string | RegExp)[] | string | RegExp | null • Default: undefined

A picomatch pattern, or array of patterns, which specifies the files to be ignored by the plugin.

options.dev

• Type: Boolean • Default: true

Resolve Solid's development builds under vite dev — the development export condition of solid-js and @solidjs/web, which carry the extra checks, warnings and diagnostics. Has no effect on vite build. Set to false to serve the production builds in dev instead.

options.observe

• Type: Boolean • Default: false

Resolve Solid's observe builds in production: the production-speed runtime that keeps the diagnostics and attribution channels (OBSERVE) alive for observability tooling (error monitoring, performance tracing). Adds the observe export condition to every environment and turns on the compiler's source names (see options.solid.sourceNames), so graph labels (, span.textContent, count) survive minification. Under vite dev the dev build still wins.

options.performanceTracks

• Type: boolean | PerformanceTracksOptions (from @solidjs/web/performance-tracks) • Default: true

Dev-serve only: paint Solid's records — effect and memo re-runs, interactions, holds, async flights, navigations, server-function calls — as custom tracks in the Chrome Performance panel, without the app calling enablePerformanceTracks() itself. Record a trace with the Performance panel while the dev server serves the page; the Solid group appears beside Chrome's main-thread and network tracks (Interactions, Propagation, Effects, Memos, Async, Holds, Navigations, Server), every span labelled by *why* it ran, findings as markers on the Timings track. See Chrome Performance panel in the Solid 2.0 diagnostics guide for how to read them.

The plugin injects a small client module that enables the tracks *ahead of the app's entry* — a tail.

middleware points at a server-only module default-exporting one middleware — (event, next) => Response | Promise, the request at event.request — or an array of them. The plugin composes the chain itself. next() takes no arguments: assign event.request = new Request(...) before calling it to hand a different request downstream (calling next(request), the previous shape, throws a migration error).

The page render runs inside next(), so per-request render inputs go on the event before that call. event.nonce is the CSP nonce (a string, or { script, style } with each a non-empty string or false). event.renderMode is 'stream' or 'async' for this request, overriding the static renderMode below. handleRequest(request, { nonce, renderMode }) is seeded onto the event before the chain and wins over a middleware write.

Generated entries pass event.nonce into renderToStream. An authored entry-server must forward the context.nonce the handler passes it (renderToStream(app, { manifest, nonce: context.nonce })).

The chain fronts every request the plugin dispatches — page SSR and the server-function endpoint, dev, production, and preview alike — and runs inside the request-event scope, so getRequestEvent() answers with the same event as the event argument (the endpoint shares it, so locals decoration is visible to server functions too). Nothing reaches the wire until the outermost middleware returns: headers stay mutable after next() even for streamed responses. In dev, writing event.nonce or event.renderMode after await next() warns: the render already read them.…

Description from the npm listing.