@bamboocss/vite 1.39.1 → 1.40.1

package/dist/index.cjs

@@ -383,7 +383,6 @@ const bamboocssCss = (options) => {
 		builder.extract();
 		if (builder.context?.config.polyfill) throw new Error("bamboocss: the cascade-layer polyfill is incompatible with compiled atomic styles. The polyfill removes the utility-layer boundary required for safe atom reachability and renaming.");
 		if (builder.context) {
-			session.cssLoaded = true;
 			session.utilityLayer = builder.context.config.layers?.utilities ?? "utilities";
 			session.extractedFiles.clear();
 			for (const file of builder.context.getFiles()) session.extractedFiles.add(builder.context.runtime.path.abs(builder.context.config.cwd, file));
@@ -413,6 +412,31 @@ const bamboocssCss = (options) => {
 		pending = Promise.resolve(pending).catch(() => void 0).then(build);
 		return pending;
 	};
+	/**
+	* The pass that runs before Rollup resolves anything, and the sheet it produced.
+	*
+	* `emit` writes `styled-system/`, and reaching it through `load` is too late to be what a
+	* fresh clone needs: `load` runs when the *virtual module* is requested, and a module's
+	* imports are all resolved before any of them is loaded. So `app/root.tsx` importing both
+	* `styled-system/css` and `virtual:bamboo.css` has the first resolved while the directory is
+	* still absent — the client build carried on and externalised it, the ssr build failed with
+	* "Rolldown failed to resolve import", and `vite dev` served an error overlay. `buildStart` is
+	* the first hook Rollup calls, and it precedes all of that.
+	*
+	* Memoised, and consumed by the first `load` rather than regenerated for it. `buildStart` runs
+	* once per environment against this one shared instance, and nothing can have invalidated the
+	* result in between — the modules that would invalidate it have not been transformed yet.
+	* Regenerating would mean a second full extraction on every cold start, to produce the same
+	* bytes.
+	*/
+	let prebuilt;
+	let prebuildStarted = false;
+	const prebuild = async () => {
+		if (prebuildStarted) return;
+		prebuildStarted = true;
+		prebuilt = generate();
+		await prebuilt;
+	};
 	return {
 		name: "bamboocss:css",
 		/**
@@ -479,6 +503,20 @@ const bamboocssCss = (options) => {
 				session.expectedEnvironments = new Set(Object.keys(builder.environments));
 			}
 		},
+		/**
+		* Put `styled-system/` on disk before anything resolves an import of it.
+		*
+		* Normalized rather than rethrown as caught, for the reason the compiler's `buildStart`
+		* gives: this evaluates the user's config and its hooks, and in dev anything that is not an
+		* object crashes Vite's error middleware instead of being reported.
+		*/
+		async buildStart() {
+			try {
+				await prebuild();
+			} catch (error) {
+				throw asError(error, `failed to generate ${VIRTUAL_CSS_ID}`);
+			}
+		},
 		resolveId(id) {
 			const query = queryOf(id);
 			const base = id.slice(0, id.length - query.length);
@@ -489,9 +527,12 @@ const bamboocssCss = (options) => {
 			const query = queryOf(id);
 			if (id.slice(0, id.length - query.length) !== RESOLVED_ID) return null;
 			servedEnvironments.add(this.environment?.name ?? "default");
+			session.cssLoaded = true;
 			let css;
 			try {
-				css = await generate();
+				const first = prebuilt;
+				prebuilt = void 0;
+				css = await (first ?? generate());
 			} catch (error) {
 				throw asError(error, `failed to generate ${VIRTUAL_CSS_ID}`);
 			}
@@ -500,12 +541,28 @@ const bamboocssCss = (options) => {
 		},
 		configureServer(devServer) {
 			server = devServer;
+			/**
+			* The graph the stylesheet's own module lives in, which is the one that has to reach it.
+			*
+			* `load` registers every extracted file with `addWatchFile`, and `vite:css-analysis`
+			* turns those into real importer edges — the virtual module ends up a direct importer of
+			* each file the extractor read. So an edit to any of them propagates to the stylesheet on
+			* Vite's own pass, in whichever environment holds that edge.
+			*
+			* The client one, because CSS is a client concern: an ssr environment never applies a
+			* stylesheet update, and asking whether *any* environment matched would skip the forced
+			* reload below for a server-only module whose styles the client still has to be told
+			* about. Vite 5 has one graph and no `environments`, where the question is exact.
+			*/
+			const clientGraph = devServer.environments?.client?.moduleGraph ?? devServer.moduleGraph;
 			const invalidate = (file) => {
 				const ctx = builder.context;
 				if (!ctx) return;
 				if (!ctx.getFiles().some((f) => ctx.runtime.path.abs(ctx.config.cwd, f) === file)) return;
+				prebuilt = void 0;
 				const mod = server?.moduleGraph.getModuleById(RESOLVED_ID);
 				if (!mod) return;
+				if (clientGraph.getModulesByFile(file)?.size) return;
 				server?.moduleGraph.invalidateModule(mod);
 				server?.reloadModule(mod);
 				_bamboocss_logger.logger.debug("vite", `styles invalidated by ${file}`);
@@ -3236,21 +3293,33 @@ const bamboocss = (options = {}) => {
 	/**
 	* 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 is the fix. It drops the stale compiled result, which is the defect itself,
+	* and it has to happen here rather than being left to `updateModules`: Vite *soft*-
+	* invalidates an importer that statically imports the changed module, and a soft invalidation
+	* keeps the cached transform — the very place the compiled class string lives.
+	*
+	* Doing it here 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.
+	*
+	* *Naming* those modules back to Vite is a different question, and the answer is almost
+	* always no. `addWatchFile` makes every consumer a direct importer of the dependency in the
+	* module graph, so `propagateUpdate` walks to all of them from the changed file by itself and
+	* sends exactly the same update. Returning them as well does not merge into that pass: a
+	* framework plugin downstream reads the list and re-drives HMR per entry — react-router's
+	* `react-router-server-change-trigger-client-hmr` calls `reloadModule` once per module, in
+	* both its client and its ssr pass — and each of those is a separate `updateModules`, a
+	* separate `hmr update`, and a separate refetch of the whole module by the browser.
 	*
-	* 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.
+	* Measured on a five-route react-router app, one `css()` edit in a shared `ui.ts`: eight
+	* `hmr update` messages, `root.tsx` and `dashboard.tsx` fetched five times each, 554 kB over
+	* the socket for a one-line edit. Dropping the redundant half takes it to four messages and
+	* 367 kB with the same modules re-transformed and the same edit applied.
 	*
-	* 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.
+	* So the list is returned only when Vite has matched nothing for the file and would otherwise
+	* do nothing at all — a dependency the fold read that never became a module of its own. 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));
@@ -3262,6 +3331,7 @@ const bamboocss = (options = {}) => {
 			added.push(module);
 		}
 		if (!added.length) return;
+		if (modules.length) return;
 		return [...modules, ...added];
 	};
 	let ctx;

package/dist/index.mjs

@@ -353,7 +353,6 @@ const bamboocssCss = (options) => {
 		builder.extract();
 		if (builder.context?.config.polyfill) throw new Error("bamboocss: the cascade-layer polyfill is incompatible with compiled atomic styles. The polyfill removes the utility-layer boundary required for safe atom reachability and renaming.");
 		if (builder.context) {
-			session.cssLoaded = true;
 			session.utilityLayer = builder.context.config.layers?.utilities ?? "utilities";
 			session.extractedFiles.clear();
 			for (const file of builder.context.getFiles()) session.extractedFiles.add(builder.context.runtime.path.abs(builder.context.config.cwd, file));
@@ -383,6 +382,31 @@ const bamboocssCss = (options) => {
 		pending = Promise.resolve(pending).catch(() => void 0).then(build);
 		return pending;
 	};
+	/**
+	* The pass that runs before Rollup resolves anything, and the sheet it produced.
+	*
+	* `emit` writes `styled-system/`, and reaching it through `load` is too late to be what a
+	* fresh clone needs: `load` runs when the *virtual module* is requested, and a module's
+	* imports are all resolved before any of them is loaded. So `app/root.tsx` importing both
+	* `styled-system/css` and `virtual:bamboo.css` has the first resolved while the directory is
+	* still absent — the client build carried on and externalised it, the ssr build failed with
+	* "Rolldown failed to resolve import", and `vite dev` served an error overlay. `buildStart` is
+	* the first hook Rollup calls, and it precedes all of that.
+	*
+	* Memoised, and consumed by the first `load` rather than regenerated for it. `buildStart` runs
+	* once per environment against this one shared instance, and nothing can have invalidated the
+	* result in between — the modules that would invalidate it have not been transformed yet.
+	* Regenerating would mean a second full extraction on every cold start, to produce the same
+	* bytes.
+	*/
+	let prebuilt;
+	let prebuildStarted = false;
+	const prebuild = async () => {
+		if (prebuildStarted) return;
+		prebuildStarted = true;
+		prebuilt = generate();
+		await prebuilt;
+	};
 	return {
 		name: "bamboocss:css",
 		/**
@@ -449,6 +473,20 @@ const bamboocssCss = (options) => {
 				session.expectedEnvironments = new Set(Object.keys(builder.environments));
 			}
 		},
+		/**
+		* Put `styled-system/` on disk before anything resolves an import of it.
+		*
+		* Normalized rather than rethrown as caught, for the reason the compiler's `buildStart`
+		* gives: this evaluates the user's config and its hooks, and in dev anything that is not an
+		* object crashes Vite's error middleware instead of being reported.
+		*/
+		async buildStart() {
+			try {
+				await prebuild();
+			} catch (error) {
+				throw asError(error, `failed to generate ${VIRTUAL_CSS_ID}`);
+			}
+		},
 		resolveId(id) {
 			const query = queryOf(id);
 			const base = id.slice(0, id.length - query.length);
@@ -459,9 +497,12 @@ const bamboocssCss = (options) => {
 			const query = queryOf(id);
 			if (id.slice(0, id.length - query.length) !== RESOLVED_ID) return null;
 			servedEnvironments.add(this.environment?.name ?? "default");
+			session.cssLoaded = true;
 			let css;
 			try {
-				css = await generate();
+				const first = prebuilt;
+				prebuilt = void 0;
+				css = await (first ?? generate());
 			} catch (error) {
 				throw asError(error, `failed to generate ${VIRTUAL_CSS_ID}`);
 			}
@@ -470,12 +511,28 @@ const bamboocssCss = (options) => {
 		},
 		configureServer(devServer) {
 			server = devServer;
+			/**
+			* The graph the stylesheet's own module lives in, which is the one that has to reach it.
+			*
+			* `load` registers every extracted file with `addWatchFile`, and `vite:css-analysis`
+			* turns those into real importer edges — the virtual module ends up a direct importer of
+			* each file the extractor read. So an edit to any of them propagates to the stylesheet on
+			* Vite's own pass, in whichever environment holds that edge.
+			*
+			* The client one, because CSS is a client concern: an ssr environment never applies a
+			* stylesheet update, and asking whether *any* environment matched would skip the forced
+			* reload below for a server-only module whose styles the client still has to be told
+			* about. Vite 5 has one graph and no `environments`, where the question is exact.
+			*/
+			const clientGraph = devServer.environments?.client?.moduleGraph ?? devServer.moduleGraph;
 			const invalidate = (file) => {
 				const ctx = builder.context;
 				if (!ctx) return;
 				if (!ctx.getFiles().some((f) => ctx.runtime.path.abs(ctx.config.cwd, f) === file)) return;
+				prebuilt = void 0;
 				const mod = server?.moduleGraph.getModuleById(RESOLVED_ID);
 				if (!mod) return;
+				if (clientGraph.getModulesByFile(file)?.size) return;
 				server?.moduleGraph.invalidateModule(mod);
 				server?.reloadModule(mod);
 				logger.debug("vite", `styles invalidated by ${file}`);
@@ -3206,21 +3263,33 @@ const bamboocss = (options = {}) => {
 	/**
 	* 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 is the fix. It drops the stale compiled result, which is the defect itself,
+	* and it has to happen here rather than being left to `updateModules`: Vite *soft*-
+	* invalidates an importer that statically imports the changed module, and a soft invalidation
+	* keeps the cached transform — the very place the compiled class string lives.
+	*
+	* Doing it here 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.
+	*
+	* *Naming* those modules back to Vite is a different question, and the answer is almost
+	* always no. `addWatchFile` makes every consumer a direct importer of the dependency in the
+	* module graph, so `propagateUpdate` walks to all of them from the changed file by itself and
+	* sends exactly the same update. Returning them as well does not merge into that pass: a
+	* framework plugin downstream reads the list and re-drives HMR per entry — react-router's
+	* `react-router-server-change-trigger-client-hmr` calls `reloadModule` once per module, in
+	* both its client and its ssr pass — and each of those is a separate `updateModules`, a
+	* separate `hmr update`, and a separate refetch of the whole module by the browser.
 	*
-	* 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.
+	* Measured on a five-route react-router app, one `css()` edit in a shared `ui.ts`: eight
+	* `hmr update` messages, `root.tsx` and `dashboard.tsx` fetched five times each, 554 kB over
+	* the socket for a one-line edit. Dropping the redundant half takes it to four messages and
+	* 367 kB with the same modules re-transformed and the same edit applied.
 	*
-	* 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.
+	* So the list is returned only when Vite has matched nothing for the file and would otherwise
+	* do nothing at all — a dependency the fold read that never became a module of its own. 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));
@@ -3232,6 +3301,7 @@ const bamboocss = (options = {}) => {
 			added.push(module);
 		}
 		if (!added.length) return;
+		if (modules.length) return;
 		return [...modules, ...added];
 	};
 	let ctx;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bamboocss/vite",
-  "version": "1.39.1",
+  "version": "1.40.1",
   "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.39.1",
-    "@bamboocss/extractor": "1.39.1",
-    "@bamboocss/core": "1.39.1",
-    "@bamboocss/logger": "1.39.1",
-    "@bamboocss/node": "1.39.1",
-    "@bamboocss/shared": "1.39.1",
-    "@bamboocss/types": "1.39.1"
+    "@bamboocss/config": "1.40.1",
+    "@bamboocss/extractor": "1.40.1",
+    "@bamboocss/logger": "1.40.1",
+    "@bamboocss/core": "1.40.1",
+    "@bamboocss/node": "1.40.1",
+    "@bamboocss/shared": "1.40.1",
+    "@bamboocss/types": "1.40.1"
   },
   "devDependencies": {
     "@jridgewell/trace-mapping": "^0.3.31",
     "vite": "7.2.6",
-    "@bamboocss/fixture": "1.39.1"
+    "@bamboocss/fixture": "1.40.1"
   },
   "peerDependencies": {
     "vite": ">=5"