ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

TypeDoc `@module` 标签实战指南:标记文件级文档注释并重命名顶层模块

TypeDoc `@module` 标签实战指南:标记文件级文档注释并重命名顶层模块 开发工具文档【免费下载链接】typedocDocumentation generator for TypeScript projects.项目地址https://gitcode.com/gh_mirrors/ty/typedoc点击查看免费下载本文围绕 TypeDoc 文档标签体系中 site/tags/module.md 所定义的module标签展开讲清它的两个核心作用——把注释块声明为「文件/模块级」文档而非紧随其后的声明的文档、以及在 TypeDoc 猜测模块名不准确时手动重命名模块。读完你将理解「模块注释」与「声明注释」的判定规则、该标签必须位于文件顶部的约束来源以及它如何影响生成文档的页面结构与路由并能正确使用它与packageDocumentation、mergeModuleWith等配套标签协作。1. 定位module是标记「文件级文档」的块标签TypeDoc 支持一套特定的文档标签其中许多 JSDoc 标签并不支持因为 TypeScript 编译器可以直接从代码推断相同信息不识别的标签会触发警告见 site/tags.md。module就是其中之一它的官方定义是Themoduletag is used to mark a comment as referring to a file rather than the declaration following it. It may optionally be used to rename a module whose name TypeDoc guesses incorrectly. module标签用于将注释标记为指向文件本身而非其后跟随的声明也可选地用于重命名 TypeDoc 猜测不准确的模块名。Tag Kind: Block块标签。从源码的默认标签清单可以印证这一点module被列入 TSDoc 块标签常量 tsdocBlockTags而 TSDoc 标准的packageDocumentation则属于修饰符modifier标签两者语义相近但分类不同。为什么要专门标记「文件级文档」TypeScript 的入口文件如file1.ts开头往往有一段注释后面跟着import语句。如果没有显式标记TypeDoc 会倾向于把这段注释解释为紧随其后的第一个声明比如那个import绑定的 JSDoc而不是整个文件模块的文档。module就是消除这种歧义的开关。2. 完整用法与官方示例下面是 site/tags/module.md 给出的官方完整示例覆盖「重命名」「不重命名」「无标记的对照」三种情况// file1.ts /** * This is the doc comment for file1.ts * * Specify this is a module comment and rename it to my-module: * module my-module */ import * as lib from lib; // file2.ts /** * Specify this is a module comment without renaming it: * module */ import * as lib from lib; // file3.ts /** * This is *not* a doc comment for the file, it is a doc comment for the import. * Include the module or packageDocumentation tag to mark it as a file comment. */ import * as lib from lib;三个文件的行为差异file1.ts注释被识别为文件模块级文档并且模块在生成文档中被重命名为my-modulefile2.ts注释被识别为文件模块级文档但模块保留 TypeDoc 按规则推断的名称通常是文件名file3.ts没有任何标记注释不会被当作文件文档而是归属于后面的import声明。关键约束使用了module标签的注释块必须是文件中的第一个注释。因此推荐把它放在文件顶部、任何 import 语句之前。这个约束有明确的源码依据文件注释的发现函数 discoverFileComments 使用ts.getLeadingCommentRanges(text, node.pos)只收集文件首个语法元素之前的前置注释范围——写在 import 之后、声明之间的注释根本不会被扫描为「文件注释」自然也无法承担module的职责。3. 重命名机制的细节带名称与不带名称module后面跟不跟名称行为不同这一点在 CommentPlugin 的onDeclaration钩子中有精确实现if (reflection.kindOf(ReflectionKind.SomeModule)) { const tag comment.getTag(module); if (tag) { // If no name is specified, this is a flag to mark a comment as a module comment // and should not result in a reflection rename. const newName Comment.combineDisplayParts(tag.content).trim(); if (newName.length !newName.includes(\n)) { reflection.name newName; } removeIfPresent(comment.blockTags, tag); } }从这段实现可以看出两条规则空内容 纯标记。module后不写名称时它只是一个「这是模块注释」的标志不触发重命名源码注释原话If no name is specified, this is a flag ... and should not result in a reflection rename名称必须是单行。只有标签内容非空且不含换行时才会执行reflection.name newName。如果module后面意外地写入了多行文本重命名会静默失效模块仍按原名展示。4. 底层原理模块注释与声明注释的互斥判定module/packageDocumentation的真正判定逻辑集中在注释获取层 src/lib/converter/comments/index.ts核心是getCommentImpl中的一对互斥检查if (moduleComment comment) { // Module comment, make sure it is tagged with packageDocumentation or module. // If it isnt then the comment applies to the first statement in the file, so throw it away. if ( !comment.hasModifier(packageDocumentation) !comment.getTag(module) ) { return; } } if (!moduleComment comment) { // Ensure module comments are not attached to non-module reflections. if ( comment.hasModifier(packageDocumentation) || comment.getTag(module) ) { return; } }这段代码解释了官方示例中 file3.ts 的行为以及两个容易踩坑的方向给模块反射取注释时moduleComment true文件头注释若既没有packageDocumentation也没有module这里直接丢弃对模块而言该注释转而可能被解释为文件里第一条语句的 JSDoc给非模块反射取注释时moduleComment false如果注释里带了module或packageDocumentation则同样丢弃——模块注释绝不会附着到非模块反射上。文件级注释的完整取用流程在 getFileComment 中遍历discoverFileComments返回的文件顶部注释跳过带license/import的注释块找到第一个带module或packageDocumentation标记的注释后才通过getCommentWithCache正式解析并缓存它。5. 输出阶段标签被清理模块名影响页面路由module是一个「发现型」标签——它的使命在转换conversion阶段完成之后就不会出现在渲染出的文档中当反射是Project或模块ReflectionKind.Project | ReflectionKind.SomeModule时CommentPlugin 会执行comment.removeTags(module)和comment.removeModifier(packageDocumentation)把这两个标签从注释中彻底移除上节重命名代码中也有removeIfPresent(comment.blockTags, tag)处理完重命名后即删除该标签。同时module提供的重命名会直接反映到生成的站点 URL 结构上。StructureRouter 按模块结构把反射放进对应目录并特意允许模块名中出现/以「镜像文件结构」// Special case: Modules allow slashes in their name. We actually want // to allow that here to mirror file structures. const parts [...reflection.name.split(/).map(createNormalizedUrl)]; ... // This should only happen if someone tries to break things with module if (parts.includes(..)) { throw new Error( structure router cannot be used with a project that has a name containing .., ); }也就是说通过module把模块改名为带/的层级名称如module utils/string可以影响输出目录布局但名字中出现..会被结构路由明确拒绝并抛出错误。使用时应确保重命名后的模块名合法、不含路径穿越片段。6. 与packageDocumentation、mergeModuleWith的协作module的两个「搭档」标签值得一并了解它们正是官方文档 See Also 部分列出的内容6.1packageDocumentationTSDoc 标准替代方案TSDoc 标准规定的packageDocumentation标签同样可以把注释标记为指向文件而非后续声明但它是修饰符标签不能用来重命名模块。选择建议需要重命名模块、或希望语义上明确表达「这是 TypeDoc 模块文档」→ 用module只想把注释挂到文件上、且希望注释与 TSDoc 生态保持一致 → 用packageDocumentation。两者在底层走同一套判定见上文 index.ts 中的hasModifier(packageDocumentation) || getTag(module)效果等价之处完全一致。6.2mergeModuleWith把模块成员搬进其他模块mergeModuleWith用于告诉 TypeDoc 把当前模块或命名空间的子成员放到另一个模块下并移除当前模块典型场景是把多个 TypeScript 工程的结果合并成一个导出模块、却对每个工程单独运行 TypeDoc配合 packages 的 entryPointStrategy。从它的官方示例可以看出mergeModuleWith通常与module写在同一个文件头注释里// module-a.ts /** * module * mergeModuleWith project */ export function fn1() {}需要注意使用mergeModuleWith会影响链接解析——指向被移除模块的链接会被报告为断链源模块子成员内部的链接也可能被解析到任意一侧模块原文档给出了 WARNING 提示使用时应留意。7. 仓库中的真实用例与测试佐证TypeDoc 仓库自带测试用例验证了module的两种典型写法src/test/converter/comment/comment3.ts不带名称的纯标记用法注释明确说明「It isnotdocumentation for themultiplyfunction」即文件头注释带module后不会错误地挂在后面的multiply函数上src/test/converter/comment/comment4.ts文件头注释中包含多行代码块module写在代码块之后验证这种复杂注释结构下模块注释的解析仍然正确。此外src/test/comments.test.ts 中的Comment Parser测试用例显式地把module配置进blockTags、把packageDocumentation配置进modifierTags与 tsdoc-defaults.ts 的默认清单一致说明这两个标签的分类块标签 vs 修饰符标签是解析器层面的既定事实。8. 实践要点小结必须置顶module所在的注释块必须是文件第一个注释放在文件顶部、import 之前重命名要单行module my-module才能生效module后面跟多行文本会静默失效互斥规则模块注释不会附着到非模块反射无标记的文件头注释也不会被当作模块文档——file3.ts 那种「看起来像文件文档、实际属于 import」的注释正是这一规则的体现标签不会出现在输出里module与packageDocumentation在转换完成后即被从注释中移除属于纯粹的发现型标签与mergeModuleWith组合多工程合并场景下用modulemergeModuleWith控制模块归属但需接受由此带来的链接解析行为变化。赞分享开发工具文档【免费下载链接】typedocDocumentation generator for TypeScript projects.项目地址https://gitcode.com/gh_mirrors/ty/typedoc点击查看免费下载相关推荐TypeDoc mergeModuleWith 标签详解合并模块文档与多项目文档整合实践TypeDoc mergeModuleWith 标签详解合并模块文档与多项目文档整合实践 本文基于 TypeDoc 官方文档 site/tags/merge开发工具文档TypeDoc 标签体系详解TypeScript 项目文档注释中的 Block、Modifier 与 Inline 标签TypeDoc 标签体系详解TypeScript 项目文档注释中的 Block、Modifier 与 Inline 标签 TypeDoc 允许开发者在 JSD开发工具文档TypeDoc include 与 includeCode 标签实战指南在文档注释中嵌入外部文件、代码区域与行号片段TypeDoc include 与 includeCode 标签实战指南在文档注释中嵌入外部文件、代码区域与行号片段 TypeDoc 的 {includ开发工具文档上一篇AutoRemesher网格优化算法对比不同算法的优缺点全面解析下一篇为什么QNNPACK成为移动端量化网络的首选库看完这篇就懂创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表