Extensions and helpers

A bun project does not live on lang=d alone. It imports a Svelte grid from node_modules, it has a jquery-bridge.ts, it has app.scss, it has a public/ logo. svelte-d’s answer is ingest, not a second runtime. Imported .svelte files are copied onto src-svelte/ext/<pkg>/ and printed with the same printer as src/lib. Local TypeScript helpers land in src-ts/modules/helpers/. SCSS and CSS land in styles/. public/ is copied to ws/public/ and served by vibe.0 serveStaticFiles("../public/") before the Vite reverse proxy, with failIfNotFound off so a missing file still falls through to HMR.

What is not ingested is “everything in package.json.” Dumping dependencies into the engine’s package.json was considered and rejected. Only files the app actually imports (or a declared extension list, if you add one later) are copied. A React or Vue widget has no .svelte to print; it is Host-JS-only and stays in src-ts. Inventing D IR for it would be a third stack.

lang=ts npm imports are a narrower fall-through than that dump. The dest package.json gets the project’s declared range for each specifier the TS body actually wrote. Dest node_modules/<pkg> gets a copy of the project’s install when it exists, then compile runs bun install in the dest if the package is still missing. $lib/foo rewrites to src-ts/modules/helpers/lib/foo. That is how admin-mini and fake-grid reach Vite in svelte-engine-ws without a file: path between two node_modules.

D that must call a lang=ts export uses the simple name (callTs). D that must call a window host object uses Eval("window.$"), the same way pglite.d reaches PgLite. It does not grow an FFI. See cross-calling.