@bamboocss/parser 1.28.1 → 1.30.0

package/dist/index.cjs

@@ -65,7 +65,7 @@ function classifyProject(ctx, resultMap) {
 		const { item, kind, filepath, localMaps } = opts;
 		if (!item.box || _bamboocss_extractor.box.isUnresolvable(item.box)) return;
 		if (!item.data) return;
-		if (item.type === "cva-call" || item.type === "tokenVar") return;
+		if (item.type === "cva-call" || item.type === "tokenValue") return;
 		const componentReportItem = {
 			componentIndex: String(componentIndex++),
 			componentName: item.name,
@@ -963,10 +963,10 @@ var ParserResult = class {
 		if (unresolved.length) this.unresolved.push(...unresolved);
 	}
 	/**
-	* `kind` separates `token()` from `token.var()`, which resolve to the value and to the
-	* variable reference respectively. They share this set deliberately: everything that reads
-	* a result for the token *path* — `collectTokenReferences`, keeping a declaration alive
-	* through pruning — wants both, and only the fold cares which half was asked for.
+	* `kind` separates the variable reference — `token()` — from `token.value()`, the resolved
+	* literal. They share this set deliberately: everything that
+	* reads a result for the token *path* — `collectTokenReferences`, keeping a declaration
+	* alive through pruning — wants both, and only the fold cares which half was asked for.
 	*/
 	setToken(result, kind = "token") {
 		this.token.add(this.append(Object.assign({ type: kind }, result)));
@@ -1108,7 +1108,7 @@ function createParser(context) {
 			ast: sourceFile,
 			tokens: context.tokens ? {
 				view: context.tokens.view,
-				isTokenFn: (fnName) => file.isTokenAlias(fnName)
+				isTokenFn: (fnName) => file.isTokenFn(fnName)
 			} : void 0,
 			components: jsx.isEnabled ? {
 				matchTag: (prop) => {
@@ -1171,13 +1171,13 @@ function createParser(context) {
 					});
 					return;
 				}
-				if (file.isTokenVarFn(alias)) {
+				if (file.isTokenValueFn(alias)) {
 					result.queryList.forEach((query) => {
 						if (query.kind === "call-expression") parserResult.setToken({
-							name: "token.var",
+							name: "token.value",
 							box: query.box.value[0] ?? _bamboocss_extractor.box.fallback(query.box),
 							data: combineResult((0, _bamboocss_extractor.unbox)(query.box.value[0]))
-						}, "tokenVar");
+						}, "tokenValue");
 					});
 					return;
 				}
@@ -1276,6 +1276,31 @@ const createTsProject = (options) => new ts_morph.Project({
 		...normalizeCompilerOptions(options.compilerOptions)
 	}
 });
+/**
+* How to parse a file, decided by its extension.
+*
+* Everything used to be `TSX`, which is not a superset of `TS`: the two disagree on exactly
+* the constructs where `<` is ambiguous. Under `TSX` a generic arrow `<T>(x: T) => x` and an
+* old-style assertion `<HTMLElement>node` parse as a *JSX element*, which then swallows the
+* rest of the file into its children. The file still reads fine and the bytes are unchanged;
+* the tree is simply wrong, and every `css()` call below the offending line stops existing as
+* far as extraction is concerned. It reports as styles that silently never got emitted.
+*
+* Only `.ts` moves. A `.ts` file cannot legally contain JSX — TypeScript requires `.tsx` for
+* that — so parsing one as `TSX` can only ever mis-parse, never accept something real.
+*
+* Everything else stays `TSX` deliberately:
+*
+* - `.js` and `.jsx` routinely carry JSX in projects that never adopted TypeScript, and `TSX`
+*   accepts the type syntax they do not use anyway.
+* - a single-file component is stored under its own extension after `parser:before` rewrites
+*   it to tsx, so `.vue` and `.svelte` have to keep parsing as tsx.
+* - an unknown extension is somebody's template that a hook may have compiled to jsx.
+*/
+const scriptKindFor = (filePath) => {
+	const extension = filePath.slice(filePath.lastIndexOf(".")).toLowerCase();
+	return extension === ".ts" || extension === ".mts" || extension === ".cts" ? ts_morph.ScriptKind.TS : ts_morph.ScriptKind.TSX;
+};
 var Project = class {
 	options;
 	project;
@@ -1421,7 +1446,7 @@ var Project = class {
 		this.invalidate();
 		return this.project.createSourceFile(filePath, readFile(filePath), {
 			overwrite: true,
-			scriptKind: ts_morph.ScriptKind.TSX
+			scriptKind: scriptKindFor(filePath)
 		});
 	};
 	createSourceFiles = () => {
@@ -1432,7 +1457,7 @@ var Project = class {
 		this.invalidate(!(filePath.includes("/") && this.project.getSourceFile(filePath)));
 		return this.project.createSourceFile(filePath, content, {
 			overwrite: true,
-			scriptKind: ts_morph.ScriptKind.TSX
+			scriptKind: scriptKindFor(filePath)
 		});
 	};
 	removeSourceFile = (filePath) => {

package/dist/index.d.cts

@@ -95,18 +95,28 @@ declare class Generator extends Context {
    */
   private getThemeTokenVars;
   /**
-   * Tokens whose javascript value is a `var()` reference rather than a literal.
-   * `token('colors.text')` hands those to the caller as a reference, so the declaration
-   * has to survive whether or not the generated css mentions it. Ordinary tokens resolve
-   * to a literal in javascript and need no such exemption.
+   * The token declarations held open so a runtime `token()` can answer for any path.
    *
-   * The two cases mirror `generateTokenJs`, which is what decides the value javascript
-   * actually receives:
+   * `token()` hands javascript the *variable reference* for every token, so a path the build
+   * cannot resolve could name any of them and every declaration has to survive. That is a
+   * blunt instrument, and deliberately so: the alternative failure is a `var()` with no
+   * declaration behind it, which resolves to the guaranteed-invalid value and inherits
+   * rather than falling back — silently wrong, which is worse than visibly large.
    *
-   * - A virtual token, or one carrying a condition, is handed its own `varRef`.
-   * - A negative token is handed `calc(var(--x) * -1)`, so it is a reference too — but to
-   *   the *positive* token's declaration. Its own var is never declared, so the name has
-   *   to come out of the value.
+   * It used to be narrower, because `token()` used to return a *literal* for a plain token
+   * and only a `var()` for virtual, conditional and negative ones. That split is gone, and
+   * narrowing this to match it would now strand exactly the base tokens the old split made
+   * safe.
+   *
+   * So the gate below carries the whole saving. `styled-system/tokens` is generated into the
+   * project, so nothing outside it can import them -- if no file under `include` reaches for
+   * a token from javascript, no caller exists to serve and the declarations are as prunable
+   * as any other.
+   *
+   * That gate is all-or-nothing per project, which is the coarse part worth fixing next: a
+   * project whose token calls all resolve to string literals needs none of this, because
+   * `collectTokenReferences` already kept those paths by name. Deciding that needs the
+   * reference accounting the gate does not do yet -- see `tokensReachableFromJs`.
    */
   private getAlwaysKeptTokenVars;
   getParserCss: (decoder: StyleDecoder) => string;
@@ -230,12 +240,12 @@ declare class ParserResult implements ParserResultInterface {
    */
   private reportUnresolvedRecipe;
   /**
-   * `kind` separates `token()` from `token.var()`, which resolve to the value and to the
-   * variable reference respectively. They share this set deliberately: everything that reads
-   * a result for the token *path* — `collectTokenReferences`, keeping a declaration alive
-   * through pruning — wants both, and only the fold cares which half was asked for.
+   * `kind` separates the variable reference — `token()` — from `token.value()`, the resolved
+   * literal. They share this set deliberately: everything that
+   * reads a result for the token *path* — `collectTokenReferences`, keeping a declaration
+   * alive through pruning — wants both, and only the fold cares which half was asked for.
    */
-  setToken(result: ResultItem, kind?: 'token' | 'tokenVar'): void;
+  setToken(result: ResultItem, kind?: 'token' | 'tokenValue'): void;
   setViewTransition(result: ResultItem): void;
   setPattern(name: string, result: ResultItem): void;
   setRecipe(recipeName: string, result: ResultItem): void;

package/dist/index.d.mts

@@ -95,18 +95,28 @@ declare class Generator extends Context {
    */
   private getThemeTokenVars;
   /**
-   * Tokens whose javascript value is a `var()` reference rather than a literal.
-   * `token('colors.text')` hands those to the caller as a reference, so the declaration
-   * has to survive whether or not the generated css mentions it. Ordinary tokens resolve
-   * to a literal in javascript and need no such exemption.
+   * The token declarations held open so a runtime `token()` can answer for any path.
    *
-   * The two cases mirror `generateTokenJs`, which is what decides the value javascript
-   * actually receives:
+   * `token()` hands javascript the *variable reference* for every token, so a path the build
+   * cannot resolve could name any of them and every declaration has to survive. That is a
+   * blunt instrument, and deliberately so: the alternative failure is a `var()` with no
+   * declaration behind it, which resolves to the guaranteed-invalid value and inherits
+   * rather than falling back — silently wrong, which is worse than visibly large.
    *
-   * - A virtual token, or one carrying a condition, is handed its own `varRef`.
-   * - A negative token is handed `calc(var(--x) * -1)`, so it is a reference too — but to
-   *   the *positive* token's declaration. Its own var is never declared, so the name has
-   *   to come out of the value.
+   * It used to be narrower, because `token()` used to return a *literal* for a plain token
+   * and only a `var()` for virtual, conditional and negative ones. That split is gone, and
+   * narrowing this to match it would now strand exactly the base tokens the old split made
+   * safe.
+   *
+   * So the gate below carries the whole saving. `styled-system/tokens` is generated into the
+   * project, so nothing outside it can import them -- if no file under `include` reaches for
+   * a token from javascript, no caller exists to serve and the declarations are as prunable
+   * as any other.
+   *
+   * That gate is all-or-nothing per project, which is the coarse part worth fixing next: a
+   * project whose token calls all resolve to string literals needs none of this, because
+   * `collectTokenReferences` already kept those paths by name. Deciding that needs the
+   * reference accounting the gate does not do yet -- see `tokensReachableFromJs`.
    */
   private getAlwaysKeptTokenVars;
   getParserCss: (decoder: StyleDecoder) => string;
@@ -230,12 +240,12 @@ declare class ParserResult implements ParserResultInterface {
    */
   private reportUnresolvedRecipe;
   /**
-   * `kind` separates `token()` from `token.var()`, which resolve to the value and to the
-   * variable reference respectively. They share this set deliberately: everything that reads
-   * a result for the token *path* — `collectTokenReferences`, keeping a declaration alive
-   * through pruning — wants both, and only the fold cares which half was asked for.
+   * `kind` separates the variable reference — `token()` — from `token.value()`, the resolved
+   * literal. They share this set deliberately: everything that
+   * reads a result for the token *path* — `collectTokenReferences`, keeping a declaration
+   * alive through pruning — wants both, and only the fold cares which half was asked for.
    */
-  setToken(result: ResultItem, kind?: 'token' | 'tokenVar'): void;
+  setToken(result: ResultItem, kind?: 'token' | 'tokenValue'): void;
   setViewTransition(result: ResultItem): void;
   setPattern(name: string, result: ResultItem): void;
   setRecipe(recipeName: string, result: ResultItem): void;

package/dist/index.mjs

@@ -64,7 +64,7 @@ function classifyProject(ctx, resultMap) {
 		const { item, kind, filepath, localMaps } = opts;
 		if (!item.box || box.isUnresolvable(item.box)) return;
 		if (!item.data) return;
-		if (item.type === "cva-call" || item.type === "tokenVar") return;
+		if (item.type === "cva-call" || item.type === "tokenValue") return;
 		const componentReportItem = {
 			componentIndex: String(componentIndex++),
 			componentName: item.name,
@@ -962,10 +962,10 @@ var ParserResult = class {
 		if (unresolved.length) this.unresolved.push(...unresolved);
 	}
 	/**
-	* `kind` separates `token()` from `token.var()`, which resolve to the value and to the
-	* variable reference respectively. They share this set deliberately: everything that reads
-	* a result for the token *path* — `collectTokenReferences`, keeping a declaration alive
-	* through pruning — wants both, and only the fold cares which half was asked for.
+	* `kind` separates the variable reference — `token()` — from `token.value()`, the resolved
+	* literal. They share this set deliberately: everything that
+	* reads a result for the token *path* — `collectTokenReferences`, keeping a declaration
+	* alive through pruning — wants both, and only the fold cares which half was asked for.
 	*/
 	setToken(result, kind = "token") {
 		this.token.add(this.append(Object.assign({ type: kind }, result)));
@@ -1107,7 +1107,7 @@ function createParser(context) {
 			ast: sourceFile,
 			tokens: context.tokens ? {
 				view: context.tokens.view,
-				isTokenFn: (fnName) => file.isTokenAlias(fnName)
+				isTokenFn: (fnName) => file.isTokenFn(fnName)
 			} : void 0,
 			components: jsx.isEnabled ? {
 				matchTag: (prop) => {
@@ -1170,13 +1170,13 @@ function createParser(context) {
 					});
 					return;
 				}
-				if (file.isTokenVarFn(alias)) {
+				if (file.isTokenValueFn(alias)) {
 					result.queryList.forEach((query) => {
 						if (query.kind === "call-expression") parserResult.setToken({
-							name: "token.var",
+							name: "token.value",
 							box: query.box.value[0] ?? box.fallback(query.box),
 							data: combineResult(unbox(query.box.value[0]))
-						}, "tokenVar");
+						}, "tokenValue");
 					});
 					return;
 				}
@@ -1275,6 +1275,31 @@ const createTsProject = (options) => new Project$1({
 		...normalizeCompilerOptions(options.compilerOptions)
 	}
 });
+/**
+* How to parse a file, decided by its extension.
+*
+* Everything used to be `TSX`, which is not a superset of `TS`: the two disagree on exactly
+* the constructs where `<` is ambiguous. Under `TSX` a generic arrow `<T>(x: T) => x` and an
+* old-style assertion `<HTMLElement>node` parse as a *JSX element*, which then swallows the
+* rest of the file into its children. The file still reads fine and the bytes are unchanged;
+* the tree is simply wrong, and every `css()` call below the offending line stops existing as
+* far as extraction is concerned. It reports as styles that silently never got emitted.
+*
+* Only `.ts` moves. A `.ts` file cannot legally contain JSX — TypeScript requires `.tsx` for
+* that — so parsing one as `TSX` can only ever mis-parse, never accept something real.
+*
+* Everything else stays `TSX` deliberately:
+*
+* - `.js` and `.jsx` routinely carry JSX in projects that never adopted TypeScript, and `TSX`
+*   accepts the type syntax they do not use anyway.
+* - a single-file component is stored under its own extension after `parser:before` rewrites
+*   it to tsx, so `.vue` and `.svelte` have to keep parsing as tsx.
+* - an unknown extension is somebody's template that a hook may have compiled to jsx.
+*/
+const scriptKindFor = (filePath) => {
+	const extension = filePath.slice(filePath.lastIndexOf(".")).toLowerCase();
+	return extension === ".ts" || extension === ".mts" || extension === ".cts" ? ScriptKind.TS : ScriptKind.TSX;
+};
 var Project = class {
 	options;
 	project;
@@ -1420,7 +1445,7 @@ var Project = class {
 		this.invalidate();
 		return this.project.createSourceFile(filePath, readFile(filePath), {
 			overwrite: true,
-			scriptKind: ScriptKind.TSX
+			scriptKind: scriptKindFor(filePath)
 		});
 	};
 	createSourceFiles = () => {
@@ -1431,7 +1456,7 @@ var Project = class {
 		this.invalidate(!(filePath.includes("/") && this.project.getSourceFile(filePath)));
 		return this.project.createSourceFile(filePath, content, {
 			overwrite: true,
-			scriptKind: ScriptKind.TSX
+			scriptKind: scriptKindFor(filePath)
 		});
 	};
 	removeSourceFile = (filePath) => {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bamboocss/parser",
-  "version": "1.28.1",
+  "version": "1.30.0",
   "description": "The static parser for bamboo css",
   "homepage": "https://bamboocss.com",
   "license": "MIT",
@@ -34,17 +34,17 @@
   "dependencies": {
     "ts-morph": "28.0.0",
     "ts-pattern": "5.9.0",
-    "@bamboocss/extractor": "1.28.1",
-    "@bamboocss/core": "^1.28.1",
-    "@bamboocss/config": "^1.28.1",
-    "@bamboocss/logger": "1.28.1",
-    "@bamboocss/shared": "1.28.1",
-    "@bamboocss/types": "1.28.1"
+    "@bamboocss/config": "^1.30.0",
+    "@bamboocss/core": "^1.30.0",
+    "@bamboocss/extractor": "1.30.0",
+    "@bamboocss/logger": "1.30.0",
+    "@bamboocss/shared": "1.30.0",
+    "@bamboocss/types": "1.30.0"
   },
   "devDependencies": {
-    "@bamboocss/generator": "1.28.1",
-    "@bamboocss/plugin-svelte": "1.28.1",
-    "@bamboocss/plugin-vue": "1.28.1"
+    "@bamboocss/generator": "1.30.0",
+    "@bamboocss/plugin-svelte": "1.30.0",
+    "@bamboocss/plugin-vue": "1.30.0"
   },
   "scripts": {
     "build": "tsdown src/index.ts --format=esm,cjs --dts",