chore: 类型文件中增加 jsdoc #3073
chore: 类型文件中增加 jsdoc #3073
Conversation
Walkthrough本次PR涉及多个模块的调整。主要在脚本中重构组件文档处理逻辑，包括将 Changes
Sequence Diagram(s)sequenceDiagram
participant U as 用户/脚本执行者
participant BC as build-comments-to-dts 脚本
participant Doc as 文档生成模块
U->>BC: 执行脚本
BC->>BC: 调用 codeShift(platform)
alt 环境变量 PROPS_JSON 为 true
BC->>BC: 读取文档 → 生成 props.json
else 环境变量 PROPS_JSON 未设置
BC->>BC: 提取组件文档
BC->>BC: 调用 addJSDoc(propsJson, componentName, platform)
BC->>Doc: 添加 JSDoc 注释
end
Possibly related PRs
Suggested reviewers
Poem
Warning There were issues while running some tools. Please review the errors and either fix the tool’s configuration or disable the tool if it’s a critical failure. 🔧 ESLint
ERR_PNPM_OPTIONAL_DEPS_REQUIRE_PROD_DEPS Optional dependencies cannot be installed without production dependencies 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
⏰ Context from checks skipped due to timeout of 90000ms (1)
🔇 Additional comments (8)
✨ Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
github-actions
bot
added
3.x
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## feat_v3.x #3073 +/- ##
==========================================
Coverage 86.10% 86.10%
==========================================
Files 277 277
Lines 18408 18408
Branches 2807 2807
==========================================
Hits 15851 15851
Misses 2552 2552
Partials 5 5 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (6)
src/types/spec/pickerview/base.ts (1)
9-18: BasePickerView 接口定义接口定义清晰完整，包含了 PickerView 组件所需的所有属性。建议为每个属性添加 JSDoc 注释，以便开发者更好地理解每个属性的用途和预期行为。
可以这样添加 JSDoc 注释：
export interface BasePickerView extends BaseProps { + /** + * 设置组件引用的回调函数 + * @param ref 组件引用 + */ setRefs?: (ref: any) => any + /** + * 选择器选项列表 + */ options: PickerOptions[] + /** + * 当前选中值 + */ value?: PickerValue[] + /** + * 默认选中值 + */ defaultValue?: PickerValue[] + /** + * 是否开启3D效果 + */ threeDimensional?: boolean + /** + * 滚动动画时长 + */ duration?: number | string + /** + * 自定义渲染选项标签的函数 + * @param item 选项数据 + */ renderLabel: (item: PickerOption) => React.ReactNode + /** + * 选项改变时的回调函数 + * @param arg0 回调参数 + */ onChange?: (arg0: PickerOnChangeCallbackParameter) => void }scripts/build.mjs (1)
446-449: 为codeShift('h5')添加错误处理逻辑当前在构建 JSDoc 时未捕获可能的异常，若
codeShift出现意外错误，脚本会继续执行，从而导致潜在的编译或文档异常。建议在调用处加入 try/catch 以增强健壮性。以下示例演示如何在同一段中进行简单错误处理：
console.time('Build JSDoc') - codeShift('h5') + try { + codeShift('h5') + } catch (err) { + console.error('[Build JSDoc] 发生错误: ', err) + process.exit(1) + } console.timeEnd('Build JSDoc')scripts/build-comments-to-dts.mjs (4)
5-5: 关于重复引入 path已额外导入
{ dirname }，但文件后续又多次使用dirname(__filename)。可将相关逻辑合并至单处管理，避免后续维护存在多处重复。
20-20: reduce 回调写法可读性此处通过
reduce收集组件信息，逻辑清晰但略显复杂。可考虑使用更直观的迭代方式（如flatMap或普通循环）提升可读性。
125-131: 变量命名与对象简写建议内部
[key, desc, types, defaultValue]中的变量名key与上一层键值同名，易产生混淆。可简要修订以提升可读性，并使用对象属性简写：如下示例：
- componentsProps[key.toLowerCase()] = table.reduce((acc, [key, desc, types, defaultValue]) => { - acc[key] = { - desc: desc, - types: types, - defaultValue: defaultValue, - } + componentsProps[key.toLowerCase()] = table.reduce((acc, [propName, desc, types, defaultValue]) => { + acc[propName] = { desc, types, defaultValue }
140-141: 保留注释的冗余代码此处写入
props.json的逻辑已被注释，若后续需要落地多份元数据，可酌情恢复或抽离为可选步骤，避免注释长期遗留。
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (19)
scripts/build-comments-to-dts.mjs(4 hunks)scripts/build-taro.mjs(0 hunks)scripts/build.mjs(0 hunks)src/config.json(1 hunks)src/packages/datepickerview/doc.en-US.md(1 hunks)src/packages/datepickerview/doc.md(1 hunks)src/packages/datepickerview/doc.taro.md(1 hunks)src/packages/datepickerview/doc.zh-TW.md(1 hunks)src/types/index.ts(1 hunks)src/types/spec/picker/base.ts(0 hunks)src/types/spec/picker/h5.ts(1 hunks)src/types/spec/picker/taro.ts(1 hunks)src/types/spec/pickerview/base.ts(1 hunks)src/types/spec/pickerview/h5.ts(1 hunks)src/types/spec/pickerview/taro.ts(1 hunks)package.json(1 hunks)scripts/build-comments-to-dts.mjs(6 hunks)scripts/build-taro.mjs(2 hunks)scripts/build.mjs(1 hunks)
💤 Files with no reviewable changes (1)
- src/types/spec/picker/base.ts
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: test
🔇 Additional comments (27)
src/types/spec/pickerview/h5.ts (1)
1-3: 新增 WebPickerViewProps 接口，代码结构合理这是一个新创建的文件，引入了 BasePickerView 接口并扩展为 WebPickerViewProps。从代码结构看，这是对 PickerView 组件类型进行的重构，将原来在 picker 目录下的代码移动到专门的 pickerview 目录中，使类型定义更加清晰和组织化。
src/types/spec/pickerview/taro.ts (1)
1-3: 新增 TaroPickerViewProps 接口，保持了与 H5 版本的一致性这个新文件创建了 TaroPickerViewProps 接口，与 WebPickerViewProps 相对应，共同维护了多平台类型定义的一致性。这种结构调整使得 PickerView 相关的类型定义更加独立和清晰，便于维护和理解。
src/types/spec/picker/h5.ts (1)
1-1: 移除了对 BasePickerView 的引用，保持代码整洁此处移除了对 BasePickerView 的引用，与项目整体重构方向一致，将 PickerView 相关类型移至新的目录结构中，使 picker 目录专注于 Picker 组件本身的类型定义。
src/types/spec/picker/taro.ts (1)
1-1: 合理调整导入，移除不再需要的 BasePickerView此处移除了对 BasePickerView 的引用，与 H5 版本保持一致，符合当前重构的整体思路。这种修改使代码结构更清晰，同时为 PickerView 相关类型在新目录中的独立管理铺平了道路。
src/types/index.ts (1)
161-163: 新增 PickerView 类型导出这些导出语句为 PickerView 组件添加了基础、H5 和 Taro 平台的类型定义。这是一个良好的结构化改进，使组件类型更加清晰和有组织。
src/types/spec/pickerview/base.ts (1)
1-8: 导入基础类型定义正确导入了所需的类型定义，包括从
../picker/base导入的 PickerOption 相关类型，使 PickerView 可以复用已有类型定义。src/packages/datepickerview/doc.taro.md (1)
31-48: 修改：更新组件标题为 DatePickerView
该文档中新增的 “## DatePickerView” 标题使组件名称与实际使用保持一致，确保各文档版本间名称一致，提升用户识别。src/packages/datepickerview/doc.zh-TW.md (1)
31-48: 修改：更新標題一致性
將文檔中的標題由原來的 “DatePicker” 修改為 “DatePickerView”，以確保與其他語言版本保持一致，改善文檔準確性。src/packages/datepickerview/doc.md (1)
31-48: 更新：组件名称正确反映为 DatePickerView
通过将文档中对应部分的标题更新为 “DatePickerView”，文档更准确地描述了该组件，统一了各版本文档的命名。src/packages/datepickerview/doc.en-US.md (2)
27-44: 修改：更新子标题为 DatePickerView
该部分标题更新为 “DatePickerView” 后，能更准确地反映实际组件名称，确保与其他语言版本文档的一致性。
1-1: 疑问：顶级标题不一致
文档首行仍显示 “# DatePicker”，建议统一修改为 “# DatePickerView”，以避免可能导致的混淆。package.json (1)
85-85: 新增脚本命令
在 package.json 中新增的"generate:props_json": "PROPS_JSON=true node scripts/build-comments-to-dts.mjs"命令已正确定义，请确保相应构建脚本内部对platform参数及PROPS_JSON环境变量的处理也已同步更新。src/config.json (1)
397-397: 新增exportEmpty属性的合理性此属性允许组件在“空导出”情况下依然被导出，便于在编译或构建时保持兼容性。整体实现无明显风险，若与后续逻辑（如
addJSDoc函数）配合使用，请确保条件判断一致。scripts/build-comments-to-dts.mjs (14)
22-22: 仅排除exclude条件原先疑似有对 version 等其他条件的限制，如今仅保留
exclude判断。若后续需要按版本排除组件，建议在此基础上再行扩展。
108-108:codeShift默认env = ''在未传参时使用默认空字符串，应确保上层调用场景清楚此逻辑，避免漏传导致错误的文档生成流程。
110-110: 初始化componentsProps此对象用于收集所有组件的 Props 数据，设计合理，不存在明显问题。
117-117: 文档路径判断
env === 'taro' ? 'doc.taro.md' : 'doc.md'简洁易理解，适配跨平台文档，无明显问题。
121-121: 直接调用readComponentDocument通过封装函数读取文档，逻辑保持一致且更具可读性，整体实现无疑义。
124-124: 调用markdownTable2Json使用专门函数解析表格令逻辑简洁明了，后期若需扩展也可在此基础上进行。
137-137: 对exportEmpty的条件判断此段逻辑在组件未设置
exportEmpty时才会执行addJSDoc，请确认如果组件实际需要空导出却又想保留注释，是否仍符合预期。
144-144: 新增addJSDoc函数该函数模块化地为组件插入 JSDoc 注释，思路清晰。后续若需要支持更多字段或接口检查，可在此处集中扩展。
145-146:transform函数内聚性在本地函数中使用
jscodeshift完成对 AST 的查找与替换，将逻辑集中在一处，易于维护。
147-165: AST 遍历与注释注入通过查找
TSInterfaceDeclaration并注入注释，匹配指定命名Base${componentName}后再逐个属性填充注释，减少重复工作量。建议在找不到对应接口的场景下（如某组件并无Base接口）输出警告，避免后续报错。
167-167: 硬编码的base.ts路径此处假定组件一定在
spec/<componentName>/base.ts下，如组件未拆分或命名有差异，可能导致找不到文件的错误。可以考虑在配置中维护更灵活的路径定义。
169-169: 校验transform返回值
transform若未找到匹配的 AST 结构，返回值可能为空或非预期格式，建议先行检查或在加注释阶段增加保护性判断。
173-173: 再次调用codeShift()脚本尾部又调用一次
codeShift()，将使用默认空字符串env=''。需确定不会与先前调用互相覆盖或产生重复输出。
174-174: 写入baseType文件此步骤会覆盖
base.ts中原有类型声明，如尚未在编译链路中明确生成该文件，或需叠加现有声明，需谨慎处理写入逻辑。
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
scripts/build-comments-to-dts.mjs (1)
191-191: 增加了直接运行脚本的功能新增的代码允许在设置了
PROPS_JSON环境变量时直接运行脚本，方便开发。建议考虑使用命令行参数解析器来处理这种情况，这样会更加明确和灵活。
- PROPS_JSON && codeShift('h5') + // 使用命令行参数解析器来处理直接运行的情况 + if (process.argv[1] === fileURLToPath(import.meta.url)) { + const platform = process.argv[2] || 'h5' + PROPS_JSON ? codeShift(platform) : console.log('使用 PROPS_JSON=true 环境变量运行此脚本以生成 props.json') + }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
scripts/build-comments-to-dts.mjs(3 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: build
- GitHub Check: test
🔇 Additional comments (7)
scripts/build-comments-to-dts.mjs (7)
2-3: JSDoc 注释已更新，清晰地描述了脚本的双重用途文档注释现在明确说明了这个脚本可以通过两种方式使用：通过其他脚本导入 codeShift 方法来添加 JSDoc，或者通过 npm scripts 触发生成 props.json 文件。这是一个很好的改进，使脚本的用途更加明确。
15-15: 新增环境变量 PROPS_JSON 用于控制脚本行为添加了环境变量
PROPS_JSON来决定是生成 JSON 文件还是直接添加 JSDoc 注释。这是一个好的做法，增加了脚本的灵活性。
57-57: 改进了 Props 标题的识别方式将
sources[index + 1].content == 'Props'更改为sources[index + 1].content.toLowerCase() == 'props'，使检查不区分大小写。这是一个很好的改进，增强了代码的健壮性。
128-135: 改进了属性提取和存储方式新的实现方式通过构建
componentsProps对象来存储从文档中提取的属性，比之前直接添加 JSDoc 注释的方法更加清晰和可维护。这种结构化的数据更容易处理和复用。
140-147: 增加了基于环境变量的条件逻辑根据
PROPS_JSON环境变量的值，决定是添加 JSDoc 注释还是生成 JSON 文件。这种设计使脚本更加灵活，可以适应不同的使用场景。
150-189: 重写了 addJSDoc 函数，支持多种声明类型新的
addJSDoc函数更加模块化，可以处理类型别名声明和接口声明，增强了功能。函数现在接受一个额外的platform参数，使其能够适应不同平台的需求。函数使用 jscodeshift 来解析 TypeScript 文件并添加 JSDoc 注释，这是一个更加结构化和可靠的方法。
24-24:✅ Verification successful
属性名称从 excludeInDocs 更改为 exclude
将
pkg.excludeInDocs更改为pkg.exclude。需要确认这项修改在整个代码库中是否一致，以避免功能受到影响。
🏁 Script executed:
#!/bin/bash # 检查 config.json 文件中是否使用了 exclude 而不是 excludeInDocs cat ../src/config.json | grep -E "exclude|excludeInDocs"Length of output: 109
验证提示：
之前验证脚本尝试检查 "../src/config.json" 时未找到预期文件，为确保属性更名在整个代码库中保持一致，请执行上述脚本。如果该脚本没有返回任何结果，则说明所有旧引用已被替换。如果仍有输出，则需要处理相关引用，确保功能正确。
🏁 Script executed:
#!/bin/bash # 请在整个代码库中搜索对 pkg.excludeInDocs 的引用， # 以确认所有相关地方都已将旧属性名称替换为 pkg.exclude。 rg -n "pkg\.excludeInDocs" .Length of output: 152
确认属性名称替换一致性
- 脚本文件
scripts/build-comments-to-dts.mjs第24行的if (pkg.exclude) {已正确反映了属性替换。- 使用
rg -n "pkg\.excludeInDocs" .搜索整个代码库未发现旧属性pkg.excludeInDocs的引用。请开发者再次确认整个代码库中未遗漏旧属性使用，确认该更改不会引起其他功能问题。
scripts/build-comments-to-dts.mjs
Outdated
| components.forEach((component) => { | ||
| const { name } = component | ||
| if(name.toLowerCase() !== 'actionsheet') return |
There was a problem hiding this comment.
警告：可能的调试代码被提交
这行代码限制脚本只处理名称为 'actionsheet'（不区分大小写）的组件。这看起来像是一个调试行，可能不应该出现在生产代码中。
- if(name.toLowerCase() !== 'actionsheet') return
+ // 移除调试代码，允许处理所有组件📝 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.
| if(name.toLowerCase() !== 'actionsheet') return | |
| // 移除调试代码，允许处理所有组件 |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
scripts/build-comments-to-dts.mjs (1)
190-190: 仅为 H5 平台生成 props.json当前实现在
PROPS_JSON为 true 时只为 h5 平台调用codeShift。如果需要生成包含所有平台组件属性的完整 JSON，可能需要考虑添加对其他平台（如 Taro）的处理。建议修改为处理所有平台：
- PROPS_JSON && codeShift('h5') + if (PROPS_JSON) { + codeShift('h5') + codeShift('taro') + }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
scripts/build-comments-to-dts.mjs(3 hunks)
🧰 Additional context used
🪛 GitHub Actions: CI
scripts/build-comments-to-dts.mjs
[error] 166-166: TypeError: Cannot read properties of undefined (reading 'forEach')
🔇 Additional comments (9)
scripts/build-comments-to-dts.mjs (9)
2-3: 文件描述更新清晰反映了脚本功能脚本的描述现在明确说明了可以通过两种方式使用：通过导入
codeShift方法向组件类型文件增加 JSDoc，或通过 npm scripts 生成 props.json 文件。这样的描述有助于其他开发者理解脚本的用途。
15-15: 使用环境变量控制行为是一个好的做法使用环境变量
PROPS_JSON来控制脚本的行为模式是一个灵活的设计，这样可以在不修改代码的情况下改变脚本的功能。
22-24: 组件筛选逻辑简化代码简化了组件筛选逻辑，仅检查
exclude属性而不再检查版本。这样的简化使代码更清晰，但请确保这不会影响到需要版本检查的场景。
57-57: Props 标题检查改为不区分大小写将 Props 标题检查修改为不区分大小写（
toLowerCase()）是一个好的改进，增加了代码的兼容性，可以处理文档中可能出现的 "props"、"Props" 等不同写法。
110-110: 函数参数名称更改更符合实际用途将
codeShift函数的参数从env改为platform更准确地反映了参数的实际用途，提高了代码的可读性和可维护性。
119-119: 平台相关文档路径构建逻辑清晰根据
platform参数选择doc.taro.md或doc.md的逻辑非常清晰，有助于支持多平台文档。
126-134: 结构化数据处理逻辑改进重构后的表格数据处理逻辑更加结构化，将表格的每一行转换为更易于访问的对象结构。这样的改进使数据在后续处理中更容易访问和操作。
139-141: 条件执行 JSDoc 添加逻辑根据
PROPS_JSON环境变量决定是否执行addJSDoc函数的逻辑很合理，避免了在生成 JSON 文件模式下不必要的操作。另外，代码还考虑了component.exportEmpty属性，增加了更多的灵活性。
143-146: JSON 文件生成逻辑清晰当
PROPS_JSON为 true 时，将组件属性数据写入 JSON 文件的逻辑简洁明了。使用JSON.stringify时添加了格式化参数，生成的 JSON 文件更易于阅读。
scripts/build-comments-to-dts.mjs
Outdated
| function addJSDoc(propsJson, componentName, platform) { | ||
| const transform = (file, api) => { | ||
| const j = api.jscodeshift.withParser('ts') | ||
| const ast = j(file.source) | ||
| function addComment(item) { | ||
| if (!item.key) return | ||
| const description = propsJson[componentName.toLowerCase()][item.key.name] | ||
| if (!description) return | ||
| item['comments'] = [ | ||
| j.commentBlock(`*\n* ${description['desc']}\n`), | ||
| ] | ||
| } | ||
| ast | ||
| .find(j.TSTypeAliasDeclaration).forEach((path) => { | ||
| const annotationTypes = path.value.typeAnnotation.types | ||
| if (!annotationTypes) return | ||
| const typeLiteral = annotationTypes[annotationTypes.length - 1] | ||
| typeLiteral.members.forEach((item) => { | ||
| addComment(item) | ||
| }) | ||
| }) | ||
| ast.find(j.TSInterfaceDeclaration, { | ||
| id: { | ||
| name: `Base${componentName}`, | ||
| type: 'Identifier', | ||
| }, | ||
| }) | ||
| .forEach((path) => { | ||
| path.value?.body?.body?.forEach((item) => { | ||
| addComment(item) | ||
| }) | ||
| }) | ||
|
|
||
| return ast.toSource() | ||
| } | ||
| const baseType = path.join(__dirname, `../release/${platform || 'h5'}/dist/es/types/spec/${componentName.toLowerCase()}/base.d.ts`) | ||
| const source = fse.readFileSync(baseType, { encoding: 'utf8' }) | ||
| const result = transform({ source }, { jscodeshift: j }) | ||
| fse.writeFileSync(baseType, result) | ||
| } |
There was a problem hiding this comment.
新增的 addJSDoc 函数实现
addJSDoc 函数的实现逻辑清晰，但存在一个潜在问题：在管道失败日志中显示第 166 行有错误，表明 typeLiteral.members 可能为 undefined。需要在访问 members 属性前添加额外的检查。
建议修复此处的错误，确保在访问 members 属性前进行检查：
const typeLiteral = annotationTypes[annotationTypes.length - 1]
- typeLiteral.members.forEach((item) => {
+ if (typeLiteral && typeLiteral.members) {
+ typeLiteral.members.forEach((item) => {
addComment(item)
})
+ }📝 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.
| function addJSDoc(propsJson, componentName, platform) { | |
| const transform = (file, api) => { | |
| const j = api.jscodeshift.withParser('ts') | |
| const ast = j(file.source) | |
| function addComment(item) { | |
| if (!item.key) return | |
| const description = propsJson[componentName.toLowerCase()][item.key.name] | |
| if (!description) return | |
| item['comments'] = [ | |
| j.commentBlock(`*\n* ${description['desc']}\n`), | |
| ] | |
| } | |
| ast | |
| .find(j.TSTypeAliasDeclaration).forEach((path) => { | |
| const annotationTypes = path.value.typeAnnotation.types | |
| if (!annotationTypes) return | |
| const typeLiteral = annotationTypes[annotationTypes.length - 1] | |
| typeLiteral.members.forEach((item) => { | |
| addComment(item) | |
| }) | |
| }) | |
| ast.find(j.TSInterfaceDeclaration, { | |
| id: { | |
| name: `Base${componentName}`, | |
| type: 'Identifier', | |
| }, | |
| }) | |
| .forEach((path) => { | |
| path.value?.body?.body?.forEach((item) => { | |
| addComment(item) | |
| }) | |
| }) | |
| return ast.toSource() | |
| } | |
| const baseType = path.join(__dirname, `../release/${platform || 'h5'}/dist/es/types/spec/${componentName.toLowerCase()}/base.d.ts`) | |
| const source = fse.readFileSync(baseType, { encoding: 'utf8' }) | |
| const result = transform({ source }, { jscodeshift: j }) | |
| fse.writeFileSync(baseType, result) | |
| } | |
| function addJSDoc(propsJson, componentName, platform) { | |
| const transform = (file, api) => { | |
| const j = api.jscodeshift.withParser('ts') | |
| const ast = j(file.source) | |
| function addComment(item) { | |
| if (!item.key) return | |
| const description = propsJson[componentName.toLowerCase()][item.key.name] | |
| if (!description) return | |
| item['comments'] = [ | |
| j.commentBlock(`*\n* ${description['desc']}\n`), | |
| ] | |
| } | |
| ast | |
| .find(j.TSTypeAliasDeclaration).forEach((path) => { | |
| const annotationTypes = path.value.typeAnnotation.types | |
| if (!annotationTypes) return | |
| const typeLiteral = annotationTypes[annotationTypes.length - 1] | |
| if (typeLiteral && typeLiteral.members) { | |
| typeLiteral.members.forEach((item) => { | |
| addComment(item) | |
| }) | |
| } | |
| }) | |
| ast.find(j.TSInterfaceDeclaration, { | |
| id: { | |
| name: `Base${componentName}`, | |
| type: 'Identifier', | |
| }, | |
| }) | |
| .forEach((path) => { | |
| path.value?.body?.body?.forEach((item) => { | |
| addComment(item) | |
| }) | |
| }) | |
| return ast.toSource() | |
| } | |
| const baseType = path.join(__dirname, `../release/${platform || 'h5'}/dist/es/types/spec/${componentName.toLowerCase()}/base.d.ts`) | |
| const source = fse.readFileSync(baseType, { encoding: 'utf8' }) | |
| const result = transform({ source }, { jscodeshift: j }) | |
| fse.writeFileSync(baseType, result) | |
| } |
🧰 Tools
🪛 GitHub Actions: CI
[error] 166-166: TypeError: Cannot read properties of undefined (reading 'forEach')
Summary by CodeRabbit
新功能
BasePickerView接口，支持更灵活的选择器组件。WebPickerViewProps和TaroPickerViewProps接口，扩展选择器功能。文档
重构