@solidjs/vite-plugin 3.0.0-next.32 → 3.0.0-next.33

package/README.md

@@ -654,6 +654,19 @@ production handler alike), and edits to the module hot-invalidate the
 handler in dev. Config calls merge per key, so it composes with the
 plugin's own runtime configuration.
 
+Server-function requests are same-origin protected by `@solidjs/web`. To
+allow another trusted origin, configure it in the same server-only module:
+
+```ts
+import { configureServerFunctionsServer } from '@solidjs/web/server-functions/server';
+
+configureServerFunctionsServer({
+  csrf: { origin: ['https://app.example.com'] },
+});
+```
+
+Set `csrf: false` only when another trusted layer protects the endpoint.
+
 Meta-frameworks that need to control plugin ordering and dispatch requests
 through their own server should use the standalone `serverFunctions()`
 export instead, which never installs the dev middleware. See

package/dist/cjs/index.cjs

@@ -2933,12 +2933,22 @@ function getSolidOptions(options, isSsr, dev, isTestMode = false) {
       hydratable: false
     };
   }
+
+  // Server components (serverFunctions.components) turn on the SSR-side
+  // behavior-claims transform: ref/on* positions on intrinsic elements
+  // compile to guarded `_bnd` claim holes instead of dropping. SSR-only
+  // by construction (the dom generate ignores the flag), and apps without
+  // the flag compile byte-for-byte as before.
+  const serverComponents = typeof options.serverFunctions === 'object' && !!options.serverFunctions.components;
   return {
     moduleName: '@solidjs/web',
     builtIns: SOLID_BUILT_INS,
     contextToCustomElements: true,
     wrapConditionals: true,
     ...solidOptions,
+    ...(serverComponents && solidOptions.generate === 'ssr' ? {
+      serverComponents: true
+    } : {}),
     dev,
     ...(options.solid || {})
   };