Uh oh!
There was an error while loading. Please reload this page.
fix(console): make vite/vitest configs loadable by configLoader: 'native' - #3475
Merged
Conversation
…tive'` Vite 8 warns that both console configs use features its native config loader drops. Today the warnings are cosmetic (the default `bundle` loader shims them); the day Vite flips the default, console dev/build/vitest all fail to load their config at once, on an unrelated dependency bump. - `__dirname` -> `import.meta.dirname` (36 sites in vite.config.ts, 1 in vitest.config.ts). Vite reports only the FIRST occurrence per file, so the 5-warning block understated the work: a single surviving `__dirname` still throws `ReferenceError: __dirname is not defined in ES module scope` under the native loader. - Explicit `.ts` extensions on the three relative specifiers (`./vite.config`, `../../scripts/vite-crypto-stub`, `../../scripts/vite-maplibre-worker`) — Node's ESM resolver does no extension guessing. Verified: the 5-warning block is gone from `vitest list apps/console/`, and `resolveConfig(..., 'build')` yields an identical result (46 plugins, same resolved aliases) under both `configLoader: 'bundle'` and `'native'`. Refs objectui#3384
The latest updates on your projects. Learn more about Vercel for GitHub. |
Contributor
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
…ecifiers The `.ts` extensions the previous commit added (required by Vite's native config loader — Node's ESM resolver does no extension guessing) are rejected by `tsc` with TS5097: `moduleResolution: bundler` accepts `./x` and `./x.js`, but an explicit `./x.ts` needs `allowImportingTsExtensions`. That option requires one of `noEmit` / `emitDeclarationOnly` / `rewriteRelativeImportExtensions`. `noEmit` is unavailable here — `tsconfig.json` references this project, so disabling emit is TS6310, the constraint this file already documents. `rewriteRelativeImportExtensions` would add `.ts` -> `.js` rewriting to output nobody reads. So: declarations only. They keep landing in the existing cache `outDir`; the `.js` half was never consumed. `tsc -b apps/console/tsconfig.node.json --force` now exits 0 with no litter in the working tree. Refs objectui#3384
Contributor
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
yinlianghui
marked this pull request as ready for review
August 6, 2026 13:51
Uh oh!
There was an error while loading. Please reload this page.
akarma-synetal pushed a commit
to akarma-synetal/objectui
that referenced
this pull request
Aug 10, 2026
…的 cache key (objectstack-ai#3513) * ci(console): put vitest.config.ts in a tsc program and drop the ghost include entry `apps/console/vitest.config.ts` was in ZERO tsc programs. CI runs `turbo run type-check` — per package — and neither console tsconfig reached the file: `tsconfig.json` includes only `src`/`dev`/ `objectstack.config.ts`, and `tsconfig.node.json` listed only `vite.config.ts` and a `vitest.setup.ts` that does not exist. Add `vitest.config.ts` to `tsconfig.node.json`'s include. Its import of `../../vitest.config.mts` has to be listed too — a composite project must list every file in its program (TS6307) — which incidentally gives the root Vitest config the gate it also lacked. Drop the `vitest.setup.ts` entry rather than repoint it. A literal, glob-less include entry matching nothing is silently ignored by tsc, so it read as coverage that was never there. The setup file `vitest.config.ts` really uses (repo-root `vitest.setup.dom.tsx`) is passed to Vitest as a runtime path string, never imported, so this program has no type edge to it; naming it here was measured red (one TS6307 + four TS2882). No flag changes were needed: `allowImportingTsExtensions` + `emitDeclarationOnly` from objectstack-ai#3475 already cover the `.ts`/`.mts` spellings. Refs objectstack-ai#3476 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GTRjn8xBqp75dk7kFupVRt * ci(turbo): hash the root vitest config into the type-check cache key The previous commit makes apps/console's type-check program span a second repo-root file (`vitest.config.mts`, pulled in because `apps/console/vitest.config.ts` imports it and a composite project must list every file in its program). turbo's `type-check` inputs did not hash it: `$TURBO_DEFAULT$` only covers files inside the package directory, and `globalDependencies` is unset. Measured A/B on this branch, same tree, same plant (a real type error in the root `vitest.config.mts`): old inputs -> cache hit, replaying logs 4214aa6ab3df0f18 -> exit 0 (a green replayed over a program that does not compile) new inputs -> cache miss, executing 648e8a0633f2bff7 -> exit 1 ../../vitest.config.mts(114,5): error TS2769 Not local-only: ci.yml persists .turbo/cache via actions/cache, and in this container turbo resolves its cache to the shared checkout's .turbo, so a stale green survives across worktrees too. Symmetric with the `$TURBO_ROOT$/scripts/vite-*.ts` entry already present, which exists for exactly this reason for the other root-level file in the same program. Refs objectstack-ai#3476, objectstack-ai#3514 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GTRjn8xBqp75dk7kFupVRt --------- Co-authored-by: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes#3384
背景
Vite 8 每次加载 console 配置都会打印同一个 5 行告警块:两个配置文件用到了
configLoader: 'native'不支持的特性。今天只是告警(默认的bundleloader 替它们做了补丁),但 Vite 把默认值翻过去的那一天,console 的 dev / build / vitest 会同时在「加载配置」这一步挂掉 —— 而且扣扳机的会是一次毫不相关的依赖升级。改动
三个文件,两个提交:
apps/console/vite.config.ts/apps/console/vitest.config.ts__dirname→import.meta.dirname:36 处(vite.config.ts)+ 1 处(vitest.config.ts)。.ts:./vite.config、../../scripts/vite-crypto-stub、../../scripts/vite-maplibre-worker。Node 的 ESM 解析器不做扩展名猜测。scripts/vite-*.ts本身没有改动 —— 扩展名只写在导入方。apps/console/tsconfig.node.json(两行,见下方「type-check 门」一节)allowImportingTsExtensions+emitDeclarationOnly—— 让 apps/console/tsconfig.node.json never type-checks — 5 standing errors, including two that say the compression options are typed wrong #3305 那道门接受显式.tsspecifier。告警只报了 5 条,真实站点是 39 个
Vite 对同一文件的同一类问题只报第一处。「5 个告警」严重低估了工作量:vite.config.ts 里有 36 处
__dirname,告警只点名了第 56 行那一处。这不是洁癖,反向验证在下面。验证
告警块前后对照(同一条命令
pnpm exec vitest list apps/console/)改动前:
改动后:告警块消失,输出直接从测试清单开始。
vitest run的完整输出里同样一条都没有。两个 loader 下配置解析完全一致(
resolveConfig,command 为 build)说明
import.meta.dirname算出的绝对路径与原来的__dirname一致。反向验证(预测方向:改前红 / 改后绿 —— 结果符合)
把两个文件退回 origin/main,再用
configLoader: 'native'加载:注意:模块解析先失败,把
__dirname那一半掩盖掉了。于是单独隔离 —— 扩展名保持修好,只把 36 处里的 1 处改回__dirname:漏掉任意一处
__dirname都足以让整个配置加载失败,所以必须全改。测试
pnpm exec vitest run apps/console/ --maxWorkers=2(仓库根):Test Files 23 passed (23)/Tests 211 passed (211)tsc -b apps/console/tsconfig.node.json --force:exit 0,工作树零 litter,产物仍全部落在原有的outDir(node_modules/.cache/tsc/console-node),且只有.d.ts、没有.jseslint vite.config.ts vitest.config.ts:干净grep -naP '[\x00-\x08\x0b\x0c\x0e-\x1f]':干净type-check 门:为什么要动
tsconfig.node.json.ts扩展名会让 #3305 那道门(apps/console的tsc -b tsconfig.node.json --force,CI 的 type-check job 会跑到)报错,而且只报这两条:issue 正文里「
moduleResolution: bundleraccepts both spellings」这一句不成立:bundler 接受./x和./x.js,但./x.ts必须开allowImportingTsExtensions。而.ts是唯一能被 Node 原生 ESM 解析的写法(./x.js在磁盘上不存在),所以绕不过去。补丁就是两行:
emitDeclarationOnly这个搭档不是随便挑的,三个候选实测过:noEmit—— 不行。allowImportingTsExtensions必须搭配noEmit/emitDeclarationOnly/rewriteRelativeImportExtensions之一(否则 TS5096),但noEmit会让type-check的前半段tsc --noEmit挂掉:tsconfig.json(28,18): error TS6310: Referenced project '.../tsconfig.node.json' may not disable emit.—— 正是tsconfig.node.json自己注释里写明的那条约束。rewriteRelativeImportExtensions—— 能过,但它给一份反正要丢掉的产物加上了.ts→.js改写语义,没有意义。emitDeclarationOnly—— 选它。composite 工程本来就需要声明产物,而那份.js从来没人用;它满足 TS6310(没有禁用 emit),又把丢弃的输出减到最小,和该文件「存在只为被类型检查」的既有设计一致。为什么没有显式钉
configLoader: 'native'issue 里那条 optional 建议做不到 —— 不是版本兼容问题,是结构问题:
configLoader是InlineConfig的字段,不在UserConfig上。它是loadConfigFromFile(...)的入参 —— 「用哪种方式读这个配置文件」,在配置文件被读出来之前就已经消费掉了。写在vite.config.ts里的键不可能影响读它自己的那一步。Vitest 侧同样:它的configLoader类型注释原文是 "Override vite config's configLoader from CLI"。因此钉死只能落在调用处(
apps/console/package.json的dev/build加vite --configLoader native;或根test脚本加vitest run --configLoader native—— 后者会把 native 强加给所有 project 配置,波及面远超本 issue)。两者都超出本 issue 范围,PM 已据此撤回该要求。兼容性本身是验证过的、绿的:本 PR 之后
apps/console/vite.config.ts、apps/console/vitest.config.ts、根vitest.config.mts三者在configLoader: 'native'下都能正常加载 —— 真要钉,随时可以钉,只是得换个文件落地。另外:告警块清零本身就是回归绊线 —— 之前 5 条常驻噪音里再多一条没人看得见,现在任何新引入的不兼容写法都是干净输出里唯一的那条告警。
Changeset
没加。
@object-ui/console确实是发布包(在 fixed 组内,非 private),但本次只改开发期配置文件,不进dist/,对使用者零可见变化 —— 按 AGENTS.md「纯 bug 修复不需要 changeset」处理。顺手记录的 finding
#3476(observation 类,未排期):
apps/console/vitest.config.ts不在任何 tsc program 里(两个 console tsconfig 的include都没覆盖它),以及tsconfig.node.json的include列了一个不存在的vitest.setup.ts。与本 PR 独立成立。