@bamboocss/parser 1.28.0 → 1.29.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/dist/index.cjs CHANGED
@@ -65,7 +65,7 @@ function classifyProject(ctx, resultMap) {
65
65
  const { item, kind, filepath, localMaps } = opts;
66
66
  if (!item.box || _bamboocss_extractor.box.isUnresolvable(item.box)) return;
67
67
  if (!item.data) return;
68
- if (item.type === "cva-call") return;
68
+ if (item.type === "cva-call" || item.type === "tokenValue") return;
69
69
  const componentReportItem = {
70
70
  componentIndex: String(componentIndex++),
71
71
  componentName: item.name,
@@ -962,8 +962,14 @@ var ParserResult = class {
962
962
  const unresolved = findUnresolvedRecipeStyles(result);
963
963
  if (unresolved.length) this.unresolved.push(...unresolved);
964
964
  }
965
- setToken(result) {
966
- this.token.add(this.append(Object.assign({ type: "token" }, result)));
965
+ /**
966
+ * `kind` separates the variable reference — `token()` and its `token.var()` alias — from
967
+ * `token.value()`, the resolved literal. They share this set deliberately: everything that
968
+ * reads a result for the token *path* — `collectTokenReferences`, keeping a declaration
969
+ * alive through pruning — wants both, and only the fold cares which half was asked for.
970
+ */
971
+ setToken(result, kind = "token") {
972
+ this.token.add(this.append(Object.assign({ type: kind }, result)));
967
973
  }
968
974
  setViewTransition(result) {
969
975
  this.viewTransition.add(this.append(Object.assign({ type: "viewTransition" }, result)));
@@ -1102,7 +1108,7 @@ function createParser(context) {
1102
1108
  ast: sourceFile,
1103
1109
  tokens: context.tokens ? {
1104
1110
  view: context.tokens.view,
1105
- isTokenFn: (fnName) => file.isTokenAlias(fnName)
1111
+ isTokenFn: (fnName) => file.isTokenFn(fnName)
1106
1112
  } : void 0,
1107
1113
  components: jsx.isEnabled ? {
1108
1114
  matchTag: (prop) => {
@@ -1165,6 +1171,17 @@ function createParser(context) {
1165
1171
  });
1166
1172
  return;
1167
1173
  }
1174
+ const tokenMethod = file.tokenMethod(alias);
1175
+ if (tokenMethod) {
1176
+ result.queryList.forEach((query) => {
1177
+ if (query.kind === "call-expression") parserResult.setToken({
1178
+ name: `token.${tokenMethod}`,
1179
+ box: query.box.value[0] ?? _bamboocss_extractor.box.fallback(query.box),
1180
+ data: combineResult((0, _bamboocss_extractor.unbox)(query.box.value[0]))
1181
+ }, tokenMethod === "value" ? "tokenValue" : "token");
1182
+ });
1183
+ return;
1184
+ }
1168
1185
  (0, ts_pattern.match)(name).when(imports.matchers.css.match, (name) => {
1169
1186
  result.queryList.forEach((query) => {
1170
1187
  if (query.kind === "call-expression") if (query.box.value.length > 1) parserResult.set(name, {
@@ -1260,6 +1277,31 @@ const createTsProject = (options) => new ts_morph.Project({
1260
1277
  ...normalizeCompilerOptions(options.compilerOptions)
1261
1278
  }
1262
1279
  });
1280
+ /**
1281
+ * How to parse a file, decided by its extension.
1282
+ *
1283
+ * Everything used to be `TSX`, which is not a superset of `TS`: the two disagree on exactly
1284
+ * the constructs where `<` is ambiguous. Under `TSX` a generic arrow `<T>(x: T) => x` and an
1285
+ * old-style assertion `<HTMLElement>node` parse as a *JSX element*, which then swallows the
1286
+ * rest of the file into its children. The file still reads fine and the bytes are unchanged;
1287
+ * the tree is simply wrong, and every `css()` call below the offending line stops existing as
1288
+ * far as extraction is concerned. It reports as styles that silently never got emitted.
1289
+ *
1290
+ * Only `.ts` moves. A `.ts` file cannot legally contain JSX — TypeScript requires `.tsx` for
1291
+ * that — so parsing one as `TSX` can only ever mis-parse, never accept something real.
1292
+ *
1293
+ * Everything else stays `TSX` deliberately:
1294
+ *
1295
+ * - `.js` and `.jsx` routinely carry JSX in projects that never adopted TypeScript, and `TSX`
1296
+ * accepts the type syntax they do not use anyway.
1297
+ * - a single-file component is stored under its own extension after `parser:before` rewrites
1298
+ * it to tsx, so `.vue` and `.svelte` have to keep parsing as tsx.
1299
+ * - an unknown extension is somebody's template that a hook may have compiled to jsx.
1300
+ */
1301
+ const scriptKindFor = (filePath) => {
1302
+ const extension = filePath.slice(filePath.lastIndexOf(".")).toLowerCase();
1303
+ return extension === ".ts" || extension === ".mts" || extension === ".cts" ? ts_morph.ScriptKind.TS : ts_morph.ScriptKind.TSX;
1304
+ };
1263
1305
  var Project = class {
1264
1306
  options;
1265
1307
  project;
@@ -1405,7 +1447,7 @@ var Project = class {
1405
1447
  this.invalidate();
1406
1448
  return this.project.createSourceFile(filePath, readFile(filePath), {
1407
1449
  overwrite: true,
1408
- scriptKind: ts_morph.ScriptKind.TSX
1450
+ scriptKind: scriptKindFor(filePath)
1409
1451
  });
1410
1452
  };
1411
1453
  createSourceFiles = () => {
@@ -1416,7 +1458,7 @@ var Project = class {
1416
1458
  this.invalidate(!(filePath.includes("/") && this.project.getSourceFile(filePath)));
1417
1459
  return this.project.createSourceFile(filePath, content, {
1418
1460
  overwrite: true,
1419
- scriptKind: ts_morph.ScriptKind.TSX
1461
+ scriptKind: scriptKindFor(filePath)
1420
1462
  });
1421
1463
  };
1422
1464
  removeSourceFile = (filePath) => {
package/dist/index.d.cts CHANGED
@@ -95,18 +95,28 @@ declare class Generator extends Context {
95
95
  */
96
96
  private getThemeTokenVars;
97
97
  /**
98
- * Tokens whose javascript value is a `var()` reference rather than a literal.
99
- * `token('colors.text')` hands those to the caller as a reference, so the declaration
100
- * has to survive whether or not the generated css mentions it. Ordinary tokens resolve
101
- * to a literal in javascript and need no such exemption.
98
+ * The token declarations held open so a runtime `token()` can answer for any path.
102
99
  *
103
- * The two cases mirror `generateTokenJs`, which is what decides the value javascript
104
- * actually receives:
100
+ * `token()` hands javascript the *variable reference* for every token, so a path the build
101
+ * cannot resolve could name any of them and every declaration has to survive. That is a
102
+ * blunt instrument, and deliberately so: the alternative failure is a `var()` with no
103
+ * declaration behind it, which resolves to the guaranteed-invalid value and inherits
104
+ * rather than falling back — silently wrong, which is worse than visibly large.
105
105
  *
106
- * - A virtual token, or one carrying a condition, is handed its own `varRef`.
107
- * - A negative token is handed `calc(var(--x) * -1)`, so it is a reference too — but to
108
- * the *positive* token's declaration. Its own var is never declared, so the name has
109
- * to come out of the value.
106
+ * It used to be narrower, because `token()` used to return a *literal* for a plain token
107
+ * and only a `var()` for virtual, conditional and negative ones. That split is gone, and
108
+ * narrowing this to match it would now strand exactly the base tokens the old split made
109
+ * safe.
110
+ *
111
+ * So the gate below carries the whole saving. `styled-system/tokens` is generated into the
112
+ * project, so nothing outside it can import them -- if no file under `include` reaches for
113
+ * a token from javascript, no caller exists to serve and the declarations are as prunable
114
+ * as any other.
115
+ *
116
+ * That gate is all-or-nothing per project, which is the coarse part worth fixing next: a
117
+ * project whose token calls all resolve to string literals needs none of this, because
118
+ * `collectTokenReferences` already kept those paths by name. Deciding that needs the
119
+ * reference accounting the gate does not do yet -- see `tokensReachableFromJs`.
110
120
  */
111
121
  private getAlwaysKeptTokenVars;
112
122
  getParserCss: (decoder: StyleDecoder) => string;
@@ -229,7 +239,13 @@ declare class ParserResult implements ParserResultInterface {
229
239
  * hash except an explicit `className`, which is what the message says to reach for.
230
240
  */
231
241
  private reportUnresolvedRecipe;
232
- setToken(result: ResultItem): void;
242
+ /**
243
+ * `kind` separates the variable reference — `token()` and its `token.var()` alias — from
244
+ * `token.value()`, the resolved literal. They share this set deliberately: everything that
245
+ * reads a result for the token *path* — `collectTokenReferences`, keeping a declaration
246
+ * alive through pruning — wants both, and only the fold cares which half was asked for.
247
+ */
248
+ setToken(result: ResultItem, kind?: 'token' | 'tokenValue'): void;
233
249
  setViewTransition(result: ResultItem): void;
234
250
  setPattern(name: string, result: ResultItem): void;
235
251
  setRecipe(recipeName: string, result: ResultItem): void;
package/dist/index.d.mts CHANGED
@@ -95,18 +95,28 @@ declare class Generator extends Context {
95
95
  */
96
96
  private getThemeTokenVars;
97
97
  /**
98
- * Tokens whose javascript value is a `var()` reference rather than a literal.
99
- * `token('colors.text')` hands those to the caller as a reference, so the declaration
100
- * has to survive whether or not the generated css mentions it. Ordinary tokens resolve
101
- * to a literal in javascript and need no such exemption.
98
+ * The token declarations held open so a runtime `token()` can answer for any path.
102
99
  *
103
- * The two cases mirror `generateTokenJs`, which is what decides the value javascript
104
- * actually receives:
100
+ * `token()` hands javascript the *variable reference* for every token, so a path the build
101
+ * cannot resolve could name any of them and every declaration has to survive. That is a
102
+ * blunt instrument, and deliberately so: the alternative failure is a `var()` with no
103
+ * declaration behind it, which resolves to the guaranteed-invalid value and inherits
104
+ * rather than falling back — silently wrong, which is worse than visibly large.
105
105
  *
106
- * - A virtual token, or one carrying a condition, is handed its own `varRef`.
107
- * - A negative token is handed `calc(var(--x) * -1)`, so it is a reference too — but to
108
- * the *positive* token's declaration. Its own var is never declared, so the name has
109
- * to come out of the value.
106
+ * It used to be narrower, because `token()` used to return a *literal* for a plain token
107
+ * and only a `var()` for virtual, conditional and negative ones. That split is gone, and
108
+ * narrowing this to match it would now strand exactly the base tokens the old split made
109
+ * safe.
110
+ *
111
+ * So the gate below carries the whole saving. `styled-system/tokens` is generated into the
112
+ * project, so nothing outside it can import them -- if no file under `include` reaches for
113
+ * a token from javascript, no caller exists to serve and the declarations are as prunable
114
+ * as any other.
115
+ *
116
+ * That gate is all-or-nothing per project, which is the coarse part worth fixing next: a
117
+ * project whose token calls all resolve to string literals needs none of this, because
118
+ * `collectTokenReferences` already kept those paths by name. Deciding that needs the
119
+ * reference accounting the gate does not do yet -- see `tokensReachableFromJs`.
110
120
  */
111
121
  private getAlwaysKeptTokenVars;
112
122
  getParserCss: (decoder: StyleDecoder) => string;
@@ -229,7 +239,13 @@ declare class ParserResult implements ParserResultInterface {
229
239
  * hash except an explicit `className`, which is what the message says to reach for.
230
240
  */
231
241
  private reportUnresolvedRecipe;
232
- setToken(result: ResultItem): void;
242
+ /**
243
+ * `kind` separates the variable reference — `token()` and its `token.var()` alias — from
244
+ * `token.value()`, the resolved literal. They share this set deliberately: everything that
245
+ * reads a result for the token *path* — `collectTokenReferences`, keeping a declaration
246
+ * alive through pruning — wants both, and only the fold cares which half was asked for.
247
+ */
248
+ setToken(result: ResultItem, kind?: 'token' | 'tokenValue'): void;
233
249
  setViewTransition(result: ResultItem): void;
234
250
  setPattern(name: string, result: ResultItem): void;
235
251
  setRecipe(recipeName: string, result: ResultItem): void;
package/dist/index.mjs CHANGED
@@ -64,7 +64,7 @@ function classifyProject(ctx, resultMap) {
64
64
  const { item, kind, filepath, localMaps } = opts;
65
65
  if (!item.box || box.isUnresolvable(item.box)) return;
66
66
  if (!item.data) return;
67
- if (item.type === "cva-call") return;
67
+ if (item.type === "cva-call" || item.type === "tokenValue") return;
68
68
  const componentReportItem = {
69
69
  componentIndex: String(componentIndex++),
70
70
  componentName: item.name,
@@ -961,8 +961,14 @@ var ParserResult = class {
961
961
  const unresolved = findUnresolvedRecipeStyles(result);
962
962
  if (unresolved.length) this.unresolved.push(...unresolved);
963
963
  }
964
- setToken(result) {
965
- this.token.add(this.append(Object.assign({ type: "token" }, result)));
964
+ /**
965
+ * `kind` separates the variable reference — `token()` and its `token.var()` alias — from
966
+ * `token.value()`, the resolved literal. They share this set deliberately: everything that
967
+ * reads a result for the token *path* — `collectTokenReferences`, keeping a declaration
968
+ * alive through pruning — wants both, and only the fold cares which half was asked for.
969
+ */
970
+ setToken(result, kind = "token") {
971
+ this.token.add(this.append(Object.assign({ type: kind }, result)));
966
972
  }
967
973
  setViewTransition(result) {
968
974
  this.viewTransition.add(this.append(Object.assign({ type: "viewTransition" }, result)));
@@ -1101,7 +1107,7 @@ function createParser(context) {
1101
1107
  ast: sourceFile,
1102
1108
  tokens: context.tokens ? {
1103
1109
  view: context.tokens.view,
1104
- isTokenFn: (fnName) => file.isTokenAlias(fnName)
1110
+ isTokenFn: (fnName) => file.isTokenFn(fnName)
1105
1111
  } : void 0,
1106
1112
  components: jsx.isEnabled ? {
1107
1113
  matchTag: (prop) => {
@@ -1164,6 +1170,17 @@ function createParser(context) {
1164
1170
  });
1165
1171
  return;
1166
1172
  }
1173
+ const tokenMethod = file.tokenMethod(alias);
1174
+ if (tokenMethod) {
1175
+ result.queryList.forEach((query) => {
1176
+ if (query.kind === "call-expression") parserResult.setToken({
1177
+ name: `token.${tokenMethod}`,
1178
+ box: query.box.value[0] ?? box.fallback(query.box),
1179
+ data: combineResult(unbox(query.box.value[0]))
1180
+ }, tokenMethod === "value" ? "tokenValue" : "token");
1181
+ });
1182
+ return;
1183
+ }
1167
1184
  match(name).when(imports.matchers.css.match, (name) => {
1168
1185
  result.queryList.forEach((query) => {
1169
1186
  if (query.kind === "call-expression") if (query.box.value.length > 1) parserResult.set(name, {
@@ -1259,6 +1276,31 @@ const createTsProject = (options) => new Project$1({
1259
1276
  ...normalizeCompilerOptions(options.compilerOptions)
1260
1277
  }
1261
1278
  });
1279
+ /**
1280
+ * How to parse a file, decided by its extension.
1281
+ *
1282
+ * Everything used to be `TSX`, which is not a superset of `TS`: the two disagree on exactly
1283
+ * the constructs where `<` is ambiguous. Under `TSX` a generic arrow `<T>(x: T) => x` and an
1284
+ * old-style assertion `<HTMLElement>node` parse as a *JSX element*, which then swallows the
1285
+ * rest of the file into its children. The file still reads fine and the bytes are unchanged;
1286
+ * the tree is simply wrong, and every `css()` call below the offending line stops existing as
1287
+ * far as extraction is concerned. It reports as styles that silently never got emitted.
1288
+ *
1289
+ * Only `.ts` moves. A `.ts` file cannot legally contain JSX — TypeScript requires `.tsx` for
1290
+ * that — so parsing one as `TSX` can only ever mis-parse, never accept something real.
1291
+ *
1292
+ * Everything else stays `TSX` deliberately:
1293
+ *
1294
+ * - `.js` and `.jsx` routinely carry JSX in projects that never adopted TypeScript, and `TSX`
1295
+ * accepts the type syntax they do not use anyway.
1296
+ * - a single-file component is stored under its own extension after `parser:before` rewrites
1297
+ * it to tsx, so `.vue` and `.svelte` have to keep parsing as tsx.
1298
+ * - an unknown extension is somebody's template that a hook may have compiled to jsx.
1299
+ */
1300
+ const scriptKindFor = (filePath) => {
1301
+ const extension = filePath.slice(filePath.lastIndexOf(".")).toLowerCase();
1302
+ return extension === ".ts" || extension === ".mts" || extension === ".cts" ? ScriptKind.TS : ScriptKind.TSX;
1303
+ };
1262
1304
  var Project = class {
1263
1305
  options;
1264
1306
  project;
@@ -1404,7 +1446,7 @@ var Project = class {
1404
1446
  this.invalidate();
1405
1447
  return this.project.createSourceFile(filePath, readFile(filePath), {
1406
1448
  overwrite: true,
1407
- scriptKind: ScriptKind.TSX
1449
+ scriptKind: scriptKindFor(filePath)
1408
1450
  });
1409
1451
  };
1410
1452
  createSourceFiles = () => {
@@ -1415,7 +1457,7 @@ var Project = class {
1415
1457
  this.invalidate(!(filePath.includes("/") && this.project.getSourceFile(filePath)));
1416
1458
  return this.project.createSourceFile(filePath, content, {
1417
1459
  overwrite: true,
1418
- scriptKind: ScriptKind.TSX
1460
+ scriptKind: scriptKindFor(filePath)
1419
1461
  });
1420
1462
  };
1421
1463
  removeSourceFile = (filePath) => {
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@bamboocss/parser",
3
- "version": "1.28.0",
3
+ "version": "1.29.0",
4
4
  "description": "The static parser for bamboo css",
5
5
  "homepage": "https://bamboocss.com",
6
6
  "license": "MIT",
@@ -34,17 +34,17 @@
34
34
  "dependencies": {
35
35
  "ts-morph": "28.0.0",
36
36
  "ts-pattern": "5.9.0",
37
- "@bamboocss/config": "^1.28.0",
38
- "@bamboocss/core": "^1.28.0",
39
- "@bamboocss/extractor": "1.28.0",
40
- "@bamboocss/logger": "1.28.0",
41
- "@bamboocss/shared": "1.28.0",
42
- "@bamboocss/types": "1.28.0"
37
+ "@bamboocss/config": "^1.29.0",
38
+ "@bamboocss/extractor": "1.29.0",
39
+ "@bamboocss/logger": "1.29.0",
40
+ "@bamboocss/shared": "1.29.0",
41
+ "@bamboocss/core": "^1.29.0",
42
+ "@bamboocss/types": "1.29.0"
43
43
  },
44
44
  "devDependencies": {
45
- "@bamboocss/generator": "1.28.0",
46
- "@bamboocss/plugin-svelte": "1.28.0",
47
- "@bamboocss/plugin-vue": "1.28.0"
45
+ "@bamboocss/generator": "1.29.0",
46
+ "@bamboocss/plugin-svelte": "1.29.0",
47
+ "@bamboocss/plugin-vue": "1.29.0"
48
48
  },
49
49
  "scripts": {
50
50
  "build": "tsdown src/index.ts --format=esm,cjs --dts",