@clearcms/admin@0.4.1

Patch Changes

• #84 2d6eb06 Thanks @slavasolutions! - Add update-available reminders to clear-admin.

  Adopters now learn about new versions of @clearcms/admin via two
  complementary surfaces:

  Passive notifier — every clear-admin <command> invocation kicks off
  an async, non-blocking check against the npm registry. The result caches
  at ~/.cache/clear-admin/update-check.json (24h TTL). On the next
  invocation, if a newer version is published, a one-line banner prints to
  stderr at process exit:

    Update available  0.4.1 → 0.5.0
    Run `npm i -g @clearcms/admin` to upgrade. Set NO_UPDATE_NOTIFIER=1 to silence.
  

  The check never blocks, never errors, never delays output. Failures
  (offline, registry 5xx, timeout) are silent. Skipped when
  NO_UPDATE_NOTIFIER=1 or CI env vars are set.

  Doctor check — clear-admin doctor now includes an admin-update
  check that reports current vs latest @clearcms/admin. Reads the cache
  file when fresh (24h); otherwise does a synchronous registry fetch with
  a 1.5s timeout. WARN tier when behind, INFO when current or registry
  unreachable. Skipped in CI / test environments / with NO_UPDATE_NOTIFIER.

  No new dependencies. Hand-rolled — built-in fetch + Node fs only.

• #82 6de9035 Thanks @slavasolutions! - Fix Windows clear-admin start spawning astro with ENOENT (#81).

  apps/admin/bin/clear-admin.js's dev-mode path resolved
  node_modules/.bin/astro and called spawn() without shell: true. On
  Windows, pnpm/npm put shell wrappers at .bin/astro.cmd and .bin/astro.ps1,
  not a bare .bin/astro — Node's child_process.spawn cannot resolve the
  .cmd extension implicitly and threw ENOENT. POSIX silently handled it
  because the bare wrapper was directly executable.

  Now picks astro.cmd on process.platform === 'win32' and bare astro
  elsewhere. No shell, no quoting concerns. Adopters running pnpm dev
  on a Windows fresh clone of a @clearcms/create scaffold can boot the
  admin alongside the site.

• #83 cbdc2ce Thanks @slavasolutions! - Fix Windows SQLite teardown EBUSY in admin tests (#56).

  Test suites that exercised real libSQL (pages-reindex, schemas [key] API,
  preview [token] API) and the backup/restore CLI tests failed on Windows
  fresh clones with EBUSY: resource busy or locked, unlink ...\clear.db. Two
  compounding causes:

  1. The cached libSQL singleton in apps/admin/src/lib/db.ts is opened lazily
     when a route is imported. Tests closed their own setup-time client but
     never the route-side cached client, so the file handle persisted past
     afterAll.
  2. POSIX silently allows unlink-while-open. Windows doesn't, and the OS
     sometimes needs a brief retry window even after close() returns.

  This change adds:

  • A new closeDb() export from apps/admin/src/lib/db.ts that closes the
    cached client and clears the singleton. Tests call it in afterAll before
    removing tempdirs.
  • A new safeRm(path) test helper in apps/admin/src/test/teardown.ts that
    retries rm with backoff on EBUSY (5 retries, linear 50ms backoff).

  Wired into the affected suites: pages-reindex.test.ts, schemas/[key].test.ts,
  preview/[token].test.ts, backup.test.ts, restore.test.ts.

  Linux/macOS unaffected — safeRm falls through to a single rm call when
  no EBUSY occurs.