编译报错根因分析：react-next-admin vs common

现象

同一份源码 src/common/lib/table/DataTableProperty.ts，在 react-next-admin 项目里 next build 报两条错误，而在 common 项目里却编译正常：

6:17   Error: 'PagerResult' is defined but never used.  @typescript-eslint/no-unused-vars
33:14  Error: The `{}` ("empty object") type allows any non-nullish value...

根因总结

关键点：两个项目里的这份文件是同一份源码，差异不在代码，而在各自的 ESLint 配置。

react-next-admin/package.json 里有一个拷贝脚本，把 common 的共享目录同步进本项目：

"copy": "cpy ./../common/src/common ./src/ --parents"

所以 react-next-admin/src/common 是从 common/src/common 拷贝来的，代码完全一致。报错差异源于两个项目用了不同的 ESLint 预设：

项目	eslint.config.mjs extends	是否启用 TS 严格规则
react-next-admin	next/core-web-vitals + next/typescript	是
common	next	否

其中 next/typescript 展开后就是 plugin:@typescript-eslint/recommended，它打开了两条规则，正好对应两条报错：

1. @typescript-eslint/no-unused-vars → PagerResult 被 import 却未使用
2. @typescript-eslint/ban-types → parent?: {} 里的空对象类型 {}

而 common 只 extends next，没有 next/typescript，这两条规则根本没开启，自然不报错。

与编译的关系

这两条报错是 ESLint 规则错误，不是 TypeScript（tsc）类型错误。

next build 在构建阶段会先运行 ESLint；当规则级别为 error 时，lint 失败会直接中断构建，所以对外表现为「编译报错」。也就是说：

• TypeScript 类型系统本身并不认为这两个地方有错（{} 是合法类型，未使用的命名 import 也不影响类型检查）；
• 是 ESLint 的静态检查把问题抬到了 error 级别，进而卡住了 next build。

修复建议

• 根治源码（推荐）：删除未使用的 PagerResult import；把 parent?: {} 改为 parent?: object（或更具体的类型）。
• 统一配置：让两个项目的 ESLint 预设一致——要么都 extends next/typescript 并修源码，要么都在 common 侧显式关闭这两条规则。

注意：react-next-admin/src/common 是拷贝产物，直接改它会在下次 npm run copy 时被覆盖；正确的修改位置是 common/src/common（源头），改完再执行 copy 同步。