尧图网页设计 
Sway 依赖管理实战forc add 命令详解与 Forc.toml 写入机制【免费下载链接】sway Empowering everyone to build reliable and efficient smart contracts.项目地址: https://gitcode.com/GitHub_Trending/sw/sway在 Sway 项目基于 Forc 工具链中管理Forc.toml清单文件里的依赖最标准的方式就是forc add命令它一次性把版本依赖、本地路径依赖、Git 依赖或 IPFS 依赖写入清单的[dependencies]或[contract-dependencies]区段并同步更新Forc.lock。读完后你能掌握forc add的完整参数用法、依赖来源的合法性校验规则以及从源码层面理解它如何安全地修改清单文件包括 dry-run 与失败回滚机制从而在真实项目中可靠地完成依赖管理。命令用法与参数forc add的官方用法为forc add [OPTIONS] DEP_SPEC...其中位置参数DEP_SPEC支持同时添加多个依赖每个依赖的格式为name[version]例如custom_lib0.1.0或custom_contract。源码中该参数被定义为可接受 1 到多个值的字符串向量见 add.rs 中dependencies: VecString的声明版本部分在解析阶段会做 semver 校验非法版本如foonot-a-version会直接报错invalid version requirement。完整选项如下选项说明--path PATH添加本地路径依赖--git URI添加 Git 来源依赖--branch branchGit 分支须与--git组合--tag tagGit 标签须与--git组合--rev revGit 修订号须与--git组合--ipfs CID添加 IPFS 来源依赖--contract-dep写入[contract-dependencies]区段而非[dependencies]--salt SALT合约部署用盐值仅对合约依赖生效--package SPEC在 workspace 中指定要修改的具体包--manifest-path PATH指定Forc.toml的路径--dry-run只展示将发生的变更不写入文件--offline不获取任何远程依赖--ipfs-node FUEL\|PUBLIC\|LOCAL\|URL拉取 IPFS 来源依赖时使用的 IPFS 节点从 CLI 参数定义看shared.rs这些选项被组织成四个共享参数组且带有严格的互斥约束Source 组SourceArgspath、git、ipfs三者构成一个 clap 互斥组即同一条命令里三种来源只能选其一Git 引号组GitRefbranch、tag、rev三者互斥multiple(false)并且必须要求同时给出git.requires(git)。这意味着forc add mylib --branch main缺少--git在命令行解析阶段就会被拒绝。官方帮助信息中给出的典型示例同样定义在 add.rs 的cli_examples宏里# 添加一个版本依赖 forc add DEP[VERSION] # 添加一个合约依赖 forc add DEP[VERSION] --contract-dep # 预演不实际写入 forc add DEP[VERSION] --dry-run依赖来源的解析规则forc add接收参数后会将其转换为内部结构ModifyOptsdep_modifier.rs并调用dep_modifier::modify_dependencies执行实际修改。每个DEP_SPEC先被解析为DepSpec { name, version_req }按第一个切分名称在前、版本要求在后空字符串会被拒绝Dependency spec cannot be empty。随后resolve_dependency依据“命令行来源参数 版本要求”的组合决定最终写入清单的依赖形态核心逻辑如下只给了版本号如mylib1.0.0写入简单的Dependency::Simple(version)在清单中表现为mylib 1.0.0给了来源参数--path/--git/--ipfs写入Dependency::Detailed(details)清单中表现为内联表inline table两者都没给如果该包名恰好是当前 workspace 的同级成员sibling则自动推导相对路径写成路径依赖例如../pkg1否则报错dependency ... source not specified. Please specify a source (e.g., git, path) or version。源码中此处还留有注释表明 registry如 forc.pub的集成是后续计划。写入前DependencyDetails::validate()manifest/mod.rs会执行合法性校验以下是实际会触发的错误规则非法组合报错信息有branch/tag/rev但没有gitDetails reserved for git sources used without a git fieldbranch、tag、rev三者同时给出Cannot specifybranch,tag, andrevtogether for dependency with a Git sourcebranch与tag同时给出Cannot specify bothbranchandtagfor dependency with a Git sourcerev与tag同时给出Cannot specify bothrevandtagfor dependency with a Git sourcebranch与rev同时给出Cannot specify bothbranchandrevfor dependency with a Git sourceversion与git同时存在Both version and git details provided for same dependencyversion与ipfs同时存在Both version and ipfs details provided for same dependencyversion与path同时存在Both version and path details provided for same dependencynamespace存在但无versionNamespace can only be specified for sources with version这些规则在 dep_modifier.rs 的测试模块test_resolve_dependency_detailed_variant_failure等中都有对应的单元测试覆盖是验证上述行为的直接依据。值得注意的一个细节Git 来源的字段会按原样写入清单内联表其中 IPFS CID 写入的键名是cid见generate_table函数inline.insert(cid, ...)而 CLI 参数名是--ipfs两者不要混淆。合约依赖--contract-dep 与 --salt当依赖的是合约contract时需要用--contract-dep将依赖写入[contract-dependencies]区段而不是[dependencies]。该命令的实现会额外处理salt盐值salt 用于合约部署时计算确定性的合约 ID提供--salt时值必须以0x开头的十六进制字符串HexSalt::from_str会先剥离0x前缀再解析见 manifest/mod.rs 中HexSalt的FromStr实现非法格式会报Invalid salt format未提供 salt 时使用fuel_tx::Salt::default()作为默认盐值。写入清单后合约依赖的条目形如[contract-dependencies] some_contract { version 1.0.0, salt 0x2222222222222222222222222222222222222222222222222222222222222222 }仓库中的真实示例可以参考 multi_contract_calls/caller/Forc.toml其中就包含[contract-dependencies]区段演示了调用方合约依赖被调用方合约的写法。关于 salt 与合约 ID 的对应关系可结合 forc contract-id 命令文档 进一步查看。workspace 支持--package 与同级包自动推导当在 workspace 根目录Forc.toml为[workspace]清单执行forc add时resolve_package_path无法确定要修改哪个成员因此必须提供--package SPEC否则会报错并列出所有可用成员forc add could not determine which package to modify. Use --package. Available: pkg1, pkg2如果--package指定的包名不存在则报package(s) name not found in workspace root。这些行为在 dep_modifier.rs 的测试test_resolve_package_path_workspace_package_not_set、test_resolve_package_path_workspace_package_not_found中被逐条验证。另一个实用能力是workspace 同级包自动推导当依赖名与某个 workspace 成员同名、且未显式指定来源和版本时forc add会自动将其解析为相对路径依赖。例如 workspace 下有pkg1和pkg2执行forc add pkg1 --package pkg2会写入[dependencies] pkg1 { path ../pkg1 }相对路径以两个包的共同父目录为基准计算见resolve_dependency中strip_prefix的处理对应测试为test_resolve_dependency_from_workspace_sibling。同时命令会阻止包依赖自身——若目标包与当前包同名同目录报错cannot add ... as a dependency to itself。--manifest-path、--dry-run 与 --offline--manifest-path直接指定Forc.toml路径。若未提供则从当前工作目录向上定位清单文件ManifestFile::from_dir(cwd)。--dry-run实现上分两步。首先正常完成清单修改与构建计划build plan计算确认依赖解析无误后把清单内容回写为修改前的备份并输出Dry run enabled. toml file not modified.日志dep_modifier.rs 中modify_dependencies的opts.dry_run分支。因此在 dry-run 模式下清单文件最终保持原样其价值在于先验证依赖能否被成功解析再执行正式写入。--offline禁止在依赖管理过程中访问网络只使用已下载的依赖缓存。该标志会透传给构建计划生成BuildPlan::from_lock_and_manifests在离线环境或 CI 场景中保证行为可复现。清单写入与失败回滚机制forc add对Forc.toml的修改并非简单的字符串拼接而是基于toml_edit的DocumentMut解析-修改-序列化流程dep_modifier.rs 中modify_dependencies函数这样能保留原有注释与格式。其完整流程为读取目标包的Forc.toml解析为 TOML 文档并保存一份备份backup_doc加载旧Forc.lock按区段dependencies或contract-dependencies逐条插入新依赖——Section::add_deps_manifest_table会先确保区段表存在简单版本依赖写成字符串值详细依赖写成内联表写回文件后基于新清单重建构建计划并刷新 lock 文件若构建计划重建失败例如远程依赖拉不下来自动将清单恢复为备份内容并以失败退出——保证不会留下一个无法构建的Forc.toml。这套“写入-校验-回滚”机制意味着只要你执行forc add后看到命令成功返回清单与 lock 文件就是自洽可用的反之任何解析或获取失败都不会污染你的清单文件。相关命令与延伸阅读forc remove与forc add共享同一套dep_modifier实现Action::Remove负责从[dependencies]或[contract-dependencies]移除依赖参数风格一致参见 forc remove 文档forc build添加依赖后用于编译验证参见 forc build 文档forc update刷新 lock 文件中的依赖版本参见 forc update 文档更底层的清单结构与来源获取逻辑可查看 forc-pkg/src/manifest/mod.rsDependency、DependencyDetails、ContractDependency定义与 forc-pkg/src/source/mod.rsIPFSNode的FUEL/PUBLIC/LOCAL/自定义 URL 解析。小结forc add以“位置参数 来源选项”的组合覆盖了版本、本地路径、Git、IPFS 四类依赖来源并通过--contract-dep/--salt支持合约依赖、通过--package精确操作 workspace 成员。理解其背后的解析校验规则版本与来源互斥、Git 引用互斥和“写入-校验-回滚”的清单处理流程能帮助你在自动化脚本与 CI 中安全地管理 Sway 项目依赖配合--dry-run预演与--offline离线模式可在不触碰现有工程文件的前提下验证依赖变更的正确性。【免费下载链接】sway Empowering everyone to build reliable and efficient smart contracts.项目地址: https://gitcode.com/GitHub_Trending/sw/sway创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Sway 依赖管理实战：forc add 命令详解与 Forc.toml 写入机制
Sway 依赖管理实战forc add 命令详解与 Forc.toml 写入机制【免费下载链接】sway Empowering everyone to build reliable and efficient smart contracts.项目地址: https://gitcode.com/GitHub_Trending/sw/sway在 Sway 项目基于 Forc 工具链中管理Forc.toml清单文件里的依赖最标准的方式就是forc add命令它一次性把版本依赖、本地路径依赖、Git 依赖或 IPFS 依赖写入清单的[dependencies]或[contract-dependencies]区段并同步更新Forc.lock。读完后你能掌握forc add的完整参数用法、依赖来源的合法性校验规则以及从源码层面理解它如何安全地修改清单文件包括 dry-run 与失败回滚机制从而在真实项目中可靠地完成依赖管理。命令用法与参数forc add的官方用法为forc add [OPTIONS] DEP_SPEC...其中位置参数DEP_SPEC支持同时添加多个依赖每个依赖的格式为name[version]例如custom_lib0.1.0或custom_contract。源码中该参数被定义为可接受 1 到多个值的字符串向量见 add.rs 中dependencies: VecString的声明版本部分在解析阶段会做 semver 校验非法版本如foonot-a-version会直接报错invalid version requirement。完整选项如下选项说明--path PATH添加本地路径依赖--git URI添加 Git 来源依赖--branch branchGit 分支须与--git组合--tag tagGit 标签须与--git组合--rev revGit 修订号须与--git组合--ipfs CID添加 IPFS 来源依赖--contract-dep写入[contract-dependencies]区段而非[dependencies]--salt SALT合约部署用盐值仅对合约依赖生效--package SPEC在 workspace 中指定要修改的具体包--manifest-path PATH指定Forc.toml的路径--dry-run只展示将发生的变更不写入文件--offline不获取任何远程依赖--ipfs-node FUEL\|PUBLIC\|LOCAL\|URL拉取 IPFS 来源依赖时使用的 IPFS 节点从 CLI 参数定义看shared.rs这些选项被组织成四个共享参数组且带有严格的互斥约束Source 组SourceArgspath、git、ipfs三者构成一个 clap 互斥组即同一条命令里三种来源只能选其一Git 引号组GitRefbranch、tag、rev三者互斥multiple(false)并且必须要求同时给出git.requires(git)。这意味着forc add mylib --branch main缺少--git在命令行解析阶段就会被拒绝。官方帮助信息中给出的典型示例同样定义在 add.rs 的cli_examples宏里# 添加一个版本依赖 forc add DEP[VERSION] # 添加一个合约依赖 forc add DEP[VERSION] --contract-dep # 预演不实际写入 forc add DEP[VERSION] --dry-run依赖来源的解析规则forc add接收参数后会将其转换为内部结构ModifyOptsdep_modifier.rs并调用dep_modifier::modify_dependencies执行实际修改。每个DEP_SPEC先被解析为DepSpec { name, version_req }按第一个切分名称在前、版本要求在后空字符串会被拒绝Dependency spec cannot be empty。随后resolve_dependency依据“命令行来源参数 版本要求”的组合决定最终写入清单的依赖形态核心逻辑如下只给了版本号如mylib1.0.0写入简单的Dependency::Simple(version)在清单中表现为mylib 1.0.0给了来源参数--path/--git/--ipfs写入Dependency::Detailed(details)清单中表现为内联表inline table两者都没给如果该包名恰好是当前 workspace 的同级成员sibling则自动推导相对路径写成路径依赖例如../pkg1否则报错dependency ... source not specified. Please specify a source (e.g., git, path) or version。源码中此处还留有注释表明 registry如 forc.pub的集成是后续计划。写入前DependencyDetails::validate()manifest/mod.rs会执行合法性校验以下是实际会触发的错误规则非法组合报错信息有branch/tag/rev但没有gitDetails reserved for git sources used without a git fieldbranch、tag、rev三者同时给出Cannot specifybranch,tag, andrevtogether for dependency with a Git sourcebranch与tag同时给出Cannot specify bothbranchandtagfor dependency with a Git sourcerev与tag同时给出Cannot specify bothrevandtagfor dependency with a Git sourcebranch与rev同时给出Cannot specify bothbranchandrevfor dependency with a Git sourceversion与git同时存在Both version and git details provided for same dependencyversion与ipfs同时存在Both version and ipfs details provided for same dependencyversion与path同时存在Both version and path details provided for same dependencynamespace存在但无versionNamespace can only be specified for sources with version这些规则在 dep_modifier.rs 的测试模块test_resolve_dependency_detailed_variant_failure等中都有对应的单元测试覆盖是验证上述行为的直接依据。值得注意的一个细节Git 来源的字段会按原样写入清单内联表其中 IPFS CID 写入的键名是cid见generate_table函数inline.insert(cid, ...)而 CLI 参数名是--ipfs两者不要混淆。合约依赖--contract-dep 与 --salt当依赖的是合约contract时需要用--contract-dep将依赖写入[contract-dependencies]区段而不是[dependencies]。该命令的实现会额外处理salt盐值salt 用于合约部署时计算确定性的合约 ID提供--salt时值必须以0x开头的十六进制字符串HexSalt::from_str会先剥离0x前缀再解析见 manifest/mod.rs 中HexSalt的FromStr实现非法格式会报Invalid salt format未提供 salt 时使用fuel_tx::Salt::default()作为默认盐值。写入清单后合约依赖的条目形如[contract-dependencies] some_contract { version 1.0.0, salt 0x2222222222222222222222222222222222222222222222222222222222222222 }仓库中的真实示例可以参考 multi_contract_calls/caller/Forc.toml其中就包含[contract-dependencies]区段演示了调用方合约依赖被调用方合约的写法。关于 salt 与合约 ID 的对应关系可结合 forc contract-id 命令文档 进一步查看。workspace 支持--package 与同级包自动推导当在 workspace 根目录Forc.toml为[workspace]清单执行forc add时resolve_package_path无法确定要修改哪个成员因此必须提供--package SPEC否则会报错并列出所有可用成员forc add could not determine which package to modify. Use --package. Available: pkg1, pkg2如果--package指定的包名不存在则报package(s) name not found in workspace root。这些行为在 dep_modifier.rs 的测试test_resolve_package_path_workspace_package_not_set、test_resolve_package_path_workspace_package_not_found中被逐条验证。另一个实用能力是workspace 同级包自动推导当依赖名与某个 workspace 成员同名、且未显式指定来源和版本时forc add会自动将其解析为相对路径依赖。例如 workspace 下有pkg1和pkg2执行forc add pkg1 --package pkg2会写入[dependencies] pkg1 { path ../pkg1 }相对路径以两个包的共同父目录为基准计算见resolve_dependency中strip_prefix的处理对应测试为test_resolve_dependency_from_workspace_sibling。同时命令会阻止包依赖自身——若目标包与当前包同名同目录报错cannot add ... as a dependency to itself。--manifest-path、--dry-run 与 --offline--manifest-path直接指定Forc.toml路径。若未提供则从当前工作目录向上定位清单文件ManifestFile::from_dir(cwd)。--dry-run实现上分两步。首先正常完成清单修改与构建计划build plan计算确认依赖解析无误后把清单内容回写为修改前的备份并输出Dry run enabled. toml file not modified.日志dep_modifier.rs 中modify_dependencies的opts.dry_run分支。因此在 dry-run 模式下清单文件最终保持原样其价值在于先验证依赖能否被成功解析再执行正式写入。--offline禁止在依赖管理过程中访问网络只使用已下载的依赖缓存。该标志会透传给构建计划生成BuildPlan::from_lock_and_manifests在离线环境或 CI 场景中保证行为可复现。清单写入与失败回滚机制forc add对Forc.toml的修改并非简单的字符串拼接而是基于toml_edit的DocumentMut解析-修改-序列化流程dep_modifier.rs 中modify_dependencies函数这样能保留原有注释与格式。其完整流程为读取目标包的Forc.toml解析为 TOML 文档并保存一份备份backup_doc加载旧Forc.lock按区段dependencies或contract-dependencies逐条插入新依赖——Section::add_deps_manifest_table会先确保区段表存在简单版本依赖写成字符串值详细依赖写成内联表写回文件后基于新清单重建构建计划并刷新 lock 文件若构建计划重建失败例如远程依赖拉不下来自动将清单恢复为备份内容并以失败退出——保证不会留下一个无法构建的Forc.toml。这套“写入-校验-回滚”机制意味着只要你执行forc add后看到命令成功返回清单与 lock 文件就是自洽可用的反之任何解析或获取失败都不会污染你的清单文件。相关命令与延伸阅读forc remove与forc add共享同一套dep_modifier实现Action::Remove负责从[dependencies]或[contract-dependencies]移除依赖参数风格一致参见 forc remove 文档forc build添加依赖后用于编译验证参见 forc build 文档forc update刷新 lock 文件中的依赖版本参见 forc update 文档更底层的清单结构与来源获取逻辑可查看 forc-pkg/src/manifest/mod.rsDependency、DependencyDetails、ContractDependency定义与 forc-pkg/src/source/mod.rsIPFSNode的FUEL/PUBLIC/LOCAL/自定义 URL 解析。小结forc add以“位置参数 来源选项”的组合覆盖了版本、本地路径、Git、IPFS 四类依赖来源并通过--contract-dep/--salt支持合约依赖、通过--package精确操作 workspace 成员。理解其背后的解析校验规则版本与来源互斥、Git 引用互斥和“写入-校验-回滚”的清单处理流程能帮助你在自动化脚本与 CI 中安全地管理 Sway 项目依赖配合--dry-run预演与--offline离线模式可在不触碰现有工程文件的前提下验证依赖变更的正确性。【免费下载链接】sway Empowering everyone to build reliable and efficient smart contracts.项目地址: https://gitcode.com/GitHub_Trending/sw/sway创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考