fix: preload modules for data-addressed server function calls by ryansolid · Pull Request #335 · solidjs/solid-vite-plugin

ryansolid · 2026-08-29T21:18:50Z

Summary

Scripted server-function calls are moving to their own data address, <endpoint>/data/<id>, leaving the bare <endpoint>/<id> to plain HTTP (form actions, direct callers) — A cacheable raw Response is shaped by a request header nothing keys on solid#3094 (landed on next as solidjs/solid@95229453). The two caller kinds get differently shaped answers, and shared caches key on the URL, so the split keeps one caller kind's cached answer from ever being replayed to the other.
The dev middleware's module-preload step assumed exactly one path segment after the mount, so a cold function only client code references would never be evaluated in the SSR environment for a data-addressed call — a 404 under vite dev. The id now parses from behind the literal data segment too. A function id spelled data still parses at the bare address, since an id occupies exactly one segment.
Dispatch itself was already fine: mount matching is prefix-based, and the runtime handler accepts both address shapes. Comments on the mount gate updated to describe the two-address scheme.

Draft until a @solidjs/web carrying the data address ships (next release after 2.0.0-rc.4); safe to land early — the parsing change is additive.

Test plan

pnpm build (clean)
Example e2e suites pass against current @solidjs/web (old client, bare addresses — unaffected path)
After the next @solidjs/web release: vite dev against a client-only-referenced server function (cold SSR module) resolves at /_server/data/<id>

Made with Cursor

