@zerotal/devtools 1.4.0 → 1.5.1

package/CHANGELOG.md

@@ -4,10 +4,40 @@ All notable changes to this package are documented here. The format is
 based on [Keep a Changelog](https://keepachangelog.com/); this package
 follows the Zerotal monorepo's unified versioning.
 
-**Maturity: `experimental`**
+**Maturity: `stable`**
 
 ## [Unreleased]
 
+## [1.5.1] — 2026-08-15
+
+### Fixed
+
+- **DevTools never activated.** The panel was missing from every app, in every mode,
+  however the environment was configured.
+
+  `DevtoolsProvider` gated itself on `isDevSurfaceAllowed(Bun.env["APP_ENV"])`, which fails
+  twice over. `APP_ENV` holds the _runtime mode_ by the time a provider boots — `setAppEnv()`
+  replaced it — so the check was asking whether `"web"` is a development environment. And it
+  was the one dev gate that did not honour `ZT_DEV`, the flag the dev orchestrator sets on
+  the server it supervises, so `zt dev` did not rescue it either.
+
+  It asks `devSurfacesEnabled()` now, which reads the preserved deployment name and honours
+  `ZT_DEV`. Still fails closed: an unset, `staging` or `production` deployment does not get
+  the unauthenticated trace inspector.
+
+## [1.5.0] — 2026-08-15
+
+### Changed
+
+- **Maturity is now `stable`.** The public API is covered by the SemVer promise from
+  here: anything importable without an `@internal` marker keeps its shape for the rest
+  of the 1.x line, and `api-surface.md` is diffed by CI on every change. The package
+  earned it by being small and self-contained — 32 exported symbols, a single dependency
+  on `@zerotal/core`, no breaking change since its first release, and the one internal
+  seam (`_setTraceStore`) correctly marked. The in-page panel extension API
+  (`window.__zerotalDevtools`, used by Flow to contribute its Timeline tab) is part of
+  that promise.
+
 ## [1.0.3] — 2026-08-07
 
 ### Changed

package/package.json

@@ -1,8 +1,8 @@
 {
   "name": "@zerotal/devtools",
-  "version": "1.4.0",
+  "version": "1.5.1",
   "license": "MIT",
-  "maturity": "experimental",
+  "maturity": "stable",
   "private": false,
   "type": "module",
   "main": "./src/index.ts",
@@ -30,11 +30,11 @@
     "typecheck": "tsc --noEmit"
   },
   "dependencies": {
-    "@zerotal/core": "1.4.0"
+    "@zerotal/core": "1.5.1"
   },
   "devDependencies": {
     "typescript": "^5.8.0",
-    "@zerotal/orm": "1.4.0"
+    "@zerotal/orm": "1.5.1"
   },
   "description": "In-browser developer tools for Zerotal — request traces, an inspector panel, and an extensible tab registry.",
   "keywords": [

package/src/provider/DevtoolsProvider.ts

@@ -1,6 +1,6 @@
 import {
   ServiceProvider,
-  isDevSurfaceAllowed,
+  devSurfacesEnabled,
   type AppEnvironment,
   type HttpContext,
 } from "@zerotal/core";
@@ -71,10 +71,16 @@ export class DevtoolsProvider extends ServiceProvider {
   private _stopStream: (() => void) | null = null;
 
   override async onBooting(): Promise<void> {
-    const env = Bun.env["APP_ENV"] ?? "";
-    // Fail closed: only activate for explicitly non-prod envs. An unset or
-    // `staging` APP_ENV must NOT expose the unauthenticated trace inspector.
-    if (!isDevSurfaceAllowed(env)) return;
+    // Fail closed: only activate for explicitly non-prod environments. An unset or
+    // `staging` deployment must NOT expose the unauthenticated trace inspector.
+    //
+    // `devSurfacesEnabled()` rather than reading `APP_ENV` here, for two reasons, and
+    // together they meant devtools never activated at all:
+    //   - by the time a provider boots, `setAppEnv()` has replaced `APP_ENV` with the
+    //     runtime mode, so this was asking whether `"web"` is a development environment;
+    //   - it is the only dev gate that did not honour `ZT_DEV`, which is what the dev
+    //     orchestrator sets on the server it supervises — so `zt dev` did not help either.
+    if (!devSurfacesEnabled()) return;
     this._active = true;
 
     const config = this._config();