feat(harmony): support async context #18876
Conversation
Walkthrough将多个 Vite/Rollup 插件钩子（如 buildStart、buildEnd、transform）和工具函数 Changes
Sequence Diagram(s)sequenceDiagram
participant Plugin as Vite Plugin Hook
participant Utils as runner-utils.getViteHarmonyCompilerContext()
participant Module as Vite/Rollup ModuleStore
Plugin->>Utils: await getViteHarmonyCompilerContext(this)
Utils->>Module: (prod) getModuleInfo(VITE_COMPILER_LABEL)\n(dev) load({ id: VITE_COMPILER_LABEL })
Module-->>Utils: module info (包含 meta.viteCompilerContext)
Utils-->>Plugin: 返回 viteCompilerContext
Plugin->>Plugin: 根据 viteCompilerContext 初始化 loaderMeta / 继续构建逻辑
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
ZakaryCode
added
A-loader
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@packages/taro-platform-harmony-cpp/src/program/vite/page.ts`:
- Around line 53-56: The code uses a non-null assertion on the result of
getViteHarmonyCompilerContext which can be undefined and causes a runtime crash
when accessing compiler.taroConfig; change the flow to await
getViteHarmonyCompilerContext into a possibly-undefined compiler and guard
accesses with if (compiler) (or if (compiler && (compiler.pages instanceof Array
|| compiler.components instanceof Array))) before reading compiler.taroConfig or
other properties to match the pattern used elsewhere (e.g., in app.ts,
render.ts, vue3/vite.harmony.ts).
🧹 Nitpick comments (1)
packages/taro-platform-harmony-cpp/src/program/vite/style.ts (1)
73-79:buildEnd缺少this: PluginContext类型注解。
buildStart（第 34 行）显式声明了this: PluginContext，但buildEnd没有。虽然运行时 Rollup 会正确绑定this，但为了类型安全和一致性，建议补上。建议补充类型注解
- async buildEnd() { + async buildEnd(this: PluginContext) {
| const compiler = (await getViteHarmonyCompilerContext(pluginContext))! | ||
| const taroConfig = compiler.taroConfig | ||
|
|
||
| if (compiler?.pages instanceof Array || compiler?.components instanceof Array) { |
There was a problem hiding this comment.
非空断言 ! 存在运行时崩溃风险。
getViteHarmonyCompilerContext 的返回类型为 Promise<ViteHarmonyCompilerContext | void>，若返回 undefined，第 54 行 compiler.taroConfig 将抛出 TypeError。其他所有调用点（如 app.ts、render.ts、vue3/vite.harmony.ts 等）均使用 if (compiler) 守卫，建议此处保持一致。
建议修复
- const compiler = (await getViteHarmonyCompilerContext(pluginContext))!
- const taroConfig = compiler.taroConfig
-
- if (compiler?.pages instanceof Array || compiler?.components instanceof Array) {
+ const compiler = await getViteHarmonyCompilerContext(pluginContext)
+ if (!compiler) return
+ const taroConfig = compiler.taroConfig
+
+ if (compiler.pages instanceof Array || compiler.components instanceof Array) {📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const compiler = (await getViteHarmonyCompilerContext(pluginContext))! | |
| const taroConfig = compiler.taroConfig | |
| if (compiler?.pages instanceof Array || compiler?.components instanceof Array) { | |
| const compiler = await getViteHarmonyCompilerContext(pluginContext) | |
| if (!compiler) return | |
| const taroConfig = compiler.taroConfig | |
| if (compiler.pages instanceof Array || compiler.components instanceof Array) { |
🤖 Prompt for AI Agents
In `@packages/taro-platform-harmony-cpp/src/program/vite/page.ts` around lines 53
- 56, The code uses a non-null assertion on the result of
getViteHarmonyCompilerContext which can be undefined and causes a runtime crash
when accessing compiler.taroConfig; change the flow to await
getViteHarmonyCompilerContext into a possibly-undefined compiler and guard
accesses with if (compiler) (or if (compiler && (compiler.pages instanceof Array
|| compiler.components instanceof Array))) before reading compiler.taroConfig or
other properties to match the pattern used elsewhere (e.g., in app.ts,
render.ts, vue3/vite.harmony.ts).
Codecov Report✅ All modified and coverable lines are covered by tests. ❌ Your project check has failed because the head coverage (52.66%) is below the target coverage (75.00%). You can increase the head coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## main #18876 +/- ##
==========================================
- Coverage 56.31% 52.66% -3.65%
==========================================
Files 447 252 -195
Lines 23352 11682 -11670
Branches 5776 2756 -3020
==========================================
- Hits 13150 6152 -6998
+ Misses 8372 4563 -3809
+ Partials 1830 967 -863
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
2 similar comments
Codecov Report✅ All modified and coverable lines are covered by tests. ❌ Your project check has failed because the head coverage (52.66%) is below the target coverage (75.00%). You can increase the head coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## main #18876 +/- ##
==========================================
- Coverage 56.31% 52.66% -3.65%
==========================================
Files 447 252 -195
Lines 23352 11682 -11670
Branches 5776 2756 -3020
==========================================
- Hits 13150 6152 -6998
+ Misses 8372 4563 -3809
+ Partials 1830 967 -863
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
Codecov Report✅ All modified and coverable lines are covered by tests. ❌ Your project check has failed because the head coverage (52.66%) is below the target coverage (75.00%). You can increase the head coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## main #18876 +/- ##
==========================================
- Coverage 56.31% 52.66% -3.65%
==========================================
Files 447 252 -195
Lines 23352 11682 -11670
Branches 5776 2756 -3020
==========================================
- Hits 13150 6152 -6998
+ Misses 8372 4563 -3809
+ Partials 1830 967 -863
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #18876 +/- ##
=======================================
Coverage 56.31% 56.31%
=======================================
Files 447 447
Lines 23352 23352
Branches 5776 5794 +18
=======================================
Hits 13150 13150
+ Misses 8372 8371 -1
- Partials 1830 1831 +1
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
ZakaryCode
force-pushed
the
feat/harmony-watch
branch
from
f0c4b47 to
97c6ab6
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@packages/taro-vite-runner/src/harmony/pipeline.ts`:
- Around line 14-19: In buildStart, the production branch currently drops the
Promise from this.load so getModuleInfo(VITE_COMPILER_LABEL) may see null;
change the ternary so the production path uses await this.load({ id:
VITE_COMPILER_LABEL }) and the non-production/watch path calls this.load({ id:
VITE_COMPILER_LABEL }) without awaiting, ensuring
this.getModuleInfo(VITE_COMPILER_LABEL) runs only after the module is loaded in
production; update the ternary in the buildStart method accordingly.
| async buildStart () { | ||
| const isProd = getMode(taroConfig) === 'production' | ||
| isProd | ||
| ? this.load({ id: VITE_COMPILER_LABEL }) | ||
| : await this.load({ id: VITE_COMPILER_LABEL }) | ||
| const info = this.getModuleInfo(VITE_COMPILER_LABEL) |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n packages/taro-vite-runner/src/harmony/pipeline.ts | head -40Repository: NervJS/taro
Length of output: 1520
🏁 Script executed:
# Search for other buildStart implementations in harmony-related files
rg -n "buildStart" --type=ts -C 5 packages/taro-vite-runner/src/harmony/ packages/taro-platform-harmony-cpp/Repository: NervJS/taro
Length of output: 12792
🏁 Script executed:
# Check if there are related harmony plugin files
fd -e ts -g '*harmony*' packages/ | head -20Repository: NervJS/taro
Length of output: 1238
生产模式下 this.load() 的 Promise 被丢弃，getModuleInfo() 无法获取正确的模块信息。
当前代码在 lines 16-18 的三元表达式将 await 放在了错误的分支：
- 生产模式（
isProd = true）：this.load()不 await → Promise 被丢弃 - 非生产模式（
isProd = false）：await this.load()→ 等待加载完成
但 line 19 的 this.getModuleInfo(VITE_COMPILER_LABEL) 依赖模块已加载。在生产模式下不 await，该方法可能返回 null，导致 line 20-23 的后续操作被跳过（模块元信息设置和配置文件监听失效）。
整个 harmony 生态中其他 async buildStart 方法都正确地 await 其异步操作（如 taro-platform-harmony-cpp/src/program/vite/ 下的 app.ts、render.ts、page.ts 等），这里应该保持一致。
三元分支应交换：生产模式同步等待加载完成，开发/watch 模式可以不阻塞。
建议修复：交换三元分支
async buildStart () {
const isProd = getMode(taroConfig) === 'production'
- isProd
- ? this.load({ id: VITE_COMPILER_LABEL })
- : await this.load({ id: VITE_COMPILER_LABEL })
+ isProd
+ ? await this.load({ id: VITE_COMPILER_LABEL })
+ : this.load({ id: VITE_COMPILER_LABEL })
const info = this.getModuleInfo(VITE_COMPILER_LABEL)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| async buildStart () { | |
| const isProd = getMode(taroConfig) === 'production' | |
| isProd | |
| ? this.load({ id: VITE_COMPILER_LABEL }) | |
| : await this.load({ id: VITE_COMPILER_LABEL }) | |
| const info = this.getModuleInfo(VITE_COMPILER_LABEL) | |
| async buildStart () { | |
| const isProd = getMode(taroConfig) === 'production' | |
| isProd | |
| ? await this.load({ id: VITE_COMPILER_LABEL }) | |
| : this.load({ id: VITE_COMPILER_LABEL }) | |
| const info = this.getModuleInfo(VITE_COMPILER_LABEL) |
🤖 Prompt for AI Agents
In `@packages/taro-vite-runner/src/harmony/pipeline.ts` around lines 14 - 19, In
buildStart, the production branch currently drops the Promise from this.load so
getModuleInfo(VITE_COMPILER_LABEL) may see null; change the ternary so the
production path uses await this.load({ id: VITE_COMPILER_LABEL }) and the
non-production/watch path calls this.load({ id: VITE_COMPILER_LABEL }) without
awaiting, ensuring this.getModuleInfo(VITE_COMPILER_LABEL) runs only after the
module is loaded in production; update the ternary in the buildStart method
accordingly.
2 participants
这个 PR 做了什么？ (简要描述所做更改)
支持 harmony context 的 async 使用
这个 PR 是什么类型？ (至少选择一个)
这个 PR 涉及以下平台：
Summary by CodeRabbit
发布说明