@bamboocss/vite 1.38.0 → 1.39.0

package/dist/index.cjs

@@ -24,6 +24,7 @@ var __toESM = (mod, isNodeMode, target) => (target = mod != null ? __create(__ge
 	enumerable: true
 }) : target, mod));
 //#endregion
+let _bamboocss_config = require("@bamboocss/config");
 let _bamboocss_node = require("@bamboocss/node");
 let _bamboocss_logger = require("@bamboocss/logger");
 let _bamboocss_shared = require("@bamboocss/shared");
@@ -426,6 +427,39 @@ const bamboocssCss = (options) => {
 		configResolved(config) {
 			command = config.command;
 			session.sourcemap = config.build.sourcemap;
+			/**
+			* Tell Vite that `bamboo.config.ts` is a config file, so editing one restarts the server.
+			*
+			* Tokens live there, and they are what a designer iterates on most — "restart the dev
+			* server to see a colour change" is the wrong instruction for the file most likely to be
+			* edited all afternoon. Nothing watched it: `watch` is the CLI's own watcher, and a
+			* project running `vite dev` never reaches it.
+			*
+			* A restart rather than re-emitting the stylesheet, because this plugin and the compiler
+			* hold *separate* contexts and only this one reloads its config. A token *value* edit
+			* came out right on the next source change, and an edit that changes what compiles —
+			* adding a token, a condition, a utility — left the compiler naming classes from the old
+			* config against a sheet emitted from the new one. Half-updated is worse than stale.
+			*
+			* Through Vite's own list rather than a watcher of ours. Vite adds these paths to the
+			* files it watches, which is what reaches a config *outside* `root` — a monorepo with one
+			* config above `apps/web`, or a preset resolved into `node_modules`, neither of which the
+			* project watcher covers. It also means the restart is Vite's, with its own concurrency
+			* guard and its own error reporting, rather than a second implementation of both.
+			*
+			* The config's own import graph is resolved the way `Builder` resolves it, minus the
+			* tsconfig paths it has not loaded yet at this point. `dependencies` globs are not
+			* expanded here: they are declared as an escape hatch for a *config reload*, and turning
+			* every file matching one into a full server restart is not what a project asking for
+			* that meant.
+			*/
+			if (config.command === "serve") try {
+				const { deps } = (0, _bamboocss_config.getConfigDependencies)((0, _bamboocss_config.findConfig)({
+					cwd: cwd ?? config.root,
+					file: configPath
+				}));
+				config.configFileDependencies.push(...deps);
+			} catch {}
 			if (config.builder && config.environments) session.expectedEnvironments = new Set(Object.keys(config.environments));
 		},
 		/**
@@ -3033,6 +3067,18 @@ const isGeneratedOutput = (filePath, ctx) => {
 };
 /** 1-indexed line of a source offset, for an error a user can navigate to. */
 const lineAt = (code, offset) => code.slice(0, offset).split("\n").length;
+/**
+* One spelling for a path used as a map key against paths from somewhere else.
+*
+* The fold reports dependencies as ts-morph sees them and Vite reports a changed file as its
+* watcher saw it. On Windows those differ by separator, and can differ by the case of the
+* drive letter alone — chokidar reports what the OS handed it, `path.resolve` preserves
+* whatever the cwd had. Either would make every lookup below miss and restore the exact
+* staleness they exist to fix, silently, since a miss is indistinguishable from a module that
+* folded nothing. Only the drive letter is case-folded: the rest of the path is compared as
+* written, because elsewhere the filesystem may well be case-sensitive.
+*/
+const normalizeFsPath = (file) => (0, node_path.resolve)(file).replaceAll("\\", "/").replace(/^[a-z]:\//, (drive) => drive.toUpperCase());
 const formatSkipped = (id, skipped) => {
 	const counts = /* @__PURE__ */ new Map();
 	for (const entry of skipped) counts.set(entry.reason, (counts.get(entry.reason) ?? 0) + 1);
@@ -3053,6 +3099,7 @@ const formatSkipped = (id, skipped) => {
 */
 const bamboocss = (options = {}) => {
 	const { configPath, cwd, reportSkipped = false, reportSummary = true, maxRecipeStates, pruneCss = true } = options;
+	(0, _bamboocss_node.markStaticCompilerActive)();
 	if (maxRecipeStates !== void 0 && (!Number.isSafeInteger(maxRecipeStates) || maxRecipeStates < 1)) throw new Error("bamboocss: `maxRecipeStates` must be a positive safe integer.");
 	if ("renameCssAsset" in options) throw new Error("bamboocss: `renameCssAsset` has been replaced by `pruneCss`. Use `pruneCss: false` for what `renameCssAsset: false` did — it always disabled the pruning as well, since pruned bytes under the unpruned sheet's name is what lets a CDN serve a stale stylesheet. The new name says which of the two it is really about.");
 	/**
@@ -3114,6 +3161,84 @@ const bamboocss = (options = {}) => {
 	* would otherwise re-parse its module fifty times, which is the transform path.
 	*/
 	const recipeConfigCache = /* @__PURE__ */ new Map();
+	/**
+	* Which modules folded a value read out of which other module, for dev invalidation.
+	*
+	* `addWatchFile` reports the same edges, and in a build that is enough — Rollup discards a
+	* module whose watched file changed. Vite's dev server does not: a module that *statically
+	* imports* the changed one is only **soft**-invalidated, which by design keeps its cached
+	* transform result and rewrites nothing but the timestamps on its import specifiers. That
+	* cached result is where the compiled class string lives, so the edit never reaches it.
+	*
+	* The recipe case is the one users meet, because it is the one where the class is compiled
+	* into somebody else's module: an inline `cva` declaration is erased, and each *call site*
+	* becomes a literal in the module that calls it. Editing the recipe then updates the class
+	* in a module Vite has decided not to re-transform, so the browser and the SSR render keep
+	* the old class — with no error, and with Vite and Bamboo both logging as if the edit landed.
+	* A restart applies it, which is what makes it read as "recipes do not hot-reload".
+	*
+	* `css(sharedObject)` across modules fails identically; it is rarer only because a consumer
+	* that folds *nothing but* recipe calls has its import erased, and an erased import is not a
+	* static one, so Vite hard-invalidates it and the bug hides. Import one more value from the
+	* same module — the shape any real `ui.ts` has — and the import survives, and so does the
+	* stale class.
+	*
+	* Keyed by dependency, since "what changed" is the question asked, and tracked in the other
+	* direction as well so a re-transform can retract edges the module no longer has.
+	*/
+	const dependentsByDependency = /* @__PURE__ */ new Map();
+	const dependenciesByFile = /* @__PURE__ */ new Map();
+	const recordFoldDependencies = (file, dependencies) => {
+		const next = new Set(dependencies.map(normalizeFsPath).filter((dependency) => dependency !== file));
+		const previous = dependenciesByFile.get(file);
+		for (const dependency of previous ?? []) {
+			if (next.has(dependency)) continue;
+			const dependents = dependentsByDependency.get(dependency);
+			if (!dependents?.delete(file)) continue;
+			if (!dependents.size) dependentsByDependency.delete(dependency);
+		}
+		if (!next.size) {
+			dependenciesByFile.delete(file);
+			return;
+		}
+		dependenciesByFile.set(file, next);
+		for (const dependency of next) {
+			const dependents = dependentsByDependency.get(dependency);
+			if (dependents) dependents.add(file);
+			else dependentsByDependency.set(dependency, new Set([file]));
+		}
+	};
+	/**
+	* Modules to re-transform because `file` changed, hard-invalidated on the way out.
+	*
+	* Both halves are load-bearing. Invalidating drops the stale compiled result, which is the
+	* defect itself; returning the modules is what makes Vite propagate an update for them, so
+	* the client applies one rather than waiting for whatever request happens next.
+	*
+	* Invalidating here rather than leaving it to `updateModules` also survives another plugin
+	* filtering the list afterwards — a framework's own `hotUpdate` decides what its route
+	* modules do, and the stale bytes have to go either way.
+	*
+	* A consumer Vite already reached costs nothing: `propagateUpdate` skips a module it has
+	* traversed, and every consumer of a *resolvable* dependency is one, since `addWatchFile`
+	* makes it an importer whether or not the import survived the fold. What is left is the
+	* consumer of a dependency with no module of its own, where Vite matched nothing and would
+	* have done nothing at all. That one can end in a page reload, which is the honest outcome:
+	* its compiled classes really did change, and a reload is what Vite does with any update
+	* nothing accepts.
+	*/
+	const foldDependentModules = (file, modules, graph) => {
+		const dependents = dependentsByDependency.get(normalizeFsPath(file));
+		if (!dependents?.size) return;
+		const added = [];
+		for (const dependent of dependents) for (const module of graph.getModulesByFile(dependent) ?? []) {
+			if (modules.includes(module) || added.includes(module)) continue;
+			graph.invalidateModule(module);
+			added.push(module);
+		}
+		if (!added.length) return;
+		return [...modules, ...added];
+	};
 	let ctx;
 	let runtimeCss;
 	let styleCompiler;
@@ -3149,6 +3274,8 @@ const bamboocss = (options = {}) => {
 				perFile.clear();
 				survivorsByFile.clear();
 				recipeConfigCache.clear();
+				dependentsByDependency.clear();
+				dependenciesByFile.clear();
 				resetStaticCompilationSession(staticSession);
 			}
 			staticSession.startedEnvironments.add(environment);
@@ -3186,10 +3313,40 @@ const bamboocss = (options = {}) => {
 			recipeConfigCache.clear();
 			if (change.event === "delete") {
 				ctx.project.removeSourceFile(filePath);
+				recordFoldDependencies(normalizeFsPath(filePath), []);
 				return;
 			}
 			ctx.project.reloadSourceFile(filePath);
 		},
+		/**
+		* Re-transform whatever folded a value out of the file that just changed.
+		*
+		* Dev only — `hotUpdate` does not run in a build, where Rollup's own invalidation already
+		* covers this — and additive: the modules Vite matched are returned alongside, so this
+		* decides nothing about them.
+		*
+		* `handleHotUpdate` below stands in on Vite 5, which has no `hotUpdate`. Not quite the
+		* same thing: Vite 5 calls that hook for an update and not for a file appearing or being
+		* deleted, so a recipe file *created* while the server runs leaves its consumers stale
+		* there. Vite 6 and up call `hotUpdate` for all three, and never call `handleHotUpdate`
+		* when a plugin has both — including its deprecation warning — so exactly one of the two
+		* runs on any supported version.
+		*
+		* `environment` optional-chained for the same reason `addWatchFile` is in `transform`:
+		* a harness driving the hook need not supply a full plugin context, and a `TypeError`
+		* here is swallowed into an HMR error payload that a middleware-mode server sends
+		* nowhere.
+		*/
+		hotUpdate({ file, modules }) {
+			const graph = this.environment?.moduleGraph;
+			if (!graph) return;
+			return foldDependentModules(file, modules, graph);
+		},
+		handleHotUpdate({ file, modules, server }) {
+			const legacy = server;
+			if (legacy.environments) return;
+			return foldDependentModules(file, modules, legacy.moduleGraph);
+		},
 		async transform(code, id) {
 			if (!shouldTransform(id)) return null;
 			try {
@@ -3257,6 +3414,7 @@ const bamboocss = (options = {}) => {
 			}
 			if (reportSkipped && result.skipped.length) _bamboocss_logger.logger.info("vite:transform", formatSkipped(filePath, result.skipped));
 			for (const dependency of result.dependencies) this.addWatchFile?.(dependency);
+			recordFoldDependencies(normalizeFsPath(filePath), result.dependencies);
 			const forFile = survivorsByFile.get(filePath);
 			if (command === "serve" && forFile?.length) throw createSurvivorError(forFile);
 			if (!result.folded.length) return null;

package/dist/index.mjs

@@ -1,4 +1,5 @@
-import { Builder, loadConfigAndCreateContext } from "@bamboocss/node";
+import { findConfig, getConfigDependencies } from "@bamboocss/config";
+import { Builder, loadConfigAndCreateContext, markStaticCompilerActive } from "@bamboocss/node";
 import { logger } from "@bamboocss/logger";
 import { compact, createCssUncached, createMergeCss, esc, memo, toHash, truncateList, viewTransitionClassName } from "@bamboocss/shared";
 import remapping from "@ampproject/remapping";
@@ -396,6 +397,39 @@ const bamboocssCss = (options) => {
 		configResolved(config) {
 			command = config.command;
 			session.sourcemap = config.build.sourcemap;
+			/**
+			* Tell Vite that `bamboo.config.ts` is a config file, so editing one restarts the server.
+			*
+			* Tokens live there, and they are what a designer iterates on most — "restart the dev
+			* server to see a colour change" is the wrong instruction for the file most likely to be
+			* edited all afternoon. Nothing watched it: `watch` is the CLI's own watcher, and a
+			* project running `vite dev` never reaches it.
+			*
+			* A restart rather than re-emitting the stylesheet, because this plugin and the compiler
+			* hold *separate* contexts and only this one reloads its config. A token *value* edit
+			* came out right on the next source change, and an edit that changes what compiles —
+			* adding a token, a condition, a utility — left the compiler naming classes from the old
+			* config against a sheet emitted from the new one. Half-updated is worse than stale.
+			*
+			* Through Vite's own list rather than a watcher of ours. Vite adds these paths to the
+			* files it watches, which is what reaches a config *outside* `root` — a monorepo with one
+			* config above `apps/web`, or a preset resolved into `node_modules`, neither of which the
+			* project watcher covers. It also means the restart is Vite's, with its own concurrency
+			* guard and its own error reporting, rather than a second implementation of both.
+			*
+			* The config's own import graph is resolved the way `Builder` resolves it, minus the
+			* tsconfig paths it has not loaded yet at this point. `dependencies` globs are not
+			* expanded here: they are declared as an escape hatch for a *config reload*, and turning
+			* every file matching one into a full server restart is not what a project asking for
+			* that meant.
+			*/
+			if (config.command === "serve") try {
+				const { deps } = getConfigDependencies(findConfig({
+					cwd: cwd ?? config.root,
+					file: configPath
+				}));
+				config.configFileDependencies.push(...deps);
+			} catch {}
 			if (config.builder && config.environments) session.expectedEnvironments = new Set(Object.keys(config.environments));
 		},
 		/**
@@ -3003,6 +3037,18 @@ const isGeneratedOutput = (filePath, ctx) => {
 };
 /** 1-indexed line of a source offset, for an error a user can navigate to. */
 const lineAt = (code, offset) => code.slice(0, offset).split("\n").length;
+/**
+* One spelling for a path used as a map key against paths from somewhere else.
+*
+* The fold reports dependencies as ts-morph sees them and Vite reports a changed file as its
+* watcher saw it. On Windows those differ by separator, and can differ by the case of the
+* drive letter alone — chokidar reports what the OS handed it, `path.resolve` preserves
+* whatever the cwd had. Either would make every lookup below miss and restore the exact
+* staleness they exist to fix, silently, since a miss is indistinguishable from a module that
+* folded nothing. Only the drive letter is case-folded: the rest of the path is compared as
+* written, because elsewhere the filesystem may well be case-sensitive.
+*/
+const normalizeFsPath = (file) => resolve(file).replaceAll("\\", "/").replace(/^[a-z]:\//, (drive) => drive.toUpperCase());
 const formatSkipped = (id, skipped) => {
 	const counts = /* @__PURE__ */ new Map();
 	for (const entry of skipped) counts.set(entry.reason, (counts.get(entry.reason) ?? 0) + 1);
@@ -3023,6 +3069,7 @@ const formatSkipped = (id, skipped) => {
 */
 const bamboocss = (options = {}) => {
 	const { configPath, cwd, reportSkipped = false, reportSummary = true, maxRecipeStates, pruneCss = true } = options;
+	markStaticCompilerActive();
 	if (maxRecipeStates !== void 0 && (!Number.isSafeInteger(maxRecipeStates) || maxRecipeStates < 1)) throw new Error("bamboocss: `maxRecipeStates` must be a positive safe integer.");
 	if ("renameCssAsset" in options) throw new Error("bamboocss: `renameCssAsset` has been replaced by `pruneCss`. Use `pruneCss: false` for what `renameCssAsset: false` did — it always disabled the pruning as well, since pruned bytes under the unpruned sheet's name is what lets a CDN serve a stale stylesheet. The new name says which of the two it is really about.");
 	/**
@@ -3084,6 +3131,84 @@ const bamboocss = (options = {}) => {
 	* would otherwise re-parse its module fifty times, which is the transform path.
 	*/
 	const recipeConfigCache = /* @__PURE__ */ new Map();
+	/**
+	* Which modules folded a value read out of which other module, for dev invalidation.
+	*
+	* `addWatchFile` reports the same edges, and in a build that is enough — Rollup discards a
+	* module whose watched file changed. Vite's dev server does not: a module that *statically
+	* imports* the changed one is only **soft**-invalidated, which by design keeps its cached
+	* transform result and rewrites nothing but the timestamps on its import specifiers. That
+	* cached result is where the compiled class string lives, so the edit never reaches it.
+	*
+	* The recipe case is the one users meet, because it is the one where the class is compiled
+	* into somebody else's module: an inline `cva` declaration is erased, and each *call site*
+	* becomes a literal in the module that calls it. Editing the recipe then updates the class
+	* in a module Vite has decided not to re-transform, so the browser and the SSR render keep
+	* the old class — with no error, and with Vite and Bamboo both logging as if the edit landed.
+	* A restart applies it, which is what makes it read as "recipes do not hot-reload".
+	*
+	* `css(sharedObject)` across modules fails identically; it is rarer only because a consumer
+	* that folds *nothing but* recipe calls has its import erased, and an erased import is not a
+	* static one, so Vite hard-invalidates it and the bug hides. Import one more value from the
+	* same module — the shape any real `ui.ts` has — and the import survives, and so does the
+	* stale class.
+	*
+	* Keyed by dependency, since "what changed" is the question asked, and tracked in the other
+	* direction as well so a re-transform can retract edges the module no longer has.
+	*/
+	const dependentsByDependency = /* @__PURE__ */ new Map();
+	const dependenciesByFile = /* @__PURE__ */ new Map();
+	const recordFoldDependencies = (file, dependencies) => {
+		const next = new Set(dependencies.map(normalizeFsPath).filter((dependency) => dependency !== file));
+		const previous = dependenciesByFile.get(file);
+		for (const dependency of previous ?? []) {
+			if (next.has(dependency)) continue;
+			const dependents = dependentsByDependency.get(dependency);
+			if (!dependents?.delete(file)) continue;
+			if (!dependents.size) dependentsByDependency.delete(dependency);
+		}
+		if (!next.size) {
+			dependenciesByFile.delete(file);
+			return;
+		}
+		dependenciesByFile.set(file, next);
+		for (const dependency of next) {
+			const dependents = dependentsByDependency.get(dependency);
+			if (dependents) dependents.add(file);
+			else dependentsByDependency.set(dependency, new Set([file]));
+		}
+	};
+	/**
+	* Modules to re-transform because `file` changed, hard-invalidated on the way out.
+	*
+	* Both halves are load-bearing. Invalidating drops the stale compiled result, which is the
+	* defect itself; returning the modules is what makes Vite propagate an update for them, so
+	* the client applies one rather than waiting for whatever request happens next.
+	*
+	* Invalidating here rather than leaving it to `updateModules` also survives another plugin
+	* filtering the list afterwards — a framework's own `hotUpdate` decides what its route
+	* modules do, and the stale bytes have to go either way.
+	*
+	* A consumer Vite already reached costs nothing: `propagateUpdate` skips a module it has
+	* traversed, and every consumer of a *resolvable* dependency is one, since `addWatchFile`
+	* makes it an importer whether or not the import survived the fold. What is left is the
+	* consumer of a dependency with no module of its own, where Vite matched nothing and would
+	* have done nothing at all. That one can end in a page reload, which is the honest outcome:
+	* its compiled classes really did change, and a reload is what Vite does with any update
+	* nothing accepts.
+	*/
+	const foldDependentModules = (file, modules, graph) => {
+		const dependents = dependentsByDependency.get(normalizeFsPath(file));
+		if (!dependents?.size) return;
+		const added = [];
+		for (const dependent of dependents) for (const module of graph.getModulesByFile(dependent) ?? []) {
+			if (modules.includes(module) || added.includes(module)) continue;
+			graph.invalidateModule(module);
+			added.push(module);
+		}
+		if (!added.length) return;
+		return [...modules, ...added];
+	};
 	let ctx;
 	let runtimeCss;
 	let styleCompiler;
@@ -3119,6 +3244,8 @@ const bamboocss = (options = {}) => {
 				perFile.clear();
 				survivorsByFile.clear();
 				recipeConfigCache.clear();
+				dependentsByDependency.clear();
+				dependenciesByFile.clear();
 				resetStaticCompilationSession(staticSession);
 			}
 			staticSession.startedEnvironments.add(environment);
@@ -3156,10 +3283,40 @@ const bamboocss = (options = {}) => {
 			recipeConfigCache.clear();
 			if (change.event === "delete") {
 				ctx.project.removeSourceFile(filePath);
+				recordFoldDependencies(normalizeFsPath(filePath), []);
 				return;
 			}
 			ctx.project.reloadSourceFile(filePath);
 		},
+		/**
+		* Re-transform whatever folded a value out of the file that just changed.
+		*
+		* Dev only — `hotUpdate` does not run in a build, where Rollup's own invalidation already
+		* covers this — and additive: the modules Vite matched are returned alongside, so this
+		* decides nothing about them.
+		*
+		* `handleHotUpdate` below stands in on Vite 5, which has no `hotUpdate`. Not quite the
+		* same thing: Vite 5 calls that hook for an update and not for a file appearing or being
+		* deleted, so a recipe file *created* while the server runs leaves its consumers stale
+		* there. Vite 6 and up call `hotUpdate` for all three, and never call `handleHotUpdate`
+		* when a plugin has both — including its deprecation warning — so exactly one of the two
+		* runs on any supported version.
+		*
+		* `environment` optional-chained for the same reason `addWatchFile` is in `transform`:
+		* a harness driving the hook need not supply a full plugin context, and a `TypeError`
+		* here is swallowed into an HMR error payload that a middleware-mode server sends
+		* nowhere.
+		*/
+		hotUpdate({ file, modules }) {
+			const graph = this.environment?.moduleGraph;
+			if (!graph) return;
+			return foldDependentModules(file, modules, graph);
+		},
+		handleHotUpdate({ file, modules, server }) {
+			const legacy = server;
+			if (legacy.environments) return;
+			return foldDependentModules(file, modules, legacy.moduleGraph);
+		},
 		async transform(code, id) {
 			if (!shouldTransform(id)) return null;
 			try {
@@ -3227,6 +3384,7 @@ const bamboocss = (options = {}) => {
 			}
 			if (reportSkipped && result.skipped.length) logger.info("vite:transform", formatSkipped(filePath, result.skipped));
 			for (const dependency of result.dependencies) this.addWatchFile?.(dependency);
+			recordFoldDependencies(normalizeFsPath(filePath), result.dependencies);
 			const forFile = survivorsByFile.get(filePath);
 			if (command === "serve" && forFile?.length) throw createSurvivorError(forFile);
 			if (!result.folded.length) return null;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bamboocss/vite",
-  "version": "1.38.0",
+  "version": "1.39.0",
   "description": "Vite integration for Bamboo CSS",
   "homepage": "https://bamboocss.com",
   "license": "MIT",
@@ -40,18 +40,18 @@
     "postcss": "8.5.26",
     "postcss-selector-parser": "7.1.5",
     "ts-morph": "28.0.0",
-    "@bamboocss/config": "1.38.0",
-    "@bamboocss/core": "1.38.0",
-    "@bamboocss/logger": "1.38.0",
-    "@bamboocss/node": "1.38.0",
-    "@bamboocss/extractor": "1.38.0",
-    "@bamboocss/shared": "1.38.0",
-    "@bamboocss/types": "1.38.0"
+    "@bamboocss/core": "1.39.0",
+    "@bamboocss/extractor": "1.39.0",
+    "@bamboocss/config": "1.39.0",
+    "@bamboocss/logger": "1.39.0",
+    "@bamboocss/node": "1.39.0",
+    "@bamboocss/shared": "1.39.0",
+    "@bamboocss/types": "1.39.0"
   },
   "devDependencies": {
     "@jridgewell/trace-mapping": "^0.3.31",
     "vite": "7.2.6",
-    "@bamboocss/fixture": "1.38.0"
+    "@bamboocss/fixture": "1.39.0"
   },
   "peerDependencies": {
     "vite": ">=5"