Scripted calls now go to <endpoint>/data/<id> (solidjs/solid#3094). The dev middleware's module-preload step assumed exactly one path segment after the mount, so a cold function only client code references would never be evaluated in the SSR environment for a data-addressed call — a 404 under vite dev. Dispatch was unaffected (mount matching is prefix-based); the id now parses from behind the literal data segment too. Co-authored-by: Cursor <cursoragent@cursor.com>

changeset-bot · 2026-08-29T21:18:54Z

🦋 Changeset detected

Latest commit: 1e0c5ef

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@solidjs/vite-plugin	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

pkg-pr-new · 2026-08-29T21:19:23Z

Open in StackBlitz

npm i https://pkg.pr.new/@solidjs/vite-plugin@335

commit: 1e0c5ef

solidjs/solid#3109) Co-authored-by: Cursor <cursoragent@cursor.com>

The RC is already breaking addresses (the data-address split), so the transitional X-Server-Function-Id header and ?id= addressing leave with the runtime's own shims — path-only addressing is the protocol (solidjs/solid#3094). Co-authored-by: Cursor <cursoragent@cursor.com>

ryansolid · 2026-08-31T21:45:09Z

Root-caused the middleware-mode failure ("Unknown server function: 9832c6f0-4-whoAmI") — it is not a regression in this PR, it's version skew:

e9b2a39 correctly reads the file hash from the second id segment, matching the identity-keyed <name>-<hash>[-<ordinal>] ids from A server function's id encodes its position in the file, so appending one re-points existing addresses solid#3109.
But #3109 hasn't shipped — the repo rides @solidjs/compiler 2.0.0-rc.4, which still mints positional <hash>-<ordinal>-<name> ids. Against those, split('-')[1] yields the ordinal, the id-to-module lookup misses, the module is never imported server-side, and dispatch refuses the call.
Plain dev mode passes only because the page graph loads the module anyway; middleware mode's direct endpoint is the one path that depends on the hash lookup.

This goes green once the repo bumps to the rc.5 compiler (which carries #3109). Blocked on the solid rc.5 release, nothing to fix here.

rc.5's argument parser treats a present body that decodes to nothing as malformed (400) where rc.4 ignored it, and the dev middlewares' node bridge attached `Readable.toWeb(req)` to every non-GET/HEAD request — so bodyless POSTs (zero-argument scripted calls, synthetic dispatches) started failing across dev and any prod host with the same conversion. Presence now follows the protocol signals: Content-Length or Transfer-Encoding on HTTP/1 (RFC 9112 §6), `stream.endAfterHeaders` on the h2 compat API. The start-ssr example's production server.js mirrors the same fix. Co-authored-by: Cursor <cursoragent@cursor.com>

rc.5 publishes the data-address split this branch routes (solidjs/solid#3094): the client transport computes `<endpoint>/data/<id>` for scripted calls while form actions and plain HTTP keep the bare `<endpoint>/<id>`, and ids are identity-keyed `<name>-<hash>[-<ordinal>]` (solidjs/solid#3109) — identical across dev and prod, so the suites' prod-id derivations collapse to the dev id. The workspace catalog moves to ^2.0.0-rc.5 (minimumReleaseAgeExclude extended per the existing pattern), the harness id extraction matches the name-first shape, and the CSRF rejection probes a registered id: rc.5 answers unknown ids 404 before the same-origin check runs. Full gate green against published rc.5 (no linking): ssr 12/12 + boundary 8/8, css-matrix 82/82 + bridge 19/19, start-ssr 366/366 + http-bridge 10/10, start-client 45/45, start-env 47/47, vite-8 vitest 1/1, cypress e2e 1/1. Co-authored-by: Cursor <cursoragent@cursor.com>

socket-security · 2026-09-01T18:29:34Z

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Package	Supply Chain Security	Quality	Maintenance
@solidjs/babel-plugin@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺⁴	⁺¹	⁺³
@solidjs/compiler@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺⁴		⁺²
@solidjs/diagnostics@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺¹		⁺¹
@solidjs/web@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺¹	⁺¹	⁺¹
solid-js@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺¹	⁺¹	⁺¹

View full report

socket-security · 2026-09-01T18:29:36Z

Warning

Review the following alerts detected in dependencies.

According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.

Action	Severity	Alert (click "▶" to expand/collapse)
Warn		Low adoption: npm `@solidjs/compiler-darwin-x64` Location:Package overview From:pnpm-lock.yaml → `npm/@solidjs/compiler@2.0.0-rc.5` → `npm/@solidjs/compiler-darwin-x64@2.0.0-rc.5` ℹ Read more on: This package \| This alert \| What are unpopular packages? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at `support@socket.dev`. Suggestion: Unpopular packages may have less maintenance and contain other problems. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/@solidjs/compiler-darwin-x64@2.0.0-rc.5`. You can also ignore all packages with `@SocketSecurity ignore-all`. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Low adoption: npm `@solidjs/compiler-linux-arm64-gnu` Location:Package overview From:pnpm-lock.yaml → `npm/@solidjs/compiler@2.0.0-rc.5` → `npm/@solidjs/compiler-linux-arm64-gnu@2.0.0-rc.5` ℹ Read more on: This package \| This alert \| What are unpopular packages? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at `support@socket.dev`. Suggestion: Unpopular packages may have less maintenance and contain other problems. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/@solidjs/compiler-linux-arm64-gnu@2.0.0-rc.5`. You can also ignore all packages with `@SocketSecurity ignore-all`. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.

View full report

ryansolid · 2026-08-29T21:18:50Z

Summary

Scripted server-function calls are moving to their own data address, <endpoint>/data/<id>, leaving the bare <endpoint>/<id> to plain HTTP (form actions, direct callers) — A cacheable raw Response is shaped by a request header nothing keys on solid#3094 (landed on next as solidjs/solid@95229453). The two caller kinds get differently shaped answers, and shared caches key on the URL, so the split keeps one caller kind's cached answer from ever being replayed to the other.
The dev middleware's module-preload step assumed exactly one path segment after the mount, so a cold function only client code references would never be evaluated in the SSR environment for a data-addressed call — a 404 under vite dev. The id now parses from behind the literal data segment too. A function id spelled data still parses at the bare address, since an id occupies exactly one segment.
Dispatch itself was already fine: mount matching is prefix-based, and the runtime handler accepts both address shapes. Comments on the mount gate updated to describe the two-address scheme.

Draft until a @solidjs/web carrying the data address ships (next release after 2.0.0-rc.4); safe to land early — the parsing change is additive.

Test plan

pnpm build (clean)
Example e2e suites pass against current @solidjs/web (old client, bare addresses — unaffected path)
After the next @solidjs/web release: vite dev against a client-only-referenced server function (cold SSR module) resolves at /_server/data/<id>

Made with Cursor

Scripted calls now go to <endpoint>/data/<id> (solidjs/solid#3094). The dev middleware's module-preload step assumed exactly one path segment after the mount, so a cold function only client code references would never be evaluated in the SSR environment for a data-addressed call — a 404 under vite dev. Dispatch was unaffected (mount matching is prefix-based); the id now parses from behind the literal data segment too. Co-authored-by: Cursor <cursoragent@cursor.com>

changeset-bot · 2026-08-29T21:18:54Z

🦋 Changeset detected

Latest commit: 1e0c5ef

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@solidjs/vite-plugin	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

pkg-pr-new · 2026-08-29T21:19:23Z

Open in StackBlitz

npm i https://pkg.pr.new/@solidjs/vite-plugin@335

commit: 1e0c5ef

solidjs/solid#3109) Co-authored-by: Cursor <cursoragent@cursor.com>

The RC is already breaking addresses (the data-address split), so the transitional X-Server-Function-Id header and ?id= addressing leave with the runtime's own shims — path-only addressing is the protocol (solidjs/solid#3094). Co-authored-by: Cursor <cursoragent@cursor.com>

ryansolid · 2026-08-31T21:45:09Z

Root-caused the middleware-mode failure ("Unknown server function: 9832c6f0-4-whoAmI") — it is not a regression in this PR, it's version skew:

e9b2a39 correctly reads the file hash from the second id segment, matching the identity-keyed <name>-<hash>[-<ordinal>] ids from A server function's id encodes its position in the file, so appending one re-points existing addresses solid#3109.
But #3109 hasn't shipped — the repo rides @solidjs/compiler 2.0.0-rc.4, which still mints positional <hash>-<ordinal>-<name> ids. Against those, split('-')[1] yields the ordinal, the id-to-module lookup misses, the module is never imported server-side, and dispatch refuses the call.
Plain dev mode passes only because the page graph loads the module anyway; middleware mode's direct endpoint is the one path that depends on the hash lookup.

This goes green once the repo bumps to the rc.5 compiler (which carries #3109). Blocked on the solid rc.5 release, nothing to fix here.

rc.5's argument parser treats a present body that decodes to nothing as malformed (400) where rc.4 ignored it, and the dev middlewares' node bridge attached `Readable.toWeb(req)` to every non-GET/HEAD request — so bodyless POSTs (zero-argument scripted calls, synthetic dispatches) started failing across dev and any prod host with the same conversion. Presence now follows the protocol signals: Content-Length or Transfer-Encoding on HTTP/1 (RFC 9112 §6), `stream.endAfterHeaders` on the h2 compat API. The start-ssr example's production server.js mirrors the same fix. Co-authored-by: Cursor <cursoragent@cursor.com>

rc.5 publishes the data-address split this branch routes (solidjs/solid#3094): the client transport computes `<endpoint>/data/<id>` for scripted calls while form actions and plain HTTP keep the bare `<endpoint>/<id>`, and ids are identity-keyed `<name>-<hash>[-<ordinal>]` (solidjs/solid#3109) — identical across dev and prod, so the suites' prod-id derivations collapse to the dev id. The workspace catalog moves to ^2.0.0-rc.5 (minimumReleaseAgeExclude extended per the existing pattern), the harness id extraction matches the name-first shape, and the CSRF rejection probes a registered id: rc.5 answers unknown ids 404 before the same-origin check runs. Full gate green against published rc.5 (no linking): ssr 12/12 + boundary 8/8, css-matrix 82/82 + bridge 19/19, start-ssr 366/366 + http-bridge 10/10, start-client 45/45, start-env 47/47, vite-8 vitest 1/1, cypress e2e 1/1. Co-authored-by: Cursor <cursoragent@cursor.com>

socket-security · 2026-09-01T18:29:34Z

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Package	Supply Chain Security	Quality	Maintenance
@solidjs/babel-plugin@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺⁴	⁺¹	⁺³
@solidjs/compiler@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺⁴		⁺²
@solidjs/diagnostics@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺¹		⁺¹
@solidjs/web@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺¹	⁺¹	⁺¹
solid-js@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺¹	⁺¹	⁺¹

View full report

socket-security · 2026-09-01T18:29:36Z

Warning

Review the following alerts detected in dependencies.

According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.

Action	Severity	Alert (click "▶" to expand/collapse)
Warn		Low adoption: npm `@solidjs/compiler-darwin-x64` Location:Package overview From:pnpm-lock.yaml → `npm/@solidjs/compiler@2.0.0-rc.5` → `npm/@solidjs/compiler-darwin-x64@2.0.0-rc.5` ℹ Read more on: This package \| This alert \| What are unpopular packages? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at `support@socket.dev`. Suggestion: Unpopular packages may have less maintenance and contain other problems. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/@solidjs/compiler-darwin-x64@2.0.0-rc.5`. You can also ignore all packages with `@SocketSecurity ignore-all`. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Low adoption: npm `@solidjs/compiler-linux-arm64-gnu` Location:Package overview From:pnpm-lock.yaml → `npm/@solidjs/compiler@2.0.0-rc.5` → `npm/@solidjs/compiler-linux-arm64-gnu@2.0.0-rc.5` ℹ Read more on: This package \| This alert \| What are unpopular packages? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at `support@socket.dev`. Suggestion: Unpopular packages may have less maintenance and contain other problems. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/@solidjs/compiler-linux-arm64-gnu@2.0.0-rc.5`. You can also ignore all packages with `@SocketSecurity ignore-all`. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.

View full report

ryansolid · 2026-08-29T21:18:50Z

Summary

Scripted server-function calls are moving to their own data address, <endpoint>/data/<id>, leaving the bare <endpoint>/<id> to plain HTTP (form actions, direct callers) — A cacheable raw Response is shaped by a request header nothing keys on solid#3094 (landed on next as solidjs/solid@95229453). The two caller kinds get differently shaped answers, and shared caches key on the URL, so the split keeps one caller kind's cached answer from ever being replayed to the other.
The dev middleware's module-preload step assumed exactly one path segment after the mount, so a cold function only client code references would never be evaluated in the SSR environment for a data-addressed call — a 404 under vite dev. The id now parses from behind the literal data segment too. A function id spelled data still parses at the bare address, since an id occupies exactly one segment.
Dispatch itself was already fine: mount matching is prefix-based, and the runtime handler accepts both address shapes. Comments on the mount gate updated to describe the two-address scheme.

Draft until a @solidjs/web carrying the data address ships (next release after 2.0.0-rc.4); safe to land early — the parsing change is additive.

Test plan

pnpm build (clean)
Example e2e suites pass against current @solidjs/web (old client, bare addresses — unaffected path)
After the next @solidjs/web release: vite dev against a client-only-referenced server function (cold SSR module) resolves at /_server/data/<id>

Made with Cursor

Scripted calls now go to <endpoint>/data/<id> (solidjs/solid#3094). The dev middleware's module-preload step assumed exactly one path segment after the mount, so a cold function only client code references would never be evaluated in the SSR environment for a data-addressed call — a 404 under vite dev. Dispatch was unaffected (mount matching is prefix-based); the id now parses from behind the literal data segment too. Co-authored-by: Cursor <cursoragent@cursor.com>

changeset-bot · 2026-08-29T21:18:54Z

🦋 Changeset detected

Latest commit: 1e0c5ef

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@solidjs/vite-plugin	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

pkg-pr-new · 2026-08-29T21:19:23Z

Open in StackBlitz

npm i https://pkg.pr.new/@solidjs/vite-plugin@335

commit: 1e0c5ef

solidjs/solid#3109) Co-authored-by: Cursor <cursoragent@cursor.com>

The RC is already breaking addresses (the data-address split), so the transitional X-Server-Function-Id header and ?id= addressing leave with the runtime's own shims — path-only addressing is the protocol (solidjs/solid#3094). Co-authored-by: Cursor <cursoragent@cursor.com>

ryansolid · 2026-08-31T21:45:09Z

Root-caused the middleware-mode failure ("Unknown server function: 9832c6f0-4-whoAmI") — it is not a regression in this PR, it's version skew:

e9b2a39 correctly reads the file hash from the second id segment, matching the identity-keyed <name>-<hash>[-<ordinal>] ids from A server function's id encodes its position in the file, so appending one re-points existing addresses solid#3109.
But #3109 hasn't shipped — the repo rides @solidjs/compiler 2.0.0-rc.4, which still mints positional <hash>-<ordinal>-<name> ids. Against those, split('-')[1] yields the ordinal, the id-to-module lookup misses, the module is never imported server-side, and dispatch refuses the call.
Plain dev mode passes only because the page graph loads the module anyway; middleware mode's direct endpoint is the one path that depends on the hash lookup.

This goes green once the repo bumps to the rc.5 compiler (which carries #3109). Blocked on the solid rc.5 release, nothing to fix here.

rc.5's argument parser treats a present body that decodes to nothing as malformed (400) where rc.4 ignored it, and the dev middlewares' node bridge attached `Readable.toWeb(req)` to every non-GET/HEAD request — so bodyless POSTs (zero-argument scripted calls, synthetic dispatches) started failing across dev and any prod host with the same conversion. Presence now follows the protocol signals: Content-Length or Transfer-Encoding on HTTP/1 (RFC 9112 §6), `stream.endAfterHeaders` on the h2 compat API. The start-ssr example's production server.js mirrors the same fix. Co-authored-by: Cursor <cursoragent@cursor.com>

rc.5 publishes the data-address split this branch routes (solidjs/solid#3094): the client transport computes `<endpoint>/data/<id>` for scripted calls while form actions and plain HTTP keep the bare `<endpoint>/<id>`, and ids are identity-keyed `<name>-<hash>[-<ordinal>]` (solidjs/solid#3109) — identical across dev and prod, so the suites' prod-id derivations collapse to the dev id. The workspace catalog moves to ^2.0.0-rc.5 (minimumReleaseAgeExclude extended per the existing pattern), the harness id extraction matches the name-first shape, and the CSRF rejection probes a registered id: rc.5 answers unknown ids 404 before the same-origin check runs. Full gate green against published rc.5 (no linking): ssr 12/12 + boundary 8/8, css-matrix 82/82 + bridge 19/19, start-ssr 366/366 + http-bridge 10/10, start-client 45/45, start-env 47/47, vite-8 vitest 1/1, cypress e2e 1/1. Co-authored-by: Cursor <cursoragent@cursor.com>

socket-security · 2026-09-01T18:29:34Z

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Package	Supply Chain Security	Quality	Maintenance
@solidjs/babel-plugin@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺⁴	⁺¹	⁺³
@solidjs/compiler@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺⁴		⁺²
@solidjs/diagnostics@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺¹		⁺¹
@solidjs/web@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺¹	⁺¹	⁺¹
solid-js@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺¹	⁺¹	⁺¹

View full report

socket-security · 2026-09-01T18:29:36Z

Warning

Review the following alerts detected in dependencies.

According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.

Action	Severity	Alert (click "▶" to expand/collapse)
Warn		Low adoption: npm `@solidjs/compiler-darwin-x64` Location:Package overview From:pnpm-lock.yaml → `npm/@solidjs/compiler@2.0.0-rc.5` → `npm/@solidjs/compiler-darwin-x64@2.0.0-rc.5` ℹ Read more on: This package \| This alert \| What are unpopular packages? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at `support@socket.dev`. Suggestion: Unpopular packages may have less maintenance and contain other problems. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/@solidjs/compiler-darwin-x64@2.0.0-rc.5`. You can also ignore all packages with `@SocketSecurity ignore-all`. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Low adoption: npm `@solidjs/compiler-linux-arm64-gnu` Location:Package overview From:pnpm-lock.yaml → `npm/@solidjs/compiler@2.0.0-rc.5` → `npm/@solidjs/compiler-linux-arm64-gnu@2.0.0-rc.5` ℹ Read more on: This package \| This alert \| What are unpopular packages? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at `support@socket.dev`. Suggestion: Unpopular packages may have less maintenance and contain other problems. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/@solidjs/compiler-linux-arm64-gnu@2.0.0-rc.5`. You can also ignore all packages with `@SocketSecurity ignore-all`. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.

View full report

ryansolid · 2026-08-29T21:18:50Z

Summary

Scripted server-function calls are moving to their own data address, <endpoint>/data/<id>, leaving the bare <endpoint>/<id> to plain HTTP (form actions, direct callers) — A cacheable raw Response is shaped by a request header nothing keys on solid#3094 (landed on next as solidjs/solid@95229453). The two caller kinds get differently shaped answers, and shared caches key on the URL, so the split keeps one caller kind's cached answer from ever being replayed to the other.
The dev middleware's module-preload step assumed exactly one path segment after the mount, so a cold function only client code references would never be evaluated in the SSR environment for a data-addressed call — a 404 under vite dev. The id now parses from behind the literal data segment too. A function id spelled data still parses at the bare address, since an id occupies exactly one segment.
Dispatch itself was already fine: mount matching is prefix-based, and the runtime handler accepts both address shapes. Comments on the mount gate updated to describe the two-address scheme.

Draft until a @solidjs/web carrying the data address ships (next release after 2.0.0-rc.4); safe to land early — the parsing change is additive.

Test plan

pnpm build (clean)
Example e2e suites pass against current @solidjs/web (old client, bare addresses — unaffected path)
After the next @solidjs/web release: vite dev against a client-only-referenced server function (cold SSR module) resolves at /_server/data/<id>

Made with Cursor

Scripted calls now go to <endpoint>/data/<id> (solidjs/solid#3094). The dev middleware's module-preload step assumed exactly one path segment after the mount, so a cold function only client code references would never be evaluated in the SSR environment for a data-addressed call — a 404 under vite dev. Dispatch was unaffected (mount matching is prefix-based); the id now parses from behind the literal data segment too. Co-authored-by: Cursor <cursoragent@cursor.com>

changeset-bot · 2026-08-29T21:18:54Z

🦋 Changeset detected

Latest commit: 1e0c5ef

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@solidjs/vite-plugin	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

pkg-pr-new · 2026-08-29T21:19:23Z

Open in StackBlitz

npm i https://pkg.pr.new/@solidjs/vite-plugin@335

commit: 1e0c5ef

solidjs/solid#3109) Co-authored-by: Cursor <cursoragent@cursor.com>

The RC is already breaking addresses (the data-address split), so the transitional X-Server-Function-Id header and ?id= addressing leave with the runtime's own shims — path-only addressing is the protocol (solidjs/solid#3094). Co-authored-by: Cursor <cursoragent@cursor.com>

ryansolid · 2026-08-31T21:45:09Z

Root-caused the middleware-mode failure ("Unknown server function: 9832c6f0-4-whoAmI") — it is not a regression in this PR, it's version skew:

e9b2a39 correctly reads the file hash from the second id segment, matching the identity-keyed <name>-<hash>[-<ordinal>] ids from A server function's id encodes its position in the file, so appending one re-points existing addresses solid#3109.
But #3109 hasn't shipped — the repo rides @solidjs/compiler 2.0.0-rc.4, which still mints positional <hash>-<ordinal>-<name> ids. Against those, split('-')[1] yields the ordinal, the id-to-module lookup misses, the module is never imported server-side, and dispatch refuses the call.
Plain dev mode passes only because the page graph loads the module anyway; middleware mode's direct endpoint is the one path that depends on the hash lookup.

This goes green once the repo bumps to the rc.5 compiler (which carries #3109). Blocked on the solid rc.5 release, nothing to fix here.

rc.5's argument parser treats a present body that decodes to nothing as malformed (400) where rc.4 ignored it, and the dev middlewares' node bridge attached `Readable.toWeb(req)` to every non-GET/HEAD request — so bodyless POSTs (zero-argument scripted calls, synthetic dispatches) started failing across dev and any prod host with the same conversion. Presence now follows the protocol signals: Content-Length or Transfer-Encoding on HTTP/1 (RFC 9112 §6), `stream.endAfterHeaders` on the h2 compat API. The start-ssr example's production server.js mirrors the same fix. Co-authored-by: Cursor <cursoragent@cursor.com>

rc.5 publishes the data-address split this branch routes (solidjs/solid#3094): the client transport computes `<endpoint>/data/<id>` for scripted calls while form actions and plain HTTP keep the bare `<endpoint>/<id>`, and ids are identity-keyed `<name>-<hash>[-<ordinal>]` (solidjs/solid#3109) — identical across dev and prod, so the suites' prod-id derivations collapse to the dev id. The workspace catalog moves to ^2.0.0-rc.5 (minimumReleaseAgeExclude extended per the existing pattern), the harness id extraction matches the name-first shape, and the CSRF rejection probes a registered id: rc.5 answers unknown ids 404 before the same-origin check runs. Full gate green against published rc.5 (no linking): ssr 12/12 + boundary 8/8, css-matrix 82/82 + bridge 19/19, start-ssr 366/366 + http-bridge 10/10, start-client 45/45, start-env 47/47, vite-8 vitest 1/1, cypress e2e 1/1. Co-authored-by: Cursor <cursoragent@cursor.com>

socket-security · 2026-09-01T18:29:34Z

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Package	Supply Chain Security	Quality	Maintenance
@solidjs/babel-plugin@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺⁴	⁺¹	⁺³
@solidjs/compiler@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺⁴		⁺²
@solidjs/diagnostics@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺¹		⁺¹
@solidjs/web@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺¹	⁺¹	⁺¹
solid-js@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺¹	⁺¹	⁺¹

View full report

socket-security · 2026-09-01T18:29:36Z

Warning

Review the following alerts detected in dependencies.

According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.

Action	Severity	Alert (click "▶" to expand/collapse)
Warn		Low adoption: npm `@solidjs/compiler-darwin-x64` Location:Package overview From:pnpm-lock.yaml → `npm/@solidjs/compiler@2.0.0-rc.5` → `npm/@solidjs/compiler-darwin-x64@2.0.0-rc.5` ℹ Read more on: This package \| This alert \| What are unpopular packages? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at `support@socket.dev`. Suggestion: Unpopular packages may have less maintenance and contain other problems. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/@solidjs/compiler-darwin-x64@2.0.0-rc.5`. You can also ignore all packages with `@SocketSecurity ignore-all`. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Low adoption: npm `@solidjs/compiler-linux-arm64-gnu` Location:Package overview From:pnpm-lock.yaml → `npm/@solidjs/compiler@2.0.0-rc.5` → `npm/@solidjs/compiler-linux-arm64-gnu@2.0.0-rc.5` ℹ Read more on: This package \| This alert \| What are unpopular packages? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at `support@socket.dev`. Suggestion: Unpopular packages may have less maintenance and contain other problems. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/@solidjs/compiler-linux-arm64-gnu@2.0.0-rc.5`. You can also ignore all packages with `@SocketSecurity ignore-all`. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.

View full report

ryansolid · 2026-08-29T21:18:50Z

Summary

Scripted server-function calls are moving to their own data address, <endpoint>/data/<id>, leaving the bare <endpoint>/<id> to plain HTTP (form actions, direct callers) — A cacheable raw Response is shaped by a request header nothing keys on solid#3094 (landed on next as solidjs/solid@95229453). The two caller kinds get differently shaped answers, and shared caches key on the URL, so the split keeps one caller kind's cached answer from ever being replayed to the other.
The dev middleware's module-preload step assumed exactly one path segment after the mount, so a cold function only client code references would never be evaluated in the SSR environment for a data-addressed call — a 404 under vite dev. The id now parses from behind the literal data segment too. A function id spelled data still parses at the bare address, since an id occupies exactly one segment.
Dispatch itself was already fine: mount matching is prefix-based, and the runtime handler accepts both address shapes. Comments on the mount gate updated to describe the two-address scheme.

Draft until a @solidjs/web carrying the data address ships (next release after 2.0.0-rc.4); safe to land early — the parsing change is additive.

Test plan

pnpm build (clean)
Example e2e suites pass against current @solidjs/web (old client, bare addresses — unaffected path)
After the next @solidjs/web release: vite dev against a client-only-referenced server function (cold SSR module) resolves at /_server/data/<id>

Made with Cursor

Scripted calls now go to <endpoint>/data/<id> (solidjs/solid#3094). The dev middleware's module-preload step assumed exactly one path segment after the mount, so a cold function only client code references would never be evaluated in the SSR environment for a data-addressed call — a 404 under vite dev. Dispatch was unaffected (mount matching is prefix-based); the id now parses from behind the literal data segment too. Co-authored-by: Cursor <cursoragent@cursor.com>

changeset-bot · 2026-08-29T21:18:54Z

🦋 Changeset detected

Latest commit: 1e0c5ef

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@solidjs/vite-plugin	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

pkg-pr-new · 2026-08-29T21:19:23Z

Open in StackBlitz

npm i https://pkg.pr.new/@solidjs/vite-plugin@335

commit: 1e0c5ef

solidjs/solid#3109) Co-authored-by: Cursor <cursoragent@cursor.com>

The RC is already breaking addresses (the data-address split), so the transitional X-Server-Function-Id header and ?id= addressing leave with the runtime's own shims — path-only addressing is the protocol (solidjs/solid#3094). Co-authored-by: Cursor <cursoragent@cursor.com>

ryansolid · 2026-08-31T21:45:09Z

Root-caused the middleware-mode failure ("Unknown server function: 9832c6f0-4-whoAmI") — it is not a regression in this PR, it's version skew:

e9b2a39 correctly reads the file hash from the second id segment, matching the identity-keyed <name>-<hash>[-<ordinal>] ids from A server function's id encodes its position in the file, so appending one re-points existing addresses solid#3109.
But #3109 hasn't shipped — the repo rides @solidjs/compiler 2.0.0-rc.4, which still mints positional <hash>-<ordinal>-<name> ids. Against those, split('-')[1] yields the ordinal, the id-to-module lookup misses, the module is never imported server-side, and dispatch refuses the call.
Plain dev mode passes only because the page graph loads the module anyway; middleware mode's direct endpoint is the one path that depends on the hash lookup.

This goes green once the repo bumps to the rc.5 compiler (which carries #3109). Blocked on the solid rc.5 release, nothing to fix here.

rc.5's argument parser treats a present body that decodes to nothing as malformed (400) where rc.4 ignored it, and the dev middlewares' node bridge attached `Readable.toWeb(req)` to every non-GET/HEAD request — so bodyless POSTs (zero-argument scripted calls, synthetic dispatches) started failing across dev and any prod host with the same conversion. Presence now follows the protocol signals: Content-Length or Transfer-Encoding on HTTP/1 (RFC 9112 §6), `stream.endAfterHeaders` on the h2 compat API. The start-ssr example's production server.js mirrors the same fix. Co-authored-by: Cursor <cursoragent@cursor.com>

rc.5 publishes the data-address split this branch routes (solidjs/solid#3094): the client transport computes `<endpoint>/data/<id>` for scripted calls while form actions and plain HTTP keep the bare `<endpoint>/<id>`, and ids are identity-keyed `<name>-<hash>[-<ordinal>]` (solidjs/solid#3109) — identical across dev and prod, so the suites' prod-id derivations collapse to the dev id. The workspace catalog moves to ^2.0.0-rc.5 (minimumReleaseAgeExclude extended per the existing pattern), the harness id extraction matches the name-first shape, and the CSRF rejection probes a registered id: rc.5 answers unknown ids 404 before the same-origin check runs. Full gate green against published rc.5 (no linking): ssr 12/12 + boundary 8/8, css-matrix 82/82 + bridge 19/19, start-ssr 366/366 + http-bridge 10/10, start-client 45/45, start-env 47/47, vite-8 vitest 1/1, cypress e2e 1/1. Co-authored-by: Cursor <cursoragent@cursor.com>

socket-security · 2026-09-01T18:29:34Z

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Package	Supply Chain Security	Quality	Maintenance
@solidjs/babel-plugin@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺⁴	⁺¹	⁺³
@solidjs/compiler@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺⁴		⁺²
@solidjs/diagnostics@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺¹		⁺¹
@solidjs/web@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺¹	⁺¹	⁺¹
solid-js@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺¹	⁺¹	⁺¹

View full report

socket-security · 2026-09-01T18:29:36Z

Warning

Review the following alerts detected in dependencies.

According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.

Action	Severity	Alert (click "▶" to expand/collapse)
Warn		Low adoption: npm `@solidjs/compiler-darwin-x64` Location:Package overview From:pnpm-lock.yaml → `npm/@solidjs/compiler@2.0.0-rc.5` → `npm/@solidjs/compiler-darwin-x64@2.0.0-rc.5` ℹ Read more on: This package \| This alert \| What are unpopular packages? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at `support@socket.dev`. Suggestion: Unpopular packages may have less maintenance and contain other problems. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/@solidjs/compiler-darwin-x64@2.0.0-rc.5`. You can also ignore all packages with `@SocketSecurity ignore-all`. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Low adoption: npm `@solidjs/compiler-linux-arm64-gnu` Location:Package overview From:pnpm-lock.yaml → `npm/@solidjs/compiler@2.0.0-rc.5` → `npm/@solidjs/compiler-linux-arm64-gnu@2.0.0-rc.5` ℹ Read more on: This package \| This alert \| What are unpopular packages? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at `support@socket.dev`. Suggestion: Unpopular packages may have less maintenance and contain other problems. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/@solidjs/compiler-linux-arm64-gnu@2.0.0-rc.5`. You can also ignore all packages with `@SocketSecurity ignore-all`. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.

View full report

ryansolid · 2026-08-29T21:18:50Z

Summary

Scripted server-function calls are moving to their own data address, <endpoint>/data/<id>, leaving the bare <endpoint>/<id> to plain HTTP (form actions, direct callers) — A cacheable raw Response is shaped by a request header nothing keys on solid#3094 (landed on next as solidjs/solid@95229453). The two caller kinds get differently shaped answers, and shared caches key on the URL, so the split keeps one caller kind's cached answer from ever being replayed to the other.
The dev middleware's module-preload step assumed exactly one path segment after the mount, so a cold function only client code references would never be evaluated in the SSR environment for a data-addressed call — a 404 under vite dev. The id now parses from behind the literal data segment too. A function id spelled data still parses at the bare address, since an id occupies exactly one segment.
Dispatch itself was already fine: mount matching is prefix-based, and the runtime handler accepts both address shapes. Comments on the mount gate updated to describe the two-address scheme.

Draft until a @solidjs/web carrying the data address ships (next release after 2.0.0-rc.4); safe to land early — the parsing change is additive.

Test plan

pnpm build (clean)
Example e2e suites pass against current @solidjs/web (old client, bare addresses — unaffected path)
After the next @solidjs/web release: vite dev against a client-only-referenced server function (cold SSR module) resolves at /_server/data/<id>

Made with Cursor

Scripted calls now go to <endpoint>/data/<id> (solidjs/solid#3094). The dev middleware's module-preload step assumed exactly one path segment after the mount, so a cold function only client code references would never be evaluated in the SSR environment for a data-addressed call — a 404 under vite dev. Dispatch was unaffected (mount matching is prefix-based); the id now parses from behind the literal data segment too. Co-authored-by: Cursor <cursoragent@cursor.com>

changeset-bot · 2026-08-29T21:18:54Z

🦋 Changeset detected

Latest commit: 1e0c5ef

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@solidjs/vite-plugin	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

pkg-pr-new · 2026-08-29T21:19:23Z

Open in StackBlitz

npm i https://pkg.pr.new/@solidjs/vite-plugin@335

commit: 1e0c5ef

solidjs/solid#3109) Co-authored-by: Cursor <cursoragent@cursor.com>

The RC is already breaking addresses (the data-address split), so the transitional X-Server-Function-Id header and ?id= addressing leave with the runtime's own shims — path-only addressing is the protocol (solidjs/solid#3094). Co-authored-by: Cursor <cursoragent@cursor.com>

ryansolid · 2026-08-31T21:45:09Z

Root-caused the middleware-mode failure ("Unknown server function: 9832c6f0-4-whoAmI") — it is not a regression in this PR, it's version skew:

e9b2a39 correctly reads the file hash from the second id segment, matching the identity-keyed <name>-<hash>[-<ordinal>] ids from A server function's id encodes its position in the file, so appending one re-points existing addresses solid#3109.
But #3109 hasn't shipped — the repo rides @solidjs/compiler 2.0.0-rc.4, which still mints positional <hash>-<ordinal>-<name> ids. Against those, split('-')[1] yields the ordinal, the id-to-module lookup misses, the module is never imported server-side, and dispatch refuses the call.
Plain dev mode passes only because the page graph loads the module anyway; middleware mode's direct endpoint is the one path that depends on the hash lookup.

This goes green once the repo bumps to the rc.5 compiler (which carries #3109). Blocked on the solid rc.5 release, nothing to fix here.

rc.5's argument parser treats a present body that decodes to nothing as malformed (400) where rc.4 ignored it, and the dev middlewares' node bridge attached `Readable.toWeb(req)` to every non-GET/HEAD request — so bodyless POSTs (zero-argument scripted calls, synthetic dispatches) started failing across dev and any prod host with the same conversion. Presence now follows the protocol signals: Content-Length or Transfer-Encoding on HTTP/1 (RFC 9112 §6), `stream.endAfterHeaders` on the h2 compat API. The start-ssr example's production server.js mirrors the same fix. Co-authored-by: Cursor <cursoragent@cursor.com>

rc.5 publishes the data-address split this branch routes (solidjs/solid#3094): the client transport computes `<endpoint>/data/<id>` for scripted calls while form actions and plain HTTP keep the bare `<endpoint>/<id>`, and ids are identity-keyed `<name>-<hash>[-<ordinal>]` (solidjs/solid#3109) — identical across dev and prod, so the suites' prod-id derivations collapse to the dev id. The workspace catalog moves to ^2.0.0-rc.5 (minimumReleaseAgeExclude extended per the existing pattern), the harness id extraction matches the name-first shape, and the CSRF rejection probes a registered id: rc.5 answers unknown ids 404 before the same-origin check runs. Full gate green against published rc.5 (no linking): ssr 12/12 + boundary 8/8, css-matrix 82/82 + bridge 19/19, start-ssr 366/366 + http-bridge 10/10, start-client 45/45, start-env 47/47, vite-8 vitest 1/1, cypress e2e 1/1. Co-authored-by: Cursor <cursoragent@cursor.com>

socket-security · 2026-09-01T18:29:34Z

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Package	Supply Chain Security	Quality	Maintenance
@solidjs/babel-plugin@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺⁴	⁺¹	⁺³
@solidjs/compiler@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺⁴		⁺²
@solidjs/diagnostics@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺¹		⁺¹
@solidjs/web@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺¹	⁺¹	⁺¹
solid-js@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺¹	⁺¹	⁺¹

View full report

socket-security · 2026-09-01T18:29:36Z

Warning

Review the following alerts detected in dependencies.

According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.

Action	Severity	Alert (click "▶" to expand/collapse)
Warn		Low adoption: npm `@solidjs/compiler-darwin-x64` Location:Package overview From:pnpm-lock.yaml → `npm/@solidjs/compiler@2.0.0-rc.5` → `npm/@solidjs/compiler-darwin-x64@2.0.0-rc.5` ℹ Read more on: This package \| This alert \| What are unpopular packages? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at `support@socket.dev`. Suggestion: Unpopular packages may have less maintenance and contain other problems. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/@solidjs/compiler-darwin-x64@2.0.0-rc.5`. You can also ignore all packages with `@SocketSecurity ignore-all`. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Low adoption: npm `@solidjs/compiler-linux-arm64-gnu` Location:Package overview From:pnpm-lock.yaml → `npm/@solidjs/compiler@2.0.0-rc.5` → `npm/@solidjs/compiler-linux-arm64-gnu@2.0.0-rc.5` ℹ Read more on: This package \| This alert \| What are unpopular packages? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at `support@socket.dev`. Suggestion: Unpopular packages may have less maintenance and contain other problems. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/@solidjs/compiler-linux-arm64-gnu@2.0.0-rc.5`. You can also ignore all packages with `@SocketSecurity ignore-all`. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.

View full report

ryansolid · 2026-08-29T21:18:50Z

Summary

Scripted server-function calls are moving to their own data address, <endpoint>/data/<id>, leaving the bare <endpoint>/<id> to plain HTTP (form actions, direct callers) — A cacheable raw Response is shaped by a request header nothing keys on solid#3094 (landed on next as solidjs/solid@95229453). The two caller kinds get differently shaped answers, and shared caches key on the URL, so the split keeps one caller kind's cached answer from ever being replayed to the other.
The dev middleware's module-preload step assumed exactly one path segment after the mount, so a cold function only client code references would never be evaluated in the SSR environment for a data-addressed call — a 404 under vite dev. The id now parses from behind the literal data segment too. A function id spelled data still parses at the bare address, since an id occupies exactly one segment.
Dispatch itself was already fine: mount matching is prefix-based, and the runtime handler accepts both address shapes. Comments on the mount gate updated to describe the two-address scheme.

Draft until a @solidjs/web carrying the data address ships (next release after 2.0.0-rc.4); safe to land early — the parsing change is additive.

Test plan

pnpm build (clean)
Example e2e suites pass against current @solidjs/web (old client, bare addresses — unaffected path)
After the next @solidjs/web release: vite dev against a client-only-referenced server function (cold SSR module) resolves at /_server/data/<id>

Made with Cursor

Scripted calls now go to <endpoint>/data/<id> (solidjs/solid#3094). The dev middleware's module-preload step assumed exactly one path segment after the mount, so a cold function only client code references would never be evaluated in the SSR environment for a data-addressed call — a 404 under vite dev. Dispatch was unaffected (mount matching is prefix-based); the id now parses from behind the literal data segment too. Co-authored-by: Cursor <cursoragent@cursor.com>

changeset-bot · 2026-08-29T21:18:54Z

🦋 Changeset detected

Latest commit: 1e0c5ef

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@solidjs/vite-plugin	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

pkg-pr-new · 2026-08-29T21:19:23Z

Open in StackBlitz

npm i https://pkg.pr.new/@solidjs/vite-plugin@335

commit: 1e0c5ef

solidjs/solid#3109) Co-authored-by: Cursor <cursoragent@cursor.com>

The RC is already breaking addresses (the data-address split), so the transitional X-Server-Function-Id header and ?id= addressing leave with the runtime's own shims — path-only addressing is the protocol (solidjs/solid#3094). Co-authored-by: Cursor <cursoragent@cursor.com>

ryansolid · 2026-08-31T21:45:09Z

Root-caused the middleware-mode failure ("Unknown server function: 9832c6f0-4-whoAmI") — it is not a regression in this PR, it's version skew:

e9b2a39 correctly reads the file hash from the second id segment, matching the identity-keyed <name>-<hash>[-<ordinal>] ids from A server function's id encodes its position in the file, so appending one re-points existing addresses solid#3109.
But #3109 hasn't shipped — the repo rides @solidjs/compiler 2.0.0-rc.4, which still mints positional <hash>-<ordinal>-<name> ids. Against those, split('-')[1] yields the ordinal, the id-to-module lookup misses, the module is never imported server-side, and dispatch refuses the call.
Plain dev mode passes only because the page graph loads the module anyway; middleware mode's direct endpoint is the one path that depends on the hash lookup.

This goes green once the repo bumps to the rc.5 compiler (which carries #3109). Blocked on the solid rc.5 release, nothing to fix here.

rc.5's argument parser treats a present body that decodes to nothing as malformed (400) where rc.4 ignored it, and the dev middlewares' node bridge attached `Readable.toWeb(req)` to every non-GET/HEAD request — so bodyless POSTs (zero-argument scripted calls, synthetic dispatches) started failing across dev and any prod host with the same conversion. Presence now follows the protocol signals: Content-Length or Transfer-Encoding on HTTP/1 (RFC 9112 §6), `stream.endAfterHeaders` on the h2 compat API. The start-ssr example's production server.js mirrors the same fix. Co-authored-by: Cursor <cursoragent@cursor.com>

rc.5 publishes the data-address split this branch routes (solidjs/solid#3094): the client transport computes `<endpoint>/data/<id>` for scripted calls while form actions and plain HTTP keep the bare `<endpoint>/<id>`, and ids are identity-keyed `<name>-<hash>[-<ordinal>]` (solidjs/solid#3109) — identical across dev and prod, so the suites' prod-id derivations collapse to the dev id. The workspace catalog moves to ^2.0.0-rc.5 (minimumReleaseAgeExclude extended per the existing pattern), the harness id extraction matches the name-first shape, and the CSRF rejection probes a registered id: rc.5 answers unknown ids 404 before the same-origin check runs. Full gate green against published rc.5 (no linking): ssr 12/12 + boundary 8/8, css-matrix 82/82 + bridge 19/19, start-ssr 366/366 + http-bridge 10/10, start-client 45/45, start-env 47/47, vite-8 vitest 1/1, cypress e2e 1/1. Co-authored-by: Cursor <cursoragent@cursor.com>

socket-security · 2026-09-01T18:29:34Z

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Package	Supply Chain Security	Quality	Maintenance
@solidjs/babel-plugin@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺⁴	⁺¹	⁺³
@solidjs/compiler@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺⁴		⁺²
@solidjs/diagnostics@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺¹		⁺¹
@solidjs/web@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺¹	⁺¹	⁺¹
solid-js@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺¹	⁺¹	⁺¹

View full report

socket-security · 2026-09-01T18:29:36Z

Warning

Review the following alerts detected in dependencies.

According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.

Action	Severity	Alert (click "▶" to expand/collapse)
Warn		Low adoption: npm `@solidjs/compiler-darwin-x64` Location:Package overview From:pnpm-lock.yaml → `npm/@solidjs/compiler@2.0.0-rc.5` → `npm/@solidjs/compiler-darwin-x64@2.0.0-rc.5` ℹ Read more on: This package \| This alert \| What are unpopular packages? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at `support@socket.dev`. Suggestion: Unpopular packages may have less maintenance and contain other problems. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/@solidjs/compiler-darwin-x64@2.0.0-rc.5`. You can also ignore all packages with `@SocketSecurity ignore-all`. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Low adoption: npm `@solidjs/compiler-linux-arm64-gnu` Location:Package overview From:pnpm-lock.yaml → `npm/@solidjs/compiler@2.0.0-rc.5` → `npm/@solidjs/compiler-linux-arm64-gnu@2.0.0-rc.5` ℹ Read more on: This package \| This alert \| What are unpopular packages? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at `support@socket.dev`. Suggestion: Unpopular packages may have less maintenance and contain other problems. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/@solidjs/compiler-linux-arm64-gnu@2.0.0-rc.5`. You can also ignore all packages with `@SocketSecurity ignore-all`. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.

View full report

ryansolid · 2026-08-29T21:18:50Z

Summary

Scripted server-function calls are moving to their own data address, <endpoint>/data/<id>, leaving the bare <endpoint>/<id> to plain HTTP (form actions, direct callers) — A cacheable raw Response is shaped by a request header nothing keys on solid#3094 (landed on next as solidjs/solid@95229453). The two caller kinds get differently shaped answers, and shared caches key on the URL, so the split keeps one caller kind's cached answer from ever being replayed to the other.
The dev middleware's module-preload step assumed exactly one path segment after the mount, so a cold function only client code references would never be evaluated in the SSR environment for a data-addressed call — a 404 under vite dev. The id now parses from behind the literal data segment too. A function id spelled data still parses at the bare address, since an id occupies exactly one segment.
Dispatch itself was already fine: mount matching is prefix-based, and the runtime handler accepts both address shapes. Comments on the mount gate updated to describe the two-address scheme.

Draft until a @solidjs/web carrying the data address ships (next release after 2.0.0-rc.4); safe to land early — the parsing change is additive.

Test plan

pnpm build (clean)
Example e2e suites pass against current @solidjs/web (old client, bare addresses — unaffected path)
After the next @solidjs/web release: vite dev against a client-only-referenced server function (cold SSR module) resolves at /_server/data/<id>

Made with Cursor

Scripted calls now go to <endpoint>/data/<id> (solidjs/solid#3094). The dev middleware's module-preload step assumed exactly one path segment after the mount, so a cold function only client code references would never be evaluated in the SSR environment for a data-addressed call — a 404 under vite dev. Dispatch was unaffected (mount matching is prefix-based); the id now parses from behind the literal data segment too. Co-authored-by: Cursor <cursoragent@cursor.com>

changeset-bot · 2026-08-29T21:18:54Z

🦋 Changeset detected

Latest commit: 1e0c5ef

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@solidjs/vite-plugin	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

pkg-pr-new · 2026-08-29T21:19:23Z

Open in StackBlitz

npm i https://pkg.pr.new/@solidjs/vite-plugin@335

commit: 1e0c5ef

solidjs/solid#3109) Co-authored-by: Cursor <cursoragent@cursor.com>

The RC is already breaking addresses (the data-address split), so the transitional X-Server-Function-Id header and ?id= addressing leave with the runtime's own shims — path-only addressing is the protocol (solidjs/solid#3094). Co-authored-by: Cursor <cursoragent@cursor.com>

ryansolid · 2026-08-31T21:45:09Z

Root-caused the middleware-mode failure ("Unknown server function: 9832c6f0-4-whoAmI") — it is not a regression in this PR, it's version skew:

e9b2a39 correctly reads the file hash from the second id segment, matching the identity-keyed <name>-<hash>[-<ordinal>] ids from A server function's id encodes its position in the file, so appending one re-points existing addresses solid#3109.
But #3109 hasn't shipped — the repo rides @solidjs/compiler 2.0.0-rc.4, which still mints positional <hash>-<ordinal>-<name> ids. Against those, split('-')[1] yields the ordinal, the id-to-module lookup misses, the module is never imported server-side, and dispatch refuses the call.
Plain dev mode passes only because the page graph loads the module anyway; middleware mode's direct endpoint is the one path that depends on the hash lookup.

This goes green once the repo bumps to the rc.5 compiler (which carries #3109). Blocked on the solid rc.5 release, nothing to fix here.

rc.5's argument parser treats a present body that decodes to nothing as malformed (400) where rc.4 ignored it, and the dev middlewares' node bridge attached `Readable.toWeb(req)` to every non-GET/HEAD request — so bodyless POSTs (zero-argument scripted calls, synthetic dispatches) started failing across dev and any prod host with the same conversion. Presence now follows the protocol signals: Content-Length or Transfer-Encoding on HTTP/1 (RFC 9112 §6), `stream.endAfterHeaders` on the h2 compat API. The start-ssr example's production server.js mirrors the same fix. Co-authored-by: Cursor <cursoragent@cursor.com>

rc.5 publishes the data-address split this branch routes (solidjs/solid#3094): the client transport computes `<endpoint>/data/<id>` for scripted calls while form actions and plain HTTP keep the bare `<endpoint>/<id>`, and ids are identity-keyed `<name>-<hash>[-<ordinal>]` (solidjs/solid#3109) — identical across dev and prod, so the suites' prod-id derivations collapse to the dev id. The workspace catalog moves to ^2.0.0-rc.5 (minimumReleaseAgeExclude extended per the existing pattern), the harness id extraction matches the name-first shape, and the CSRF rejection probes a registered id: rc.5 answers unknown ids 404 before the same-origin check runs. Full gate green against published rc.5 (no linking): ssr 12/12 + boundary 8/8, css-matrix 82/82 + bridge 19/19, start-ssr 366/366 + http-bridge 10/10, start-client 45/45, start-env 47/47, vite-8 vitest 1/1, cypress e2e 1/1. Co-authored-by: Cursor <cursoragent@cursor.com>

socket-security · 2026-09-01T18:29:34Z

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Package	Supply Chain Security	Quality	Maintenance
@solidjs/babel-plugin@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺⁴	⁺¹	⁺³
@solidjs/compiler@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺⁴		⁺²
@solidjs/diagnostics@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺¹		⁺¹
@solidjs/web@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺¹	⁺¹	⁺¹
solid-js@2.0.0-rc.4 ⏵ 2.0.0-rc.5	⁺¹	⁺¹	⁺¹

View full report

socket-security · 2026-09-01T18:29:36Z

Warning

Review the following alerts detected in dependencies.

According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.

Action	Severity	Alert (click "▶" to expand/collapse)
Warn		Low adoption: npm `@solidjs/compiler-darwin-x64` Location:Package overview From:pnpm-lock.yaml → `npm/@solidjs/compiler@2.0.0-rc.5` → `npm/@solidjs/compiler-darwin-x64@2.0.0-rc.5` ℹ Read more on: This package \| This alert \| What are unpopular packages? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at `support@socket.dev`. Suggestion: Unpopular packages may have less maintenance and contain other problems. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/@solidjs/compiler-darwin-x64@2.0.0-rc.5`. You can also ignore all packages with `@SocketSecurity ignore-all`. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Low adoption: npm `@solidjs/compiler-linux-arm64-gnu` Location:Package overview From:pnpm-lock.yaml → `npm/@solidjs/compiler@2.0.0-rc.5` → `npm/@solidjs/compiler-linux-arm64-gnu@2.0.0-rc.5` ℹ Read more on: This package \| This alert \| What are unpopular packages? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at `support@socket.dev`. Suggestion: Unpopular packages may have less maintenance and contain other problems. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/@solidjs/compiler-linux-arm64-gnu@2.0.0-rc.5`. You can also ignore all packages with `@SocketSecurity ignore-all`. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.

View full report

ryansolid mentioned this pull request Aug 29, 2026
A cacheable raw Response is shaped by a request header nothing keys on solidjs/solid#3094
Closed

ryansolidand others added 2 commits August 29, 2026 22:17

fix: read the file hash from the second id segment (identity-keyed ids,
e9b2a39
solidjs/solid#3109) Co-authored-by: Cursor <cursoragent@cursor.com>

ryansolidand others added 2 commits September 1, 2026 11:28

ryansolid marked this pull request as ready for review September 1, 2026 18:29

ryansolid merged commit 03c5628 into nextSep 1, 2026
6 checks passed

ryansolid mentioned this pull request Aug 29, 2026
A cacheable raw Response is shaped by a request header nothing keys on solidjs/solid#3094
Closed

ryansolidand others added 2 commits August 29, 2026 22:17

fix: read the file hash from the second id segment (identity-keyed ids,
e9b2a39
solidjs/solid#3109) Co-authored-by: Cursor <cursoragent@cursor.com>

ryansolidand others added 2 commits September 1, 2026 11:28

ryansolid marked this pull request as ready for review September 1, 2026 18:29

ryansolid merged commit 03c5628 into nextSep 1, 2026
6 checks passed

ryansolid mentioned this pull request Aug 29, 2026
A cacheable raw Response is shaped by a request header nothing keys on solidjs/solid#3094
Closed

ryansolidand others added 2 commits August 29, 2026 22:17

fix: read the file hash from the second id segment (identity-keyed ids,
e9b2a39
solidjs/solid#3109) Co-authored-by: Cursor <cursoragent@cursor.com>

ryansolidand others added 2 commits September 1, 2026 11:28

ryansolid marked this pull request as ready for review September 1, 2026 18:29

ryansolid merged commit 03c5628 into nextSep 1, 2026
6 checks passed

ryansolid mentioned this pull request Aug 29, 2026
A cacheable raw Response is shaped by a request header nothing keys on solidjs/solid#3094
Closed

ryansolidand others added 2 commits August 29, 2026 22:17

fix: read the file hash from the second id segment (identity-keyed ids,
e9b2a39
solidjs/solid#3109) Co-authored-by: Cursor <cursoragent@cursor.com>

ryansolidand others added 2 commits September 1, 2026 11:28

ryansolid marked this pull request as ready for review September 1, 2026 18:29

ryansolid merged commit 03c5628 into nextSep 1, 2026
6 checks passed

ryansolid mentioned this pull request Aug 29, 2026
A cacheable raw Response is shaped by a request header nothing keys on solidjs/solid#3094
Closed

ryansolidand others added 2 commits August 29, 2026 22:17

fix: read the file hash from the second id segment (identity-keyed ids,
e9b2a39
solidjs/solid#3109) Co-authored-by: Cursor <cursoragent@cursor.com>

ryansolidand others added 2 commits September 1, 2026 11:28

ryansolid marked this pull request as ready for review September 1, 2026 18:29

ryansolid merged commit 03c5628 into nextSep 1, 2026
6 checks passed

ryansolid mentioned this pull request Aug 29, 2026
A cacheable raw Response is shaped by a request header nothing keys on solidjs/solid#3094
Closed

ryansolidand others added 2 commits August 29, 2026 22:17

fix: read the file hash from the second id segment (identity-keyed ids,
e9b2a39
solidjs/solid#3109) Co-authored-by: Cursor <cursoragent@cursor.com>

ryansolidand others added 2 commits September 1, 2026 11:28

ryansolid marked this pull request as ready for review September 1, 2026 18:29

ryansolid merged commit 03c5628 into nextSep 1, 2026
6 checks passed

ryansolid mentioned this pull request Aug 29, 2026
A cacheable raw Response is shaped by a request header nothing keys on solidjs/solid#3094
Closed

ryansolidand others added 2 commits August 29, 2026 22:17

fix: read the file hash from the second id segment (identity-keyed ids,
e9b2a39
solidjs/solid#3109) Co-authored-by: Cursor <cursoragent@cursor.com>

ryansolidand others added 2 commits September 1, 2026 11:28

ryansolid marked this pull request as ready for review September 1, 2026 18:29

ryansolid merged commit 03c5628 into nextSep 1, 2026
6 checks passed

ryansolid mentioned this pull request Aug 29, 2026
A cacheable raw Response is shaped by a request header nothing keys on solidjs/solid#3094
Closed

ryansolidand others added 2 commits August 29, 2026 22:17

fix: read the file hash from the second id segment (identity-keyed ids,
e9b2a39
solidjs/solid#3109) Co-authored-by: Cursor <cursoragent@cursor.com>

ryansolidand others added 2 commits September 1, 2026 11:28

ryansolid marked this pull request as ready for review September 1, 2026 18:29

ryansolid merged commit 03c5628 into nextSep 1, 2026
6 checks passed

Uh oh!

Conversation

ryansolid commented Aug 29, 2026

Summary

Test plan

Uh oh!

changeset-botBot commented Aug 29, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🦋 Changeset detected

Uh oh!

pkg-pr-newBot commented Aug 29, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ryansolid commented Aug 31, 2026

Uh oh!

socket-securityBot commented Sep 1, 2026

Uh oh!

socket-securityBot commented Sep 1, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

ryansolid commented Aug 29, 2026

Summary

Test plan

Uh oh!

changeset-botBot commented Aug 29, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🦋 Changeset detected

Uh oh!

pkg-pr-newBot commented Aug 29, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ryansolid commented Aug 31, 2026

Uh oh!

socket-securityBot commented Sep 1, 2026

Uh oh!

socket-securityBot commented Sep 1, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

ryansolid commented Aug 29, 2026

Summary

Test plan

Uh oh!

changeset-botBot commented Aug 29, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🦋 Changeset detected

Uh oh!

pkg-pr-newBot commented Aug 29, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ryansolid commented Aug 31, 2026

Uh oh!

socket-securityBot commented Sep 1, 2026

Uh oh!

socket-securityBot commented Sep 1, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

changeset-botBot commented Aug 29, 2026•
edited
Loading

pkg-pr-newBot commented Aug 29, 2026•
edited
Loading

changeset-botBot commented Aug 29, 2026•
edited
Loading

pkg-pr-newBot commented Aug 29, 2026•
edited
Loading

changeset-botBot commented Aug 29, 2026•
edited
Loading

pkg-pr-newBot commented Aug 29, 2026•
edited
Loading

changeset-botBot commented Aug 29, 2026•
edited
Loading

pkg-pr-newBot commented Aug 29, 2026•
edited
Loading

changeset-botBot commented Aug 29, 2026•
edited
Loading

pkg-pr-newBot commented Aug 29, 2026•
edited
Loading