Skip to content

Commit cd955af

Browse files
Version Packages (next)
1 parent 3d2d4c4 commit cd955af

3 files changed

Lines changed: 21 additions & 1 deletion

File tree

‎.changeset/pre.json‎

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -79,6 +79,7 @@
7979
"reject-prefixed-server-env-keys",
8080
"remove-client-manifest-virtual",
8181
"response-head-middleware-preview",
82+
"ride-solid-rc-9",
8283
"root-relative-filter-globs",
8384
"sc-bootstrap-before-hydration-data",
8485
"scoped-server-function-dce",
@@ -98,7 +99,9 @@
9899
"ssr-inline-solid-consumers",
99100
"start-css-filter",
100101
"start-env-typed",
102+
"start-instrument-early-server-import",
101103
"start-mode-terminology",
104+
"start-node-entry",
102105
"start-render-mode",
103106
"start-setup-hook",
104107
"support-tsrx-vite",

‎CHANGELOG.md‎

Lines changed: 17 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,22 @@
11
# Changelog
22

3+
## 3.0.0-next.44
4+
5+
### Minor Changes
6+
7+
- 22858a3: `start.node`: the build emits a ready-to-run Node server. With `start: { node: true }` the ssr build writes `dist/server/node.js` beside `server.js` — `node dist/server/node.js` (env `PORT`, default 3000, and `HOST`) serves the client build statically (files under `build.assetsDir` as `Cache-Control: public, max-age=31536000, immutable`, everything else `public, max-age=0, must-revalidate` with `Last-Modified`; a reasonable MIME table, `HEAD`, dot-segment paths and `..` traversal refused) and hands every other request to `handleRequest` with the raw Node request as `nativeEvent`, so `getRequestEvent().nativeEvent` answers the same as under `vite dev` and `vite preview`. The node<->web bridge is the plugin's own `src/http.ts` — the code the dev and preview middlewares already run (HTTP/2 pseudo-headers, `https:` on TLS sockets, client disconnects as the request's `AbortSignal`, HEAD short-circuit, `set-cookie` split, backpressure that also settles on close) — shipped as a separate build artifact of the package (`dist/node-entry.mjs`) that the plugin reads at build time and emits under a small generated header carrying the emit-time constants (client dir relative to the server dir, `assetsDir`, `base`, the mode). The file is ESM with no dependency beyond `node:*` and `./server.js`, listens only when run directly, and exports `listener` (the `(req, res)` function, mountable into `http.createServer`, Express, Fastify), `createListener({ static?, event? })` — `static: false` leaves files and the client-mode `index.html` fallback to a framework such as `express.static` or a CDN and keeps only the bridge; `event: (req) => fields` merges extra request-event fields over `{ nativeEvent: req }` — and `serve({ port?, host?, static?, event? })`.
8+
9+
Why: the fullstack templates shipped a hand-written `server.js` whose bulk was this generic Node bridge, copied into every scaffold and baked into the CLI, so bridge fixes never reached users — and it looked custom-made. Node is the one mainstream runtime without a fetch-shaped server API (Workers, Deno, Bun, Netlify, Nitro consume the server bundle's `{ fetch }` directly), so the gap is Node-only and belongs in the build output. It is a `start.*` option, not `ssr.*` (`ssr` stays boolean-only), and applies to both start modes: SSR mode renders pages; client mode with `serverFunctions` (which keeps `dist/server`) serves the static client with an `index.html` history fallback for HTML navigations plus the endpoint. `node.js` is an emitted asset, never a second build input — `server.js` and its `handleRequest` / `{ fetch }` contracts are unchanged, and nothing changes without the option. Where no server bundle exists (client mode without `serverFunctions`, or `start.external`) the build warns and emits nothing. Compression/proxy stance unchanged: plain HTTP, put a reverse proxy or CDN in front. Follow-ups this unlocks: the templates drop `server.js` and point their `start` script at `node dist/server/node.js`; create-solid drops its baked `SERVER_JS` constant.
10+
11+
### Patch Changes
12+
13+
- 2e79544: Require solid-js / @solidjs/web 2.0.0-rc.9 (peer floor) and compile with @solidjs/compiler / @solidjs/babel-plugin rc.9 — runtime and compiler move in lockstep. The rc.9 compilers emit output only the rc.9 runtime understands, so this floor is a hard requirement, not policy: native elements with several spread sources compile to the runtimes' array form (`spread(el, [a, b], …)` on the client, `ssrElement(tag, [a, b], …)` on the server — no `mergeProps()` proxy, no memo, no hydration id; #3418/#3419/#3423) which only rc.9's `@solidjs/web` accepts; delegated event handlers move off Solid 1's `$$<type>` element key onto `_$$<type>` in both compiled output and the runtime's document delegate, so an rc.8 runtime would never fire an rc.9-compiled `onClick` (and vice versa); and under `componentNames` — which the plugin already turns on for its dev and observe postures — SSR output keeps `createComponent(Comp, props, "Comp")` so the server runtime's observe/dev tier labels the owner and a server finding's `ownerPath` reads `<App> › <Page>` like the client's. Nothing in the plugin itself had to change for rc.9: the new `observe` / `development` export conditions on `@solidjs/web`'s server-functions and frames client entries (and `observe` on every server entry) are picked up by the condition lists the plugin already installs, and the new `solid-js/internal` subpath is covered by the existing `solid-js` inlining.
14+
- 256c25d: `start.instrument`: a server-only module the plugin runs to completion before anything else in the server graph loads — the app, the middleware, `@solidjs/web`, every dependency. The seam for instrumentation that must patch the runtime before the modules it patches are loaded (an APM's OpenTelemetry setup, a profiler, a `module.register` hook), honored on every surface: `vite dev`, `vite build`, `vite preview`, and a host consuming the handler entry. Replaces the per-host `node --import instrument.mjs` dance.
15+
16+
Import order cannot do this in ESM — static imports are hoisted and evaluated in dependency order — so the generated handler entry becomes `await import(instrument); await import(handler)`, with the handler's surface (`handleRequest`, the `fetch` default) re-declared by name. The module may be async and needs no exports; the server build must keep code splitting on (the default).
17+
18+
Also: the `componentNames` note in the compiler options no longer calls the labels DOM-only — the SSR generate emits them too from the compilers that carry solidjs/solid#3441 (2.0.0-rc.9), and the start-ssr suite gains an `observe` mode that asserts an `observe: true` production build resolves the observe artifacts and carries component labels (the SSR half asserted once the workspace rides an rc that emits them).
19+
320
## 3.0.0-next.43
421

522
### Patch Changes

‎package.json‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
{
22
"name": "@solidjs/vite-plugin",
3-
"version": "3.0.0-next.43",
3+
"version": "3.0.0-next.44",
44
"description": "solid-js integration plugin for Vite",
55
"type": "module",
66
"engines": {

0 commit comments

Comments
 (0)