尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

Dagger TypeScript SDK 中的 DirectoryAsModuleOpts 与 sourceRootPath:从目录加载模块的完整指南

Dagger TypeScript SDK 中的 DirectoryAsModuleOpts 与 sourceRootPath:从目录加载模块的完整指南 Dagger TypeScript SDK 中的 DirectoryAsModuleOpts 与 sourceRootPath从目录加载模块的完整指南【免费下载链接】daggerAutomation engine to build, test and ship any codebase. Runs locally, in CI, or directly in the cloud项目地址: https://gitcode.com/GitHub_Trending/da/dagger导读本文围绕 Dagger TypeScript SDK 的类型别名DirectoryAsModuleOpts展开深入讲解如何通过Directory.asModule()将一个目录加载为 Dagger 模块并重点剖析其唯一可选参数sourceRootPath的作用、默认行为与底层实现原理。读完本文你将掌握在 Dagger 中指定模块源码根目录而非总是使用目录根的完整用法并理解引擎端如何通过配置文件向上查找find-up来确定 source root。DirectoryAsModuleOpts类型别名总览在 Dagger TypeScript SDK 的版本化 API 参考文档中DirectoryAsModuleOpts被定义为一个object类型的类型别名作为Directory.asModule()方法的可选参数对象。其完整定义如下来自 DirectoryAsModuleOpts.mdtype DirectoryAsModuleOpts { /** * 目录中的一个可选子路径该子路径下包含模块的配置文件。 * * 如果未设置模块源码将从目录的根位置加载。 */ sourceRootPath?: string }在 SDK 的生成代码 sdk/typescript/src/api/client.gen.ts 中可以看到该类型与文档保持一致export type DirectoryAsModuleOpts { /** * An optional subpath of the directory which contains the modules configuration file. * * If not set, the module source code is loaded from the root of the directory. */ sourceRootPath?: string }值得注意的是DirectoryAsModuleOpts并不是一个孤立类型SDK 中还存在一个结构完全相同的姊妹类型DirectoryAsModuleSourceOpts见 client.gen.ts它服务于Directory.asModuleSource()方法。两者的唯一字段都是sourceRootPath语义也完全一致——区别仅在于方法的返回值不同详见下文两个容易混淆的方法一节。sourceRootPath模块源码根目录的定位器sourceRootPath是DirectoryAsModuleOpts中唯一的属性也是整个类型别名的核心。它的作用是当目标目录包含多个子目录、而模块的配置文件和源码位于某个子目录而非目录根时通过该参数显式指定模块配置所在的位置。语义与默认行为根据官方文档与 SDK 注释其语义可以概括为两点可选子路径sourceRootPath是目录内的一个可选子路径subpath该子路径下包含模块的配置文件configuration file。默认从根加载如果未设置模块源码将从目录的根位置加载。也就是说当你的Directory对象代表的目录结构如下时monorepo/ ├── apps/ │ └── web/ │ ├── dagger.json # 模块配置文件 │ └── src/ # 模块实现源码 └── packages/ └── shared/如果这个Directory是monorepo/本身而你希望把它当作模块加载的是apps/web子目录就需要传入sourceRootPath: apps/web否则引擎会默认在monorepo/的根部查找模块配置——如果根部没有配置文件加载就会失败。与 GraphQL Schema 的对应关系该参数不是 TypeScript SDK 的专有概念而是 Dagger GraphQL API 的通用参数。在核心层的 GraphQL 字段定义 core/schema/modulesource.go 中asModule与asModuleSource字段都声明了sourceRootPath参数且文档字符串与 SDK 注释逐字一致dagql.Fields[*core.Directory]{ dagql.NodeFunc(asModule, s.directoryAsModule). Doc(Load the directory as a Dagger module source). Args( dagql.Arg(sourceRootPath).Doc( An optional subpath of the directory which contains the modules configuration file., If not set, the module source code is loaded from the root of the directory.), ), dagql.NodeFunc(asModuleSource, s.directoryAsModuleSource). ... }这印证了 TypeScript SDK 中的DirectoryAsModuleOpts正是由这份 GraphQL Schema 通过代码生成codegen自动产出的——SDK 中的asModule方法最终会把opts展开为 GraphQL 参数并提交给引擎见 client.gen.ts 中this._ctx.select(asModule, { ...opts })的调用方式。使用场景在 TypeScript SDK 中调用 asModuleDirectoryAsModuleOpts的实际使用入口是Directory.asModule()方法。在 Directory.md 中该方法的签名如下asModule(opts?: DirectoryAsModuleOpts): Module_入参opts?类型为DirectoryAsModuleOpts可选。返回值Module_一个 Dagger 模块实例随后可继续调用模块上的方法如解析、生成代码、加载等。典型用法示例场景一目录根就是模块根默认行为无需传参import { connect } from dagger.io/dagger connect(async (client) { const module client .host() .directory(/path/to/my-module) .asModule() // 省略后续对 module 的处理 })由于sourceRootPath未设置引擎会默认在/path/to/my-module的根部查找模块配置文件。场景二模块位于目录的子目录中显式指定 sourceRootPathimport { connect } from dagger.io/dagger connect(async (client) { const module client .host() .directory(/path/to/monorepo) .asModule({ sourceRootPath: apps/web }) // 模块配置文件将到 /path/to/monorepo/apps/web 下查找 })两个容易混淆的方法asModule 与 asModuleSourceDirectoryAsModuleOpts与DirectoryAsModuleSourceOpts字段相同但对应的两个方法返回类型不同见 Directory.md方法参数类型返回类型语义asModule(opts?)DirectoryAsModuleOptsModule_将目录作为 Dagger 模块加载asModuleSource(opts?)DirectoryAsModuleSourceOptsModuleSource将目录作为模块源码加载更底层的表示两者都接受sourceRootPath通常ModuleSource是更细粒度的中间表示而Module_是经过进一步处理后的模块实例。在 modulesource.go 中可以看到asModuleSource还额外带有PerClientInput输入标记说明其上下文解析与客户端会话相关。底层原理引擎如何解析 sourceRootPath理解了用法之后再深入引擎端看sourceRootPath是如何被消费的这有助于规避使用中的坑。模块配置文件dagger-module.toml 与 legacy dagger.json引擎在确定 source root 时会寻找模块配置文件。配置文件名定义在 core/modules/config.go// Filename is the name of the current module config file. const Filename dagger-module.toml // LegacyFilename is the legacy module config file name. const LegacyFilename dagger.json即当前项目使用dagger-module.toml作为模块配置文件名同时兼容旧的dagger.json。find-up向上查找配置与 .git在 core/schema/modulesource.go 中模块源码解析逻辑会从传入的本地路径出发向上向父目录查找两类东西.git目录——用于确定上下文目录context dir即 git 仓库根。模块配置文件dagger-module.toml或dagger.json通过modules.ConfigFilenames()枚举——用于确定源码根目录source root。当sourceRootPath未设置时source root 默认就是传入的路径本身见代码中sourceRootPath localAbsPath的分支。随后代码会计算 source root 相对于 context dir 的路径并进行越界校验sourceRootRelPath, err : pathutil.LexicalRelativePath(contextDirPath, sourceRootPath) if err ! nil { return inst, fmt.Errorf(failed to get relative path from context to source root: %w, err) } if !filepath.IsLocal(sourceRootRelPath) { return inst, fmt.Errorf(source root path %q escapes context %q, sourceRootRelPath, contextDirPath) }这意味着sourceRootPath必须落在 context 目录之内不允许通过..逃逸到目录之外。对 Git 模块的影响从源码可见sourceRootPath还会影响 Git 类模块源的展示信息在 modulesource.go 中当sourceRootPath ! .时它会拼接到 Git 模块的 symbolic 路径与 HTML 链接上if sourceRootPath ! . { src.Git.Symbolic / filepath.ToSlash(sourceRootPath) } src.Git.HTMLURL, err src.Git.Link(sourceRootPath, -1, -1)也就是说对于从 Git 仓库加载的模块sourceRootPath同样被用于定位仓库内子目录中的模块配置。测试验证集成测试中的实际用法仓库的集成测试为sourceRootPath提供了可复现的验证示例。在 core/integration/module_typescript_test.go 中测试通过 GraphQL 查询直接演示了该参数的用法{ host { directory(path: .) { asModule(sourceRootPath: ./sub) { id } } } }这证明sourceRootPath接受形如./sub的相对路径写法引擎会将其规范化如filepath.Clean后用于模块解析。此外多个 SDK 的生成代码中例如 core/integration/testdata/modules/go/defaults/foobar/internal/dagger/dagger.gen.go也包含了对sourceRootPath参数的透传实现说明各语言 SDK 的该参数均来自同一份 GraphQL Schema。使用注意事项综合文档与源码使用DirectoryAsModuleOpts时需要注意以下几点路径必须位于目录内部sourceRootPath是相对路径且不能越出 context 目录引擎会做filepath.IsLocal校验见 modulesource.go。默认行为是根目录不传参时引擎默认从目录根加载模块如果目录根没有dagger-module.toml或dagger.json请务必显式指定子路径。sourceRootPath指向的是配置所在目录文档明确说明它是包含模块配置文件的子路径因此请传入包含配置文件的目录而不是某个随意的源码目录。区分asModule与asModuleSource二者参数相同但返回Module_与ModuleSource两种不同粒度的对象按业务需要选择。结语DirectoryAsModuleOpts虽然只有一个可选属性sourceRootPath却承担着从任意目录结构中准确定位 Dagger 模块源码根的关键职责。借助它你可以把Directory.asModule()用在 monorepo、嵌套项目等复杂目录布局上而无需先把子目录单独提取出来。理解其背后的 find-up 机制与配置文件约定dagger-module.toml/dagger.json能帮助你在实际使用中写出更稳健的模块加载逻辑。【免费下载链接】daggerAutomation engine to build, test and ship any codebase. Runs locally, in CI, or directly in the cloud项目地址: https://gitcode.com/GitHub_Trending/da/dagger创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表