@bakery-framework/core 1.2.1 → 1.2.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bakery-framework/core",
-  "version": "1.2.1",
+  "version": "1.2.3",
   "description": "Bakery framework core: handlers, router, config, session, caches, logger, compiler.",
   "keywords": [
     "bakery",

package/src/compiler/tsconfig-sync.ts

@@ -1,3 +1,4 @@
+import { readFileSync } from 'node:fs'
 import { Bakery } from '../core/bakery'
 import { errorMsg, serveLog } from '../logger'
 import type { PluginTsProject } from '../plugins/types'
@@ -69,6 +70,7 @@ export function coreProjects(): PluginTsProject[] {
   return [
     {
       name: 'server',
+      server: true,
       extends: '@bakery-framework/core/tsconfig.server.json',
       // Repeated rather than inherited: Bun's runtime does not follow
       // `extends` into a package specifier, only a relative path.
@@ -138,6 +140,77 @@ function resolveFilesEntry(entry: string): string | null {
   }
 }
 
+/**
+ * The `files` the extended base config declares, resolved for the generated one.
+ *
+ * **TypeScript's rule is that a child's `files` *replaces* the parent's, and
+ * that rule silently disarmed every project a plugin contributes.**
+ * `tsconfig.vue.json` lists core's three ambient declarations — `global.d.ts`,
+ * `shared.d.ts`, `types.d.ts` — which is where `Bakery`, `AppConfig`, the JSX
+ * namespace and `Request.session` come from. `@bakery-framework/plugin-vue`
+ * declares one `files` entry of its own for `vue.d.ts`, and that one entry
+ * replaced all three: measured on a real app, the generated `vue` project loaded
+ * **zero** of them.
+ *
+ * It hid because `vue.d.ts` happens to declare `req` and `body` itself, so the
+ * globals an SFC reaches for most still resolved. Everything else — `Bakery`,
+ * `MapOf`, the JSX namespace — was quietly missing.
+ *
+ * So the base's list is read and merged rather than inherited. Paths inside it
+ * are relative to *that* file, which is the property the whole arrangement rests
+ * on and the reason they cannot simply be copied across.
+ */
+function readBase(extendsSpecifier: string): string[] {
+  try {
+    const base = Bun.resolveSync(extendsSpecifier, APP_DIR)
+    const parsed = parseJSONC(readFileSync(base, 'utf8'))
+    const list: string[] = Array.isArray(parsed?.files) ? parsed.files : []
+    const baseDir = fs.dirname(base)
+
+    return list.map(entry => {
+      const abs = fs.resolve(baseDir, entry)
+      const rel = fs.relative(PROJECT_DIR, abs).replace(/\\/g, '/')
+      return RE_RELATIVE.test(rel) ? rel : `./${rel}`
+    })
+  } catch {
+    // A base that cannot be read is not fatal: the project still compiles, it
+    // just loses the ambients — which is the status quo this repairs, not a
+    // regression. Assume client-side, which is the conservative half.
+    return []
+  }
+}
+
+/**
+ * The app file carrying `declare module '@bakery-framework/orm/schema-registry'`.
+ *
+ * Declaration merging only happens if the declaring file is in the program, and
+ * it reached exactly one project: `server`, because that is the only one whose
+ * `include` covers `orm/**`. Everywhere else `SchemaRegistry` stayed empty,
+ * `Registered` resolved to `never`, and every table fell back to
+ * `MapOf<MapOf<any>>` — the ORM's documented untyped mode, arrived at by
+ * accident. It does not error; it just stops checking.
+ *
+ * **Server-side projects only.** The client project deliberately does not get
+ * it: the ORM is server-only, so a browser file importing `DB` should fail to
+ * typecheck rather than be helpfully typed. That is not only a preference —
+ * `@bakery-framework/orm` ships TypeScript source that calls `Bun.*`, so pulling
+ * it into a config without `bun-types` produces errors from inside the package
+ * rather than types for the app. Measured when this was applied to every
+ * project: 187 new errors in `client`.
+ */
+function schemaRegistrationFile(): string | null {
+  const configured = Bakery.config.schema
+  const candidates = configured
+    ? [configured, `${configured}/index.ts`]
+    : ['orm/index.ts', 'schema.ts']
+
+  for (const rel of candidates) {
+    const abs = fs.resolve(APP_DIR, rel)
+    if (fs.isFileSync(abs)) return abs
+  }
+  return null
+}
+
 /** Every project: core's two, plus whatever the loaded plugins contribute. */
 function allProjects(): PluginTsProject[] {
   const projects = coreProjects()
@@ -174,9 +247,16 @@ function allProjects(): PluginTsProject[] {
  */
 export async function writeProjects(paths: MapOf<string[]>): Promise<string[]> {
   const written: string[] = []
+  const found = schemaRegistrationFile()
+  const registrationFile = found
+    ? (() => {
+        const rel = fs.relative(PROJECT_DIR, found).replace(/\\/g, '/')
+        return RE_RELATIVE.test(rel) ? rel : `./${rel}`
+      })()
+    : null
 
   for (const project of allProjects()) {
-    const files = (project.files ?? [])
+    const own = (project.files ?? [])
       .map(entry => {
         const resolved = resolveFilesEntry(entry)
         if (!resolved) {
@@ -186,6 +266,24 @@ export async function writeProjects(paths: MapOf<string[]>): Promise<string[]> {
       })
       .filter((f): f is string => f !== null)
 
+    const baseFiles = readBase(project.extends)
+
+    // The schema registration goes to every server-side project, so an SFC's
+    // `<script>` gets the app's real tables rather than the `any` fallback. The
+    // server project already reaches it through `include: ['orm/**']`; adding it
+    // to `files` there is a harmless duplicate and keeps the rule in one place.
+    const registration =
+      project.server && registrationFile ? [registrationFile] : []
+
+    // The base's own `files` are merged back in whenever this project declares
+    // any of its own, because a child's `files` *replaces* the parent's — see
+    // `readBase`. Left entirely empty, TypeScript inherits correctly and there
+    // is nothing to repair.
+    const declared = [...own, ...registration]
+    const files = declared.length
+      ? [...new Set([...baseFiles, ...declared])]
+      : []
+
     const config: Record<string, unknown> = {
       $comment:
         'GENERATED by Bakery on dev boot. Edits are lost; change the plugin or server.config.ts instead.',

package/src/core/cache-version.ts

@@ -100,12 +100,37 @@ async function run(): Promise<void> {
  */
 export const __wipeCacheDir = wipe
 
+/**
+ * The one thing in `.cache/` the wipe must not take.
+ *
+ * **The app's committed `tsconfig.json` *references* `.cache/tsconfig/*.json`,
+ * so deleting them breaks the editor for the whole project** — not one setting,
+ * everything. TypeScript reports `TS6053: File '…/server.json' not found` for
+ * each reference, has no project left to put a file in, and falls back to an
+ * inferred one with no ambients: `req.session`, `Bakery`, the JSX namespace and
+ * the app's own schema types all stop resolving at once.
+ *
+ * That happens on every framework upgrade, because the version wipe is keyed on
+ * the framework version among others. The developer sees their editor lose every
+ * type the moment they bump a patch, and nothing says why — the files come back
+ * only on the next `bun run dev`, which is not an obvious remedy for "my types
+ * vanished".
+ *
+ * Keeping them is safe in the direction that matters. A stale project is
+ * regenerated on the next dev boot and is, in the meantime, *approximately
+ * right* — while a missing one is catastrophically wrong. Nothing is executed
+ * from these files either: they configure a typechecker, so the "never read a
+ * cache an older framework wrote" rule the wipe exists to enforce does not apply.
+ */
+const WIPE_KEEP = new Set(['tsconfig'])
+
 async function wipe(dir: string): Promise<string[]> {
   if (!fs.exists(dir)) return []
   const [readErr, entries] = await Try.catch(() => readdir(dir))
   if (readErr || !entries) return ['<unreadable>']
 
   for (const entry of entries) {
+    if (WIPE_KEEP.has(entry)) continue
     // Errors are deliberately not swallowed *silently* here — each failure is
     // collected and reported by the caller.
     await Try.catch(() =>
@@ -115,5 +140,7 @@ async function wipe(dir: string): Promise<string[]> {
 
   const [rereadErr, left] = await Try.catch(() => readdir(dir))
   if (rereadErr) return ['<unreadable>']
-  return left ?? []
+  // Kept entries are not survivors of a failed delete, and reporting them as
+  // such would make the caller withhold the "cache is current" marker forever.
+  return (left ?? []).filter(entry => !WIPE_KEEP.has(entry))
 }

package/src/plugins/types.ts

@@ -43,6 +43,22 @@ export interface PluginTsProject {
    * A plugin whose project compiles browser code should set it.
    */
   importMapPaths?: boolean
+  /**
+   * Does code in this project run on the server?
+   *
+   * Declared, not inferred. The first version read `bun-types` out of the base
+   * config and treated that as the marker — true today, and an inference about
+   * intent drawn from a detail that exists for another reason. A plugin saying
+   * what its project *is* cannot drift out of step with itself.
+   *
+   * What it controls: the app's schema registration, so the ORM's tables are the
+   * app's own rather than the permissive `any` fallback. Off for browser code on
+   * purpose — `@bakery-framework/orm` is server-only, so a `.ts` bound for the
+   * browser importing `DB` should fail to typecheck rather than be helpfully
+   * typed, and the package ships TypeScript source calling `Bun.*`, which a
+   * client config cannot compile anyway.
+   */
+  server?: boolean
 }
 
 /** What a plugin contributes to the generated tsconfig projects. */