尧图网站建设 
asdf 工具版本管理器用单一 .tool-versions 文件与插件系统统一管理开发工具版本【免费下载链接】asdfExtendable version manager with support for Ruby, Node.js, Elixir, Erlang more项目地址: https://gitcode.com/GitHub_Trending/as/asdfasdf 是一个可扩展的工具版本管理器Tool Version Manager支持 Ruby、Node.js、Elixir、Erlang 等大量工具与运行时环境。本文以 docs/zh-hans/guide/introduction.md 为核心结合本仓库GitHub_Trending/as/asdf的 Go 源码实现系统讲解 asdf 的核心设计单一.tool-versions配置文件的版本定义、垫片shim执行机制、插件系统架构以及它与 nvm/rbenv、direnv、Homebrew、NixOS 等方案的本质区别。读完本文你将理解 asdf 为什么能把多个版本管理器 多个配置文件 多套命令收敛为一个统一的工作流并掌握如何将项目工具版本提交到 Git 仓库实现团队完全一致的开发环境。asdf 是什么一个文件统一管理所有工具版本asdf的核心思想非常朴素却极具说服力所有工具版本定义都包含在一个文件.tool-versions中。你可以把这个文件放进项目的 Git 仓库里与团队共享从而确保每个人都使用完全相同的工具版本例如 exact same versions of tools见 docs/zh-hans/guide/introduction.md。传统的开发工作方式要求为每个工具准备一个独立的命令行版本管理器Node.js 用 nvm、Ruby 用 rbenv、Python 用 pyenv…… 每个管理器都有自己的 API、配置文件.nvmrc、.ruby-version、.python-version等和实现方式$PATH操作、垫片、环境变量等等。而asdf提供单一交互方式和单一配置文件来简化开发工作流并通过一个简单的插件接口Plugin Interface扩展到所有工具和运行环境。.tool-versions 文件格式详解.tool-versions是一个纯文本文件每行描述一个工具及其一个或多个版本。语法要点可以从本仓库的解析实现 internal/toolversions/toolversions.go 中确认# 每行格式工具名 版本1 [版本2 ...] ruby 3.2.2 nodejs 20.10.0 erlang 26.1.2关键解析规则对应parseLine与getAllToolsAndVersionsInContentinternal/toolversions/toolversions.go每一行以空格分隔出工具名与版本 token#号出现在行中任意位置时其后的内容被视为注释并被忽略strings.Cut(line, #)同一工具可以在一行内指定多个版本例如ruby 3.2.2 3.1.4运行时按顺序尝试匹配空行会被跳过。版本类型的灵活语法asdf的版本字符串不仅仅是数字版本号。从 internal/toolversions/toolversions.go 的Parse函数可以看到它支持 5 种版本类型版本类型写法示例含义version3.2.2普通发布的版本号refref:mainGit 引用分支/提交/tag用于安装源码形式的工具pathpath:/foo/bar/project使用本地已编译的源码目录中的二进制适合语言本身开发者systemsystem使用系统自带非 asdf 安装的版本latestlatest/latest:3.2解析为插件列出版本中的最新一个可携带过滤字符串仅在部分子命令中可用对应地Format负责把版本类型还原为可写回文件的字符串ref:、path:前缀FormatForFS则在文件系统层面把ref版本编码为ref-值形式的目录名internal/toolversions/toolversions.go。文件名也可以自定义虽然默认文件名是.tool-versions常量defaultToolVersionsFilenameDefault见 internal/config/config.go但可以通过环境变量ASDF_TOOL_VERSIONS_FILENAME或ASDF_DEFAULT_TOOL_VERSIONS_FILENAME覆盖internal/config/config.go 展示了这一解析逻辑。这为需要迁移或特殊约定的团队提供了灵活性。asdf 工作原理从 Shell 配置到垫片执行原文档用一段话概括了整体机制docs/zh-hans/guide/introduction.md一旦asdf核心在 Shell 配置中设置好之后你可以安装插件来管理特定的工具。当通过插件安装工具时安装的可执行程序会为每个可执行程序创建垫片。当你尝试运行其中一个可执行程序时将运行垫片从而让asdf识别.tool-versions文件中的工具版本并执行该版本。下面把这个流程拆解为四个环节并用仓库源码逐一印证。第一步Shell 配置单一 Shell 脚本asdf的核心以 Shell 脚本形式集成进你的 Shell 配置.bashrc/.zshrc等它只做两件关键的事导出ASDF_DIR等环境变量并把 asdf 的bin与shims目录加入PATH。本仓库的 Bats 集成测试 test/asdf_sh.bats 明确验证了这些行为exports ASDF_DIR、adds asdf dirs to PATH并且保证不会重复添加路径、在set -o nounset下也不会报错。这正是单一 Shell 脚本的简单性与熟悉性的工程化保障。第二步插件系统asdf本身不内置任何工具的安装逻辑而是通过插件Plugin把能力扩展到所有工具。插件本质上是放在 asdf 数据目录plugins/name/下的一个 Git 仓库内含bin/目录和一系列回调脚本如list-all、download、install、exec-path、list-legacy-filenames等。从 internal/plugins/plugins.go 可以看到Plugin结构体仅保存Name、Dir、Ref、URL四个字段internal/plugins/plugins.go而RunCallback则负责在插件目录中定位并执行指定名称的回调脚本。回调机制是 asdf 与 nvm 这类一工具一管理器方案的本质分水岭新增一种语言/工具不再需要一个全新的管理器只需要一个新的插件这也消除了每个管理工具不同的命令与仓库中不同的*-version文件。第三步安装工具与垫片生成当通过插件安装某个版本的工具后asdf 会为安装目录下每个可执行文件创建一个垫片shim。垫片生成的主流程在 internal/shims/shims.goGenerateAllinternal/shims/shims.go遍历所有插件GenerateForPluginVersionsinternal/shims/shims.go遍历某插件的所有已安装版本GenerateForVersioninternal/shims/shims.go枚举该版本的每个可执行文件并在调用pre_asdf_reshim_plugin/post_asdf_reshim_plugin钩子后逐个写入垫片Writeinternal/shims/shims.go垫片以0o777权限写入$ASDF_DATA_DIR/shims/可执行文件名内容记录了哪个插件的哪个版本提供了该命令。垫片目录的位置由Path/Directory计算得出即conf.DataDir/shiminternal/shims/shims.go正是第一步 Shell 配置中插入到PATH的那个目录。第四步运行时的版本解析与执行当你敲下node --version时Shell 实际命中$ASDF_DATA_DIR/shims/node这个垫片。垫片被调用后FindExecutableinternal/shims/shims.go解析垫片文件获得提供该命令的工具列表对每个工具调用resolve.Version在当前目录及上级目录中查找.tool-versions并解析出应使用的版本用toolversions.Intersect把配置的版本与垫片记录的版本取交集internal/shims/shims.go通过GetExecutablePath定位到对应版本安装目录中的真实可执行文件最终由 internal/exec/exec.go 调用syscall.Exec以真实可执行文件替换当前进程完成执行internal/exec/exec.go。这一过程中还可能遇到三种有代表性的错误分别对应三个自定义错误类型internal/shims/shims.go垫片不存在unknown command、未配置任何版本no versions set for shim、版本匹配但找不到对应可执行文件No shim executable found for tool version。另外如果插件提供了exec-path回调或自定义shim模板getCustomExecutablePath与ShimTemplatePath会优先使用它们来定制可执行文件的实际路径internal/shims/shims.go。版本解析的完整优先级版本解析是 asdf 的核心其完整顺序记录在 internal/resolve/resolve.go环境变量ASDF_TOOL_VERSION工具名大写、-转_例如ASDF_NODEJS_VERSION优先级最高internal/resolve/resolve.go逐级向上查找.tool-versions从当前目录开始向父目录逐级向上直到文件系统根目录internal/resolve/resolve.goHome 目录兜底若一路向上都未找到尝试读取用户主目录下的.tool-versionsLegacy 版本文件需开启legacy_version_file配置对支持该特性的插件读取其list-legacy-filenames回调列出的文件如.ruby-version并用parse-legacy-file回调解析版本internal/resolve/resolve.go、internal/plugins/plugins.go。也就是说项目根目录的.tool-versions覆盖上级目录这一直觉行为是由源码明确保证的——这也正是把配置文件放进 Git 仓库与团队共享能够生效的底层机制。与传统版本管理器的对比nvm / n / rbenvnvm、n、rbenv 等工具都是用 Shell 脚本实现的它们为各自工具安装的可执行程序创建垫片asdf与它们非常相似正是要在工具/运行时版本管理这个领域竞争。asdf的独特之处在于插件系统原文档 docs/zh-hans/guide/introduction.md 的表述。它一次性消除了三个痛点每个工具/运行时一个管理器→ 一个 asdf 管理所有工具每个管理器不同的命令→ 统一的asdf install/asdf local/asdf global等子命令仓库中不同的*-version文件.nvmrc、.ruby-version… → 只有一份.tool-versions。需要说明的是原文档中关于 pyenv 的对比章节目前仍是以注释形式存在的 TODOasdf has some similarities to pyenv but is missing some key features见 docs/zh-hans/guide/introduction.md说明官方对这类对比持审慎态度尚未给出正式结论。asdf 与 direnv环境变量管理的边界direnv 是根据当前所在目录动态加载和卸载环境变量来增强现有 shell 的工具。原文档明确了一个重要边界asdf不直接管理环境变量docs/zh-hans/guide/introduction.md。从源码看asdf 对环境的干预确实保持在最低限度除了 Shell 初始化脚本把 asdf 的bin/shims目录注入PATH之外运行时层面的唯一环境注入是解析ASDF_TOOL_VERSION这类输入变量以及execute.Command在运行插件回调时通过MergeWithCurrentEnv合并传入的环境internal/execute/execute.go。因此如果你需要进入某个目录时自动加载/卸载与该目录工具链相关的环境变量这类能力正确的做法是安装社区插件asdf-direnv把 direnv 的行为集成进 asdf而不是期待 asdf 核心提供该功能。asdf 与 Homebrew / NixOS为什么它不是包管理器原文档反复强调同一个观点asdf不是包管理器docs/zh-hans/guide/introduction.md。它与两类方案的定位差异如下HomebrewmacOS 或 Linux 上缺失包的管理器Homebrew 管理软件包及其上游依赖asdf不管理上游依赖依赖管理应当由用户负责asdf 只是尽力把依赖列表保持在较小规模。NixOSNix 是一种采用独特方法进行软件包管理和系统配置的工具NixOS 的目标是通过管理每个工具整个依赖关系树中软件包的确切版本来构建真正可重复的环境为此它拥有自己的编程语言、许多命令行工具和超过 60,000 个包的包集合。这是 asdf不想做的事情——asdf 只负责工具本身的版本选择与切换不染指系统级的依赖树复现。从实现角度也能印证这个边界asdf 的安装回调插件bin/install由插件作者自己编写asdf 核心只负责编排回调、记录版本、生成垫片与解析版本既不解析依赖也不编译任何包元数据。为什么使用 asdf综合原文档docs/zh-hans/guide/introduction.mdasdf 的核心价值可以归纳为三点团队版本一致性通过把.tool-versions提交进项目 Git 仓库确保团队使用完全相同的工具版本——不是大致相同而是逐字一致覆盖面广通过插件系统支持很多工具与运行时无需为每种语言维护一套独立的版本管理方案简单与熟悉它本质上只是你引入 Shell 配置中的一个Shell 脚本配合少量统一命令学习成本远低于维护多套管理器的 API 与配置文件。注意事项版本管理器 ≠ 包管理器原文档在末尾给出了一条必须遵守的边界docs/zh-hans/guide/introduction.mdasdf并不打算成为一个系统包管理器。它是一个工具版本管理器。仅仅因为你可以为任何工具创建插件并使用asdf管理其版本但这并不意味着这一定是某个特定工具的最佳实践方案。换言之能用 asdf 管理与应该用 asdf 管理是两回事。在实际选型时应当结合工具的生态惯例例如某些工具官方明确推荐自己的版本管理器以及团队的依赖管理需求做出判断而不是把 asdf 无差别地套用到所有场景。深入阅读完整介绍本文基础文档 docs/zh-hans/guide/introduction.md英文原版见 docs/guide/introduction.md快速上手docs/zh-hans/guide/getting-started.md核心实现internal/toolversions/toolversions.go、internal/resolve/resolve.go、internal/shims/shims.go、internal/plugins/plugins.go行为验证测试test/asdf_sh.bats、internal/toolversions/toolversions_test.go、internal/shims/shims_test.go【免费下载链接】asdfExtendable version manager with support for Ruby, Node.js, Elixir, Erlang more项目地址: https://gitcode.com/GitHub_Trending/as/asdf创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 asdf 工具版本管理器：用单一 .tool-versions 文件与插件系统统一管理开发工具版本
asdf 工具版本管理器用单一 .tool-versions 文件与插件系统统一管理开发工具版本【免费下载链接】asdfExtendable version manager with support for Ruby, Node.js, Elixir, Erlang more项目地址: https://gitcode.com/GitHub_Trending/as/asdfasdf 是一个可扩展的工具版本管理器Tool Version Manager支持 Ruby、Node.js、Elixir、Erlang 等大量工具与运行时环境。本文以 docs/zh-hans/guide/introduction.md 为核心结合本仓库GitHub_Trending/as/asdf的 Go 源码实现系统讲解 asdf 的核心设计单一.tool-versions配置文件的版本定义、垫片shim执行机制、插件系统架构以及它与 nvm/rbenv、direnv、Homebrew、NixOS 等方案的本质区别。读完本文你将理解 asdf 为什么能把多个版本管理器 多个配置文件 多套命令收敛为一个统一的工作流并掌握如何将项目工具版本提交到 Git 仓库实现团队完全一致的开发环境。asdf 是什么一个文件统一管理所有工具版本asdf的核心思想非常朴素却极具说服力所有工具版本定义都包含在一个文件.tool-versions中。你可以把这个文件放进项目的 Git 仓库里与团队共享从而确保每个人都使用完全相同的工具版本例如 exact same versions of tools见 docs/zh-hans/guide/introduction.md。传统的开发工作方式要求为每个工具准备一个独立的命令行版本管理器Node.js 用 nvm、Ruby 用 rbenv、Python 用 pyenv…… 每个管理器都有自己的 API、配置文件.nvmrc、.ruby-version、.python-version等和实现方式$PATH操作、垫片、环境变量等等。而asdf提供单一交互方式和单一配置文件来简化开发工作流并通过一个简单的插件接口Plugin Interface扩展到所有工具和运行环境。.tool-versions 文件格式详解.tool-versions是一个纯文本文件每行描述一个工具及其一个或多个版本。语法要点可以从本仓库的解析实现 internal/toolversions/toolversions.go 中确认# 每行格式工具名 版本1 [版本2 ...] ruby 3.2.2 nodejs 20.10.0 erlang 26.1.2关键解析规则对应parseLine与getAllToolsAndVersionsInContentinternal/toolversions/toolversions.go每一行以空格分隔出工具名与版本 token#号出现在行中任意位置时其后的内容被视为注释并被忽略strings.Cut(line, #)同一工具可以在一行内指定多个版本例如ruby 3.2.2 3.1.4运行时按顺序尝试匹配空行会被跳过。版本类型的灵活语法asdf的版本字符串不仅仅是数字版本号。从 internal/toolversions/toolversions.go 的Parse函数可以看到它支持 5 种版本类型版本类型写法示例含义version3.2.2普通发布的版本号refref:mainGit 引用分支/提交/tag用于安装源码形式的工具pathpath:/foo/bar/project使用本地已编译的源码目录中的二进制适合语言本身开发者systemsystem使用系统自带非 asdf 安装的版本latestlatest/latest:3.2解析为插件列出版本中的最新一个可携带过滤字符串仅在部分子命令中可用对应地Format负责把版本类型还原为可写回文件的字符串ref:、path:前缀FormatForFS则在文件系统层面把ref版本编码为ref-值形式的目录名internal/toolversions/toolversions.go。文件名也可以自定义虽然默认文件名是.tool-versions常量defaultToolVersionsFilenameDefault见 internal/config/config.go但可以通过环境变量ASDF_TOOL_VERSIONS_FILENAME或ASDF_DEFAULT_TOOL_VERSIONS_FILENAME覆盖internal/config/config.go 展示了这一解析逻辑。这为需要迁移或特殊约定的团队提供了灵活性。asdf 工作原理从 Shell 配置到垫片执行原文档用一段话概括了整体机制docs/zh-hans/guide/introduction.md一旦asdf核心在 Shell 配置中设置好之后你可以安装插件来管理特定的工具。当通过插件安装工具时安装的可执行程序会为每个可执行程序创建垫片。当你尝试运行其中一个可执行程序时将运行垫片从而让asdf识别.tool-versions文件中的工具版本并执行该版本。下面把这个流程拆解为四个环节并用仓库源码逐一印证。第一步Shell 配置单一 Shell 脚本asdf的核心以 Shell 脚本形式集成进你的 Shell 配置.bashrc/.zshrc等它只做两件关键的事导出ASDF_DIR等环境变量并把 asdf 的bin与shims目录加入PATH。本仓库的 Bats 集成测试 test/asdf_sh.bats 明确验证了这些行为exports ASDF_DIR、adds asdf dirs to PATH并且保证不会重复添加路径、在set -o nounset下也不会报错。这正是单一 Shell 脚本的简单性与熟悉性的工程化保障。第二步插件系统asdf本身不内置任何工具的安装逻辑而是通过插件Plugin把能力扩展到所有工具。插件本质上是放在 asdf 数据目录plugins/name/下的一个 Git 仓库内含bin/目录和一系列回调脚本如list-all、download、install、exec-path、list-legacy-filenames等。从 internal/plugins/plugins.go 可以看到Plugin结构体仅保存Name、Dir、Ref、URL四个字段internal/plugins/plugins.go而RunCallback则负责在插件目录中定位并执行指定名称的回调脚本。回调机制是 asdf 与 nvm 这类一工具一管理器方案的本质分水岭新增一种语言/工具不再需要一个全新的管理器只需要一个新的插件这也消除了每个管理工具不同的命令与仓库中不同的*-version文件。第三步安装工具与垫片生成当通过插件安装某个版本的工具后asdf 会为安装目录下每个可执行文件创建一个垫片shim。垫片生成的主流程在 internal/shims/shims.goGenerateAllinternal/shims/shims.go遍历所有插件GenerateForPluginVersionsinternal/shims/shims.go遍历某插件的所有已安装版本GenerateForVersioninternal/shims/shims.go枚举该版本的每个可执行文件并在调用pre_asdf_reshim_plugin/post_asdf_reshim_plugin钩子后逐个写入垫片Writeinternal/shims/shims.go垫片以0o777权限写入$ASDF_DATA_DIR/shims/可执行文件名内容记录了哪个插件的哪个版本提供了该命令。垫片目录的位置由Path/Directory计算得出即conf.DataDir/shiminternal/shims/shims.go正是第一步 Shell 配置中插入到PATH的那个目录。第四步运行时的版本解析与执行当你敲下node --version时Shell 实际命中$ASDF_DATA_DIR/shims/node这个垫片。垫片被调用后FindExecutableinternal/shims/shims.go解析垫片文件获得提供该命令的工具列表对每个工具调用resolve.Version在当前目录及上级目录中查找.tool-versions并解析出应使用的版本用toolversions.Intersect把配置的版本与垫片记录的版本取交集internal/shims/shims.go通过GetExecutablePath定位到对应版本安装目录中的真实可执行文件最终由 internal/exec/exec.go 调用syscall.Exec以真实可执行文件替换当前进程完成执行internal/exec/exec.go。这一过程中还可能遇到三种有代表性的错误分别对应三个自定义错误类型internal/shims/shims.go垫片不存在unknown command、未配置任何版本no versions set for shim、版本匹配但找不到对应可执行文件No shim executable found for tool version。另外如果插件提供了exec-path回调或自定义shim模板getCustomExecutablePath与ShimTemplatePath会优先使用它们来定制可执行文件的实际路径internal/shims/shims.go。版本解析的完整优先级版本解析是 asdf 的核心其完整顺序记录在 internal/resolve/resolve.go环境变量ASDF_TOOL_VERSION工具名大写、-转_例如ASDF_NODEJS_VERSION优先级最高internal/resolve/resolve.go逐级向上查找.tool-versions从当前目录开始向父目录逐级向上直到文件系统根目录internal/resolve/resolve.goHome 目录兜底若一路向上都未找到尝试读取用户主目录下的.tool-versionsLegacy 版本文件需开启legacy_version_file配置对支持该特性的插件读取其list-legacy-filenames回调列出的文件如.ruby-version并用parse-legacy-file回调解析版本internal/resolve/resolve.go、internal/plugins/plugins.go。也就是说项目根目录的.tool-versions覆盖上级目录这一直觉行为是由源码明确保证的——这也正是把配置文件放进 Git 仓库与团队共享能够生效的底层机制。与传统版本管理器的对比nvm / n / rbenvnvm、n、rbenv 等工具都是用 Shell 脚本实现的它们为各自工具安装的可执行程序创建垫片asdf与它们非常相似正是要在工具/运行时版本管理这个领域竞争。asdf的独特之处在于插件系统原文档 docs/zh-hans/guide/introduction.md 的表述。它一次性消除了三个痛点每个工具/运行时一个管理器→ 一个 asdf 管理所有工具每个管理器不同的命令→ 统一的asdf install/asdf local/asdf global等子命令仓库中不同的*-version文件.nvmrc、.ruby-version… → 只有一份.tool-versions。需要说明的是原文档中关于 pyenv 的对比章节目前仍是以注释形式存在的 TODOasdf has some similarities to pyenv but is missing some key features见 docs/zh-hans/guide/introduction.md说明官方对这类对比持审慎态度尚未给出正式结论。asdf 与 direnv环境变量管理的边界direnv 是根据当前所在目录动态加载和卸载环境变量来增强现有 shell 的工具。原文档明确了一个重要边界asdf不直接管理环境变量docs/zh-hans/guide/introduction.md。从源码看asdf 对环境的干预确实保持在最低限度除了 Shell 初始化脚本把 asdf 的bin/shims目录注入PATH之外运行时层面的唯一环境注入是解析ASDF_TOOL_VERSION这类输入变量以及execute.Command在运行插件回调时通过MergeWithCurrentEnv合并传入的环境internal/execute/execute.go。因此如果你需要进入某个目录时自动加载/卸载与该目录工具链相关的环境变量这类能力正确的做法是安装社区插件asdf-direnv把 direnv 的行为集成进 asdf而不是期待 asdf 核心提供该功能。asdf 与 Homebrew / NixOS为什么它不是包管理器原文档反复强调同一个观点asdf不是包管理器docs/zh-hans/guide/introduction.md。它与两类方案的定位差异如下HomebrewmacOS 或 Linux 上缺失包的管理器Homebrew 管理软件包及其上游依赖asdf不管理上游依赖依赖管理应当由用户负责asdf 只是尽力把依赖列表保持在较小规模。NixOSNix 是一种采用独特方法进行软件包管理和系统配置的工具NixOS 的目标是通过管理每个工具整个依赖关系树中软件包的确切版本来构建真正可重复的环境为此它拥有自己的编程语言、许多命令行工具和超过 60,000 个包的包集合。这是 asdf不想做的事情——asdf 只负责工具本身的版本选择与切换不染指系统级的依赖树复现。从实现角度也能印证这个边界asdf 的安装回调插件bin/install由插件作者自己编写asdf 核心只负责编排回调、记录版本、生成垫片与解析版本既不解析依赖也不编译任何包元数据。为什么使用 asdf综合原文档docs/zh-hans/guide/introduction.mdasdf 的核心价值可以归纳为三点团队版本一致性通过把.tool-versions提交进项目 Git 仓库确保团队使用完全相同的工具版本——不是大致相同而是逐字一致覆盖面广通过插件系统支持很多工具与运行时无需为每种语言维护一套独立的版本管理方案简单与熟悉它本质上只是你引入 Shell 配置中的一个Shell 脚本配合少量统一命令学习成本远低于维护多套管理器的 API 与配置文件。注意事项版本管理器 ≠ 包管理器原文档在末尾给出了一条必须遵守的边界docs/zh-hans/guide/introduction.mdasdf并不打算成为一个系统包管理器。它是一个工具版本管理器。仅仅因为你可以为任何工具创建插件并使用asdf管理其版本但这并不意味着这一定是某个特定工具的最佳实践方案。换言之能用 asdf 管理与应该用 asdf 管理是两回事。在实际选型时应当结合工具的生态惯例例如某些工具官方明确推荐自己的版本管理器以及团队的依赖管理需求做出判断而不是把 asdf 无差别地套用到所有场景。深入阅读完整介绍本文基础文档 docs/zh-hans/guide/introduction.md英文原版见 docs/guide/introduction.md快速上手docs/zh-hans/guide/getting-started.md核心实现internal/toolversions/toolversions.go、internal/resolve/resolve.go、internal/shims/shims.go、internal/plugins/plugins.go行为验证测试test/asdf_sh.bats、internal/toolversions/toolversions_test.go、internal/shims/shims_test.go【免费下载链接】asdfExtendable version manager with support for Ruby, Node.js, Elixir, Erlang more项目地址: https://gitcode.com/GitHub_Trending/as/asdf创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考