[Bug?]: devtools css is included in production #2327

Activity

1. huseeiin

   added

   bugSomething isn't workingSomething isn't working

   needs triage

   on Sep 24, 2026
2. lxsmnsyc

   self-assigned this

   on Sep 24, 2026
3. brenelz

   removed

   needs triage

   on Oct 13, 2026
4. lxsmnsyc

   closed this as completedin #2339on Oct 13, 2026
5. plethu commented on Oct 21, 2026

   

   plethu

   on Oct 21, 2026

   Last edited by plethu

   More actions

   Update: fixed in SolidStart 2.1.0. The linked app, rebuilt with its SolidStart pin updated to 2.1.0, emits no toolbar CSS without a local workaround. The report below describes 2.0.6.

   The production-toolbar CSS behavior from #2327
   still reproduces with the current npm version, @solidjs/start 2.0.6.

   Reproduction gist · Download ZIP. The app has a single Hello page and no application CSS imports. It uses Solid 1.9.17,
   Solid Router 1.0.0, Vite 8.3.4 and Nitro 3.0.260903-beta.

   Download and extract the ZIP, then run inside the extracted directory:

   bun install --frozen-lockfile
   bun run build

   Inspect .output/public/_build/assets/*.css: the build emits 16,856 bytes of CSS, with ten
   data-start-dev-toolbar selector matches. The expected result is no development-toolbar CSS in this
   production build.

   In a local paired build, conditionally lazy-loading the development toolbar in the shared
   ErrorBoundary removes that CSS. The reproduction uses the published unmodified SolidStart package;
   the workaround was applied only for the comparison.

   Verified on CachyOS x86_64 using Bun 1.4.3. This reproduction and follow-up were prepared with
   coding-agent assistance.

   Reproduction source (lockfile included in the ZIP)

   app.tsx

   import { Router } from '@solidjs/router';
   import { FileRoutes } from '@solidjs/start/router';
   import { Suspense } from 'solid-js';
   export default function App() {
     return (
       <Router root={(props) => <Suspense>{props.children}</Suspense>}>
         <FileRoutes />
       </Router>
     );
   }

   entry-client.tsx

   import { mount, StartClient } from '@solidjs/start/client';
   mount(() => <StartClient />, document.getElementById('app')!);

   entry-server.tsx

   import { createHandler, StartServer } from '@solidjs/start/server';
   export default createHandler(() => (
     <StartServer
       document={({ assets, children, scripts }) => (
         <html lang="en">
           <head>
             <meta charset="utf-8" />
             {assets}
           </head>
           <body>
             <div id="app">{children}</div>
             {scripts}
           </body>
         </html>
       )}
     />
   ));

   index.tsx

   export default function Home() {
     return <h1>Hello</h1>;
   }

   package.json

   {
     "name": "solidstart-production-toolbar-repro",
     "private": true,
     "type": "module",
     "scripts": {
       "build": "node setup.mjs && vite build"
     },
     "dependencies": {
       "@solidjs/router": "1.0.0",
       "@solidjs/start": "2.0.6",
       "nitro": "3.0.260903-beta",
       "solid-js": "1.9.17",
       "vite": "8.3.4"
     }
   }

   setup.mjs

   import { mkdir, copyFile } from 'node:fs/promises';
   
   await mkdir('src/routes', { recursive: true });
   for (const file of ['app.tsx', 'entry-client.tsx', 'entry-server.tsx']) {
     await copyFile(file, `src/${file}`);
   }
   await copyFile('index.tsx', 'src/routes/index.tsx');

   vite.config.ts

   import { defineConfig } from 'vite';
   import { solidStart } from '@solidjs/start/config';
   import { nitro } from 'nitro/vite';
   export default defineConfig({
     plugins: [solidStart(), nitro()],
     nitro: { preset: 'static', prerender: { routes: ['/'] } },
   });
6. lxsmnsyc commented on Oct 22, 2026

   

   lxsmnsyc

   on Oct 22, 2026

   Member

   More actions

   @plethu this is fixed but the fix hasn't been released yet. See: #2337
7. plethu commented on Oct 22, 2026

   

   plethu

   on Oct 22, 2026

   More actions

   Thanks, I missed the sideEffects change when checking main. That explains why the static toolbar import was misleading. We’ll keep the workaround on 2.0.6 and retest once #2337 is released.