如果你说的是 Taro 3.x ,它解析 app.config.ts 和各页面 index.config.ts 的核心思路可以概括成:
先把 TS/JS 配置文件当作模块执行/编译 → 拿到导出的配置对象 → 再由 Taro 编译器把配置转换成各端需要的配置文件。
大致链路是:
src/app.config.ts
│
▼
Taro 编译入口
│
├── 解析 app.config.ts
│ └── 得到 appConfig
│
├── 扫描 pages
│ └── 找到 pages/home/index.tsx
│
├── 查找对应的 index.config.ts
│ └── 得到 pageConfig
│
▼
配置合并 / 标准化
│
▼
Taro 编译器
│
├── 微信小程序 → app.json / page.json
├── 百度小程序 → app.json / page.json
├── H5 → 路由/运行时配置
└── React Native → 对应运行时配置
1. app.config.ts 是怎么被识别的?
例如:
// src/app.config.ts
export default {
pages: [
'pages/index/index',
'pages/user/index'
],
window: {
navigationBarTitleText: 'Taro App'
}
}
Taro 启动编译时,会从项目入口开始寻找 App 配置。
在 Taro 3 中,通常入口是:
src/app.ts
src/app.tsx
而:
src/app.config.ts
是和 App 入口对应的配置文件。
Taro 会把它视为一个特殊的配置模块,而不是普通业务 TS 文件。
最终类似:
const appConfig = {
pages: [...],
window: {...}
}
然后根据当前编译端进行转换。
比如微信小程序:
app.config.ts
↓
Taro 配置解析
↓
appConfig
↓
微信端编译器
↓
dist/app.json
2. 页面配置是怎么找到的?
假设:
src/
├── app.tsx
├── app.config.ts
└── pages/
├── index/
│ ├── index.tsx
│ └── index.config.ts
│
└── user/
├── index.tsx
└── index.config.ts
页面:
// pages/index/index.tsx
export default function Index() {
return <View>Hello</View>
}
对应配置:
// pages/index/index.config.ts
export default {
navigationBarTitleText: '首页',
enablePullDownRefresh: true
}
Taro 在处理:
app.config.ts
的时候发现:
pages: [
'pages/index/index',
'pages/user/index'
]
于是它会继续解析这些页面。
对于:
pages/index/index
Taro 会关联到:
pages/index/index.tsx
pages/index/index.config.ts
也就是说,页面配置不是通过 import 显式引入的:
// ❌ 一般不是这种模式
import config from './index.config'
而是 Taro 根据页面入口的约定自动关联:
index.tsx
↕
index.config.ts
3. Taro 真正关键的是「配置 AST」
这里是理解 Taro 的重点。
Taro 并不是简单地:
require('./app.config.ts')
然后完事。
因为 Taro 需要处理:
export default {
pages: [
'pages/index/index'
],
window: {
navigationBarTitleText: 'xxx'
}
}
甚至:
const title = '首页'
export default {
pages: ['pages/index/index'],
window: {
navigationBarTitleText: title
}
}
所以 Taro 的编译体系会对配置文件进行 编译/解析。
从架构上可以理解成:
app.config.ts
│
▼
TypeScript / Babel AST
│
▼
配置提取
│
▼
TaroConfig
│
▼
Normalize
│
▼
Platform Config
这里的 AST 非常重要。
因为 Taro 不只是需要"执行结果",还需要知道:
pages
window
tabBar
subpackages
preloadRule
usingComponents
这些字段分别是什么。
4. 为什么 Taro 要解析 AST?
例如:
export default {
pages: [
'pages/index/index',
'pages/user/index'
]
}
如果单纯执行 JS:
const config = require('./app.config')
当然也可以拿到对象。
但 Taro 编译器还需要做很多静态工作:
pages
↓
扫描页面
↓
建立依赖关系
↓
创建页面编译任务
↓
生成对应目录
↓
生成 app.json
所以它需要把:
pages: [...]
当成 编译期元数据。
5. 页面配置最终怎么进入 page.json?
例如:
// pages/index/index.config.ts
export default {
navigationBarTitleText: '首页',
enablePullDownRefresh: true
}
最终微信小程序可能得到:
{
"navigationBarTitleText": "首页",
"enablePullDownRefresh": true
}
也就是:
index.config.ts
↓
Taro config parser
↓
pageConfig
↓
platform transform
↓
page.json
6. App 配置和 Page 配置其实走的是同一套体系
可以把它们理解成:
Taro Config
│
┌──────────┴──────────┐
│ │
App Config Page Config
│ │
app.config.ts index.config.ts
│ │
▼ ▼
app.json page.json
区别主要在于:
App Config
负责整个应用:
{
pages,
window,
tabBar,
subpackages,
permission,
...
}
Page Config
负责单个页面:
{
navigationBarTitleText,
enablePullDownRefresh,
backgroundColor,
usingComponents,
...
}
7. 如果你想看 Taro 源码,重点追这几层
如果你是在研究 Taro 源码实现 ,不要一上来从 app.config.ts 搜。
建议按照这条链路追:
@tarojs/cli
↓
编译入口
↓
@tarojs/service
↓
编译流程
↓
配置解析
↓
页面扫描
↓
各端 compiler
尤其关注这些概念:
app.config
config parser
page config
appConfig
pages
entry
compiler
generator
不同 Taro 版本源码目录会有差异,但整体架构基本就是:
CLI
│
├── 项目初始化 / 参数处理
│
└── Service
│
├── 读取 app.config
├── 创建编译上下文
├── 分析 pages
├── 分析 page.config
│
└── Platform
├── weapp
├── h5
├── alipay
└── ...
如果你现在是在读 Taro 源码,我可以继续给你按 Taro 3.x 源码,把 app.config.ts → appConfig → pages → index.config.ts → page.json 这条调用链具体追到函数级别,包括每一步在哪个 package、哪个文件、哪个函数完成。