Repository navigation
Version Packages (next) - #472
Merged
Merged
Conversation
github-actions
Bot
force-pushed
the
changeset-release/next
branch
12 times, most recently
from
October 28, 2026 05:31
3cbef18 to
accb80e
Compare
github-actions
Bot
force-pushed
the
changeset-release/next
branch
from
October 28, 2026 05:38
accb80e to
1a4e8ea
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to next, this PR will be updated.
nextis currently in pre mode so this branch has prereleases rather than normal releases. If you want to exit prereleases, runchangeset pre exitonnext.Releases
@solidjs/[email protected]
Patch Changes
@solidjs/webpeer, and the HMR note no longer describes itself as early work from version 1.1.0.frontendsoption: other languages that lower to Solid can claim a file extension and compile its modules themselves (frontends: { ".x": x() }). A front end'scompile(source, { id, moduleId, ssr, root, solid, addWatchFile })returns{ code, map, css }, given the compiler options this plugin would use for a JSX module in that environment; the result then takes the lowered.tsrxroute (lazy and refresh passes, server functions keyed by the module's real path,cssas a CSS module, dep scanning). Server functions in a front end's modules need@solidjs/compilerwith secondary passes that accept any extension..rx(ReactiveScript) is built in: with@reactivescript/compilerinstalled in the project,.rxmodules compile with no option.lazy()module-URL transform on non-JSX modules that mentionsolid-js. Any.jsfile containing the text "lazy" was parsed as an ES module, so a CommonJS dependency with a top-levelreturn(or Flow syntax) failedvite build. The compiler only rewriteslazyimported fromsolid-js, so other files are left untouched.devoption contract (left unset it means development builds undervite devonly,truealso forces them invite build), add a README section fordiagnostics, and remove the README entry foroptions.typescript, which the plugin does not accept.refresh: falsenow disables HMR, replacingrefresh: { disabled: true }, and the deprecatedhotoption is removed.refreshtakestrue,falseor{ granular }. The old spellings fail at config time with a message naming the replacement.start.errorBoundarytostart.productionErrorBoundary, since the boundary is only added in production builds. The old key fails at config time with a message naming the replacement.signaltorenderToStream, so a render still pending when the client disconnects is disposed ([3.0.0-next.51 / next] SSR: pending render survives client disconnect in Vite dev #467).//as the request path. The Node-to-web bridge resolvedreq.urlagainst the host as a relative URL, soGET //evil.example/api/xproduced arequest.urlofhttp://evil.example/api/x, letting a client choose the origin seen by origin checks and absolute redirects. The node entry's static file lookup and the dev and preview middlewares parse the path the same way now.serverFunctions()now takes only its options. The second parameter it used to declare was internal wiring for the main plugin'sserverFunctionsoption (dev middleware, SSR handler, TSRX ordering), which the standalone export should never set; it moved to an internal factory, so it is no longer part of the public types.^2.0.0-rc.19(solid-js,@solidjs/web,@solidjs/compiler,@solidjs/babel-plugin).start.entries:start.entryServerbecomesstart.entries.serverandstart.entryClientbecomesstart.entries.client. The old keys fail at config time with a message naming the replacement.start.externaltostart.externalServer, so it no longer reads like Vite'sssr.external(dependency externalization): the option hands the whole server side to a host. The old key fails at config time with a message naming the replacement.startto a top-levelcssoption:start.css.filterbecomescss.filter. Plainssr: truesetups readingvirtual:solid-manifestalready ran the crawl but had no way to configure it.start.cssfails at config time with a message naming the replacement.startto a top-levelenvoption, since it also works without start mode. An explicitenv(trueor a schema path) now works in any setup, for example a manualssr: trueserver. Left unset, only start mode probes for the conventionalenv.ts/env.js, so projects withoutstartthat happen to have an unrelatedenv.tsare unaffected.start.envfails at config time with a message naming the replacement.virtual:solid-manifestas what it exports:ViteManifestin an SSR build, the liveDevAssetResolverin dev (now exported from the plugin). Both still pass straight intorenderToStream'smanifestoption; code that reads the module narrows withif (manifest.resolve). Code that treated the dev export as aViteManifestnow gets a type error where it used to fail at runtime.