pi 2026-09-15 实测出来的,**这次长在判据自己身上** —— 正是我们前几轮一直在消的那个形状。
## 一、`const ROOT = '/home/program/agentmail'`:规则进来了,对象没进来
`harmony-arkts.test.mjs` 把仓库根写成了绝对路径。后果我按 pi 的步骤亲手复现了:
```
$ git worktree add --detach /tmp/wt-verify 7f4fa26 # 那个检出里 import 顺序**确实**违规
(核对:最后 import 在第 80 行,而第 63 行已是 `const NAV_MATERIAL_OF…`)
$ cd /tmp/wt-verify/client/electron && node --test test/harmony-arkts.test.mjs
ok 1 / ok 2 / ok 3 # pass 3 # fail 0 ← **在一个明显违规的检出上 3/3 全绿**
```
因为它读的不是 `/tmp/wt-verify`,是 `/home/program/agentmail`(那份早已修好)。
两层后果,第二层最糟:
① 它**永远无法验证任何别的 checkout / CI / 镜像** —— 换目录不是"红",是 `readdirSync` 直接抛;
② 在本机做 worktree 复核时,它**静默读另一棵树并报绿**。
**判据的逻辑是对的、对象是错的** —— 这比"判据写错了"更难发现,因为它在原地永远是绿的。
同一个毛病在 4 个文件里,**恰好全是最近这几笔新写的**(另 10 个鸿蒙判据写法是对的):
```
harmony-admin / harmony-imageprep / harmony-presets / harmony-arkts → const ROOT = '/home/program/agentmail';
其余 10 个 → const ROOT = join(HERE, '..', '..', '..');
```
已全部照邻居改掉。**修好之后在同一个违规检出上:`# fail 1`** —— 它终于会红了。
## 二、修这条时又牵出一个:`stripComments` **改变了行号**
修好路径后,判据报出"最后一个 import 在第 64 行、第 47 行已是语句",
而**真实文件里是第 80 / 63 行**。成因:`stripComments` 把块注释整块抹成 `''`,
而块注释**自带换行** ⇒ 它之后所有行号整体前移。
这不是小节:全仓判据都用 `文件:行号` 定位(`grep -n`、编辑器跳转、`git show` 核对),
**报出来的行号必须能直接用**,否则读者第一步得先猜"这是剥过的还是没剥的"。
改成"块注释里的每个换行换成等量空行"。修完报的就是 **80 / 63**,与文件逐字对上。
## 三、新增两条判据,让这两个形状不能再回来
1. **`★ 判据不许把仓库根硬编码成绝对路径`** —— 扫判据目录里**真代码**
(`code()` 剥注释,否则本文件自己的说明文字就会误报),找
`const X = '/绝对路径'` 且**看着像仓库内**的声明。
**例外按名字放行**(含 `TOOLCHAIN`/`SDK`/`HDC` 的常量)—— 工具链本来就不在仓库里、推不出来;
按**值**做白名单会逼着下一个人为了过判据去改那个路径的写法。
2. **`★ stripComments 必须保持行号`** —— 造含多行块注释的样本,断言剥完
**行数不变**、且第 N 行仍是原来的第 N 行;**同时**断言注释内容确实被去掉了
(别为了保行号把注释留下)。
两条都做了**变异验证**:
- 把 `harmony-admin` 的 ROOT 改回硬编码 ⇒ 新判据**红**,并点名那个文件;还原后绿。
- 在 `MainPage.ets` **import 之前**插一条语句 ⇒ `harmony-arkts` **红**
(第 79 行 vs 第 1 行);还原后绿。**这条同时证明了"读的是自己那棵树"** ——
同样这个变异,在修路径**之前**是绿的。
## 四、未做 / 未验
- 到期闸门那 7 条**没动**(要真装真点,是另一件活)。
- **"把 build 做成一条判据"我探了,两个硬障碍**(详见给 pi 的回信):
① `client/harmony/oh_modules` 被 `.gitignore` 排除且未入库 ⇒ **全新检出没有它**,
构建会先死在装依赖上;② 本沙箱**拒写 `/root/.hvigor`**(`mkdir` Permission denied),
`hvigorw` 在 worktree 里直接 `EACCES: mkdir '/root/.hvigor/project_caches/…'`。
所以它在本仓能编过、在干净检出编不过 —— 作为判据它现在会**假红**。
160 lines
7.2 KiB
JavaScript
160 lines
7.2 KiB
JavaScript
/**
|
||
* ArkTS **编译期**硬规则的判据(本机可跑,不需要设备)。
|
||
*
|
||
* ── 这一整个文件的来历 ──
|
||
*
|
||
* `hvigorw assembleHap` 在 `f31bc02` / `7647c24` 上都红了一条:
|
||
*
|
||
* ERROR: ArkTS:ERROR File: …/MainPage.ets
|
||
* "import" statements after other statements are not allowed (arkts-no-misplaced-imports)
|
||
*
|
||
* 原因是**我**在 `MainPage.ets` 里把 `NAV_MATERIAL_OF` 那张(带注释的)常量表
|
||
* **插在了既有 import 之前** —— 而这个仓库里**没有一条判据会跑 ArkTS 的编译规则**:
|
||
* 我那一笔的判据判的是"表达式对不对/接没接上",它们全绿,因为**文本层面没问题**,
|
||
* 问题只有编译器知道。pi 是构建时撞上的。
|
||
*
|
||
* ⇒ 教训不是"下次小心",是**把编译器能抓、而判据不抓的那一类固化下来**。
|
||
* 一组 import 位置、解构、`any`、函数表达式这些**都不需要设备**、纯文本就能判,
|
||
* 所以它们**不该**待在"等设备才能验"的欠账里。
|
||
*
|
||
* ⚠️ 这个文件**不能**替代 `hvigorw`:它覆盖的是"能静态判出来的那几类"。
|
||
* ArkTS 还有大量只有编译器知道的事(类型推断、重载解析、Sendable…)——
|
||
* 那部分仍然只有 build 能验,不许把这个文件的存在读成"编译已经验过了"。
|
||
*/
|
||
import test from 'node:test';
|
||
import assert from 'node:assert/strict';
|
||
import { readdirSync } from 'node:fs';
|
||
import { dirname, join } from 'node:path';
|
||
import { fileURLToPath } from 'node:url';
|
||
import { code } from './lib/read.mjs';
|
||
|
||
// 与其它鸿蒙判据同口径(见 `harmony-admin.test.mjs` 的文件头)
|
||
/*
|
||
* ★ 仓库根必须**从本文件的位置推**,不许硬编码绝对路径。
|
||
*
|
||
* 原来这里写的是 `const ROOT = '/home/program/agentmail';` —— pi 2026-09-15 实测出后果:
|
||
* 把带违规的提交检出到**别的目录**再跑,判据**读的仍是 `/home/program/agentmail`**,
|
||
* 于是"在一个 import 顺序明显违规的检出上 3/3 全绿"。
|
||
* 两层后果,第二层最糟:
|
||
* ① 它**永远无法验证任何别的 checkout / CI / 镜像**(换目录不是"红",是 readdirSync 直接抛);
|
||
* ② 在本机做 worktree 复核时,它会**静默读另一棵树并报绿** —— 正是我们这几轮在消的形状,
|
||
* 这次长在判据自己身上。**"规则进来了,对象没进来"**。
|
||
* 修法照邻居(10 个鸿蒙判据都是 `join(HERE, '..', '..', '..')`)。
|
||
*/
|
||
const HERE = dirname(fileURLToPath(import.meta.url));
|
||
const ROOT = join(HERE, '..', '..', '..');
|
||
const ETS_ROOT = join(ROOT, 'client/harmony/entry/src/main/ets');
|
||
|
||
function allEts(dir = ETS_ROOT) {
|
||
const out = [];
|
||
for (const e of readdirSync(dir, { withFileTypes: true })) {
|
||
const p = join(dir, e.name);
|
||
if (e.isDirectory()) { out.push(...allEts(p)); continue; }
|
||
if (e.name.endsWith('.ets')) out.push(p);
|
||
}
|
||
return out;
|
||
}
|
||
|
||
const rel = (p) => p.slice(ETS_ROOT.length + 1);
|
||
|
||
/**
|
||
* 逐行扫"最后一个 import"与"第一个非 import 语句"的位置。
|
||
*
|
||
* 要注意 import 可能是**多行**的(`import {\n a,\n b\n} from '…';`),
|
||
* 所以不能只看以 `import` 开头的行 —— 多行块里的成员名会被误判成"语句"。
|
||
* (我第一版就这么误判过:把 `NAV_BAR_BOTTOM,` 当成了一条语句。)
|
||
*/
|
||
function importOrder(src) {
|
||
const lines = src.split('\n');
|
||
let lastImport = 0;
|
||
let firstOther = null;
|
||
let inBlock = false;
|
||
for (let i = 0; i < lines.length; i++) {
|
||
const ls = lines[i].trim();
|
||
if (!ls || ls.startsWith('//') || ls.startsWith('*') || ls.startsWith('/*') || ls.startsWith('*/')) continue;
|
||
if (ls.startsWith('import ')) {
|
||
lastImport = i + 1;
|
||
inBlock = !ls.replace(/\s+$/, '').endsWith(';');
|
||
continue;
|
||
}
|
||
if (inBlock) {
|
||
// import 块内:`} from '…';` 或成员行
|
||
if (ls.startsWith('}') || ls.endsWith(';')) { lastImport = i + 1; inBlock = false; }
|
||
continue;
|
||
}
|
||
if (firstOther === null) firstOther = { line: i + 1, text: ls.slice(0, 60) };
|
||
}
|
||
return { lastImport, firstOther };
|
||
}
|
||
|
||
test('★ ArkTS:所有 import 必须在任何其它语句之前(arkts-no-misplaced-imports)', () => {
|
||
/*
|
||
* 这条是**构建时撞出来的**(见文件头)。它判的是"文件级语句顺序",
|
||
* 与"import 写全没写全""路径对不对"是不同的事 —— 那些别处判。
|
||
*/
|
||
const bad = [];
|
||
for (const f of allEts()) {
|
||
const { lastImport, firstOther } = importOrder(code(f));
|
||
if (firstOther && firstOther.line < lastImport) {
|
||
bad.push(`${rel(f)}:最后一个 import 在第 ${lastImport} 行,`
|
||
+ `但第 ${firstOther.line} 行已是语句「${firstOther.text}」`);
|
||
}
|
||
}
|
||
assert.deepEqual(bad, [],
|
||
`★ 这些文件把 import 写在了其它语句**之后** —— ArkTS 编译器会直接报错,构建不过:\n ${bad.join('\n ')}\n` +
|
||
' 修法:把 import 全部挪到文件最前(常量表、类、函数都要在它们之后)。');
|
||
});
|
||
|
||
test('★ 判据自检:import 顺序检查必须能抓到"常量插在 import 之前"', () => {
|
||
/*
|
||
* 这条自检是**必须的**:上面那条今天全绿,而它绿的原因可能是"真的没问题",
|
||
* 也可能是"我的扫描逻辑失效了"(把整段当注释跳过、多行 import 判错…)。
|
||
* 造一个**已知坏样本**,确认它会被判红 —— 这正是这次事故的形状。
|
||
*/
|
||
const badSample = [
|
||
"import { a } from './a';",
|
||
'',
|
||
'const TABLE: Record<string, number> = {',
|
||
" 'x': 1",
|
||
'};',
|
||
'',
|
||
"import { b } from './b';",
|
||
'',
|
||
'export function use(): number { return TABLE.x + b; }'
|
||
].join('\n');
|
||
const r = importOrder(badSample);
|
||
assert.ok(r.firstOther && r.firstOther.line < r.lastImport,
|
||
'自检失败:检查逻辑抓不到"常量插在两组 import 之间"——那正是本次构建报错的形状');
|
||
// 反向:合法样本不许误报
|
||
const goodSample = [
|
||
"import { a } from './a';",
|
||
"import { b } from './b';",
|
||
'',
|
||
'const TABLE: Record<string, number> = {',
|
||
" 'x': 1",
|
||
'};'
|
||
].join('\n');
|
||
const g = importOrder(goodSample);
|
||
assert.ok(g.firstOther && g.firstOther.line > g.lastImport, '自检失败:合法样本被误报');
|
||
});
|
||
|
||
test('ArkTS 词汇层硬坑:全仓 .ets 不许出现解构 / any / unknown / 函数表达式', () => {
|
||
/*
|
||
* 这几条此前**只在我新写的那个页面里**判(`harmony-admin.test.mjs` ⑨),
|
||
* 也就是说"我自己新写的文件"有判据、"别的文件"没有 —— 而我恰恰是在
|
||
* **改既有文件**(`MainPage.ets`)时犯的下一个错。
|
||
* ⇒ 铺到全部 `.ets`:编译期硬规则不该按"谁写的"分覆盖。
|
||
*/
|
||
const bad = [];
|
||
for (const f of allEts()) {
|
||
const src = code(f);
|
||
const hits = [];
|
||
if (/const\s*\{[^}]*\}\s*=/.test(src) || /let\s*\{[^}]*\}\s*=/.test(src)) hits.push('对象解构');
|
||
if (/\bany\b/.test(src)) hits.push('any');
|
||
if (/\bunknown\b/.test(src)) hits.push('unknown');
|
||
if (/\bfunction\s*\(/.test(src)) hits.push('函数表达式');
|
||
if (hits.length) bad.push(`${rel(f)}:${hits.join('、')}`);
|
||
}
|
||
assert.deepEqual(bad, [], `★ ArkTS 硬坑(编译不过):\n ${bad.join('\n ')}`);
|
||
});
|