mise deps 完全指南用 providers 管理项目依赖、自动安装与新鲜度检查【免费下载链接】misedev tools, env vars, task runner项目地址: https://gitcode.com/GitHub_Trending/mi/misemise deps是 mise 的实验性依赖管理命令它把node_modules、.venv这类项目依赖与由mise install管理的版本化工具区分开来通过可插拔的 provider 机制在锁定文件变化或输出缺失时自动执行对应的包管理器命令。本文以 docs/cli/deps.md 为骨架结合 docs/dev-tools/deps.md 与 src/deps/ 源码完整讲解命令用法、配置参数、内置 provider 清单、新鲜度判定原理、monorepo 支持与自定义 provider 实战帮助你用一条mise deps取代手工的npm install、uv sync与各种代码生成步骤。命令概览Usage、别名与效果mise deps [FLAGS] [PROVIDER] [SUBCOMMAND]别名dep可见别名、prepare向后兼容的隐藏别名效果modifies state会修改项目状态源码入口src/cli/deps/mod.rs不带任何子命令运行时mise deps等价于mise deps install即对当前项目执行依赖安装流程。Providers提供方会检测自身的输入sources与已安装的输出outputs以此决定是否需要执行安装工作当你希望了解某个 provider 为何被判定为新鲜或过期时可用--explain PROVIDER查看判定细节。从源码看命令分发逻辑非常直接Deps::run()在未指定子命令时默认落入Commands::Install随后调用cmd.run().await完成执行见 src/cli/deps/mod.rs。关键概念区分[tools]负责安装包管理器本身如 node、uv[deps]负责安装项目自身的包如 npm 的 node_modules、Python 的虚拟环境。两者互补不要混淆。子命令与核心标志mise deps下共有三个子命令其完整参考文档分别位于 add、install、remove子命令作用关键参数mise deps add用ecosystem:package语法添加依赖-D --dev标记为开发依赖mise deps install安装或检查项目依赖是默认子命令见下方标志表mise deps remove用ecosystem:package语法移除依赖破坏性操作不可逆mise deps install的参数与标志[PROVIDER]— 指定只运行某个 provider也可与--explain组合使用。传入后等价于--only行为源码中当位置参数存在且未显式传--only时会自动将其并入 only 列表见 src/cli/deps/install.rs。--explain— 展示 provider 是 fresh 还是 stale 及其原因必须同时传入 provider 参数否则直接报错见 src/cli/deps/install.rs。输出内容包括Provider ID、是否 auto、Sources带/-标记表示是否存在、Outputs、可选输出、将要执行的 Command以及最终的Status: fresh/stale (原因)判定。-f --force— 即使输出是新鲜的也强制执行所有 deps 步骤。对应源码中FreshnessResult::Forced见 src/deps/mod.rs。-n --dry-run— 只检查是否需要进行依赖安装不实际执行命令。结果会以[dry-run] Would install: id (reason)形式输出。--list— 列出当前项目可用的 deps providers包括每个 provider 的 id、active/inactive 状态、sources 与 outputs。无任何 provider 时输出No deps providers found for this project。--monorepo— 从每一个显式配置的 [monorepo].config_roots 配置根安装依赖。要求 monorepo 根配置中设置monorepo_root true且显式声明[monorepo].config_roots。此时 provider 采用//apps/api:uv这种带作用域的命名。可通过环境变量MISE_MONOREPO设置。--only ONLY— 只运行指定的 deps 规则可多个。--skip SKIP— 跳过指定的 deps 规则可多个。-h --help— 打印帮助。--only与--skip的过滤逻辑在 src/deps/engine.rs 中实现provider 需要同时满足未被 skip在 only 列表内若指定若 auto_only 则必须为 auto provider三个条件才会被纳入执行候选。位置参数与 inactive provider 的校验一个值得注意的实现细节如果你显式指定了某个 provider 但它当前处于 inactive 状态例如缺少 lockfilemise deps install会在解析和安装无关的项目工具之前就报错退出避免无谓的下载见 src/cli/deps/install.rs 与validate_selection。e2e 测试 e2e/cli/test_deps 也验证了这一点在[tools] tiny 1存在但 npm provider 缺 lockfile 的场景下mise deps npm直接失败且不会安装 tiny 工具。快速上手以一个已有package.json和package-lock.json的 npm 项目为例在mise.toml中添加[settings] experimental true [tools] node 24 [deps.npm] auto true然后依次执行mise install mise deps install --list # 查看发现的 provider mise deps install npm # 只安装 npm provider mise deps install npm --explain # 解释为什么 fresh 或 stale设置auto true后后续的mise exec与mise run也会自动检查该 provider。如果项目还没有 lockfile请先用包管理器创建它例如mise exec --no-deps -- npm install--no-deps避免自动安装流程在首次创建 lockfile 时陷入循环。配置内置 provider、自定义 provider 与禁用[deps]配置段位于mise.toml顶层所有 provider内置与自定义都平铺在这一层级# 内置 npm provider自动检测 lockfile [deps.npm] auto true # 在 mise x/run 之前自动运行 # 自定义 provider [deps.codegen] auto true sources [schema/*.graphql] outputs [src/generated/] run npm run codegen # 禁用从其他配置继承来的 npm provider [deps] disable [npm]要点空表即启用只写[deps.uv]不设任何字段即可选中内置 provider但不会让它变成自动运行。disable只阻止运行不会删除已安装的包mise deps install --list可查看实际生效的 provider 集合。从源码看顶层配置结构为DepsConfig { disable: VecString, providers: BTreeMap... }采用#[serde(flatten)]展开 provider 表见 src/deps/rule.rs。Provider 配置使用deny_unknown_fields严格校验拼写错误的字段会直接报错。每个 provider 的配置归属于其配置文件所在目录根目录mise.toml中定义的[deps.pnpm]只在从根目录运行时生效从子目录运行不会触发见 src/deps/engine.rs。父目录配置文件中的 deps 会被跳过但全局/系统配置始终生效。内置 Providers 一览每个内置 provider 都自带 sources、outputs 与默认安装命令的默认值详见 docs/dev-tools/deps.md 的 Built-in Providers 表ProviderSources跟踪的输出默认命令npmpackage.json,package-lock.jsonnode_modules/npm installyarnpackage.json,yarn.locknode_modules/yarn installpnpmpackage.json,pnpm-lock.yamlnode_modules/pnpm installbunpackage.json,bun.lock或bun.lockbnode_modules/bun installdenodeno.json,deno.jsonc,package.json,deno.lock可选node_modules/deno installaubepackage.json,aube-lock.yamlnode_modules/aube installgogo.mod,go.sum可选vendor/存在vendor/时go mod vendor否则go mod downloadpiprequirements.txt可选.venv/pip install -r requirements.txtpoetrypyproject.toml,poetry.lock可选.venv/poetry installuvpyproject.toml,uv.lock可选.venv/uv syncbundlerGemfile,Gemfile.lock可选vendor/bundle/bundle installcomposercomposer.json,composer.lockvendor/composer installdartpubspec.yaml,pubspec.lock.dart_tool/package_config.jsondart pub getflutterpubspec.yaml,pubspec.lock.dart_tool/package_config.jsonflutter pub getgit-submodule.gitmodules声明的子模块目录git submodule update --init --recursive内置 provider 的完整清单在 src/deps/rule.rs 的BUILTIN_PROVIDERS常量中定义DepsEngine::build_provider负责按 ID 分发到具体实现类见 src/deps/engine.rs。注意事项必须显式配置provider 才会生效且需要具备对应项目输入文件才可用。大多数 provider 要求 lockfile 存在例外是go只需go.mod、pip只需requirements.txt、Dart/Flutter只需pubspec.yaml与git-submodule只需非空的.gitmodules。可选输出optional output只有在 mise 成功运行并观察到它之后才进行删除即失效检查。这支持了默认安装到项目目录之外的包管理器。例如 pip provider 本身不会创建或选择虚拟环境如果希望 pip 安装到.venv需要先配置 Python 虚拟环境自动激活_.python.venv。内置 provider 的默认命令是普通安装命令不保证使用冻结 lockfile。若要强制 npm 使用干净、基于 lockfile 的安装可覆盖run[deps.npm] run npm ci新鲜度检查仍然决定是否运行该命令只有当你希望命令无条件执行时才用--force。新鲜度检查Freshness Checking原理mise 使用blake3 哈希判断 sources 或有效 provider 命令自上次成功运行以来是否发生变化这是整个 deps 功能的核心机制详见 src/deps/state.rs计算所有源文件的 blake3 内容哈希计算有效 provider 命令的 blake3 哈希freshness_hash对 inline 标记、程序名、全部参数、全部环境变量、工作目录做带长度前缀的哈希保证编码无歧义见 src/deps/mod.rs与上次成功运行存入的哈希比较若源文件或有效命令被新增、删除或修改则标记该 provider 为 stale。状态文件存放在$MISE_STATE_DIR/deps/hash.toml按项目根目录为键因此不会在项目目录内写入任何内容。存储内容只包含摘要与输出路径列表从不保存原始命令或环境变量值——这也是一个不错的安全设计。判定结果共有五种FreshnessResult见 src/deps/mod.rs结果含义Fresh输出与源文件保持一致OutputsMissing一个或多个输出路径不存在Stale(reason)源文件自上次成功后发生变化NoSourcesprovider 没有 sources视为 freshForced使用了--force判定规则细节必需输出必须存在可选输出在第一次被观察到之后也必须持续存在一旦被删除即触发重新安装。可选输出的记录逻辑见DepsState::set_seen_outputssrc/deps/state.rs。有源文件跟踪时首次运行必然是 stale之后源文件或有效命令变化都会再次触发。自定义 provider 若没有 sources只要输出存在就算 fresh命令变化本身不会使其失效若 sources 和 outputs都没有则该 provider 每次都会运行。因此当命令结果依赖输入内容时务必配置真实的源文件。新鲜度检查不会逐包检查、不会查询上游是否有新版本、也不会检测未跟踪的外部包缓存被删除。若依赖文件在跟踪状态之外被改动用mise deps install provider --explain查看判定用--force修复。自定义 Providers 与全部配置选项创建自定义 provider 可以覆盖项目特有的构建步骤。以下示例假设graphql-codegen/cli和prisma已经是项目依赖且对应脚本/配置存在[deps.codegen] sources [schema/*.graphql, codegen.yml] outputs [src/generated/] run npm run codegen description Generate GraphQL types [deps.prisma] sources [prisma/schema.prisma] outputs [node_modules/.prisma/] run npx prisma generateProvider 选项参考表选项类型说明autobool在mise x和mise run之前自动运行默认falsesourcesstring[]检查变更的文件/通配模式outputsstring[]provider 被视为 fresh 所必需存在的文件/目录runstring过期时执行的命令envtable设置的环境变量dirstringsources、outputs 与命令的基准目录descriptionstring输出中显示的描述dependsstring[]必须在本 provider 之前完成的其他 provider 名称timeoutstringrun 命令的超时时间如30s、5m默认无超时这些字段与DepsProviderConfig结构体一一对应见 src/deps/rule.rs。timeout由crate::duration::parse_duration解析非法值会告警并忽略见 src/deps/mod.rs。行为语义内置 provider 在省略这些选项时使用文档记载的默认 sources/outputs一旦显式设置sources或outputs就会整体替换默认值不是追加。空数组如outputs []显式禁用该类路径跟踪同时也会禁用内置 provider 的任何可选输出。相对路径与 glob 模式从应用dir之后的 provider config root 解析绝对路径按原样使用。例如 pnpm workspace 想把安装包限制在某个应用目录下[deps.pnpm] sources [pnpm-lock.yaml, packages/app/package.json] outputs [packages/app/node_modules]run命令会被包装为sh -c执行匹配 task 的执行方式因此管道、重定向、等 shell 特性都可用见 src/deps/mod.rs。模板与环境变量provider 配置中的字符串值支持 Tera 模板如{{ config_root }}、{{ env.NAME }}、{{ vars.name }}并在 Tera 渲染之后、按照与[env]相同的env_shell_expand设置展开 shell 风格变量$NAME、${NAME:-default}[vars] package api [deps.codegen] sources [{{ config_root }}/schemas/$SCHEMA_NAME.graphql] outputs [{{ config_root }}/generated/${SCHEMA_NAME:-default}/] dir {{ config_root }} env { OUTPUT_PACKAGE {{ vars.package }}-$BUILD_MODE } run npm run codegen -- $OUTPUT_PACKAGE运行前请在环境中设置SCHEMA_NAME与BUILD_MODE。注意事项run中的$VAR表达式留给 provider 的 shell 在执行时展开因此可以在run里使用 provider 自身env表中的值而run中的 Tera 表达式在配置加载时即被渲染。需要保持为一个参数时请在run中对 shell 展开加引号如上面的$OUTPUT_PACKAGE。Provider ID 和环境变量名不支持模板非法 Tera 模板在命令启动前就会作为配置错误报告未定义的 shell 变量保持原样并给出警告可用${NAME:-}显式设为空字符串。模板渲染的完整实现含render_strings、render_env、validate_template_syntax位于 src/deps/rule.rs。添加与移除依赖mise deps add/mise deps remove包规格统一使用ecosystem:package语法前缀决定使用哪个包管理器# 添加包 mise deps add npm:react mise deps add npm:types/react19 mise deps add -D npm:vitest # 开发依赖 # 移除包 mise deps remove npm:lodash目前支持 add/remove 的生态前缀为npm、yarn、pnpm、bun、deno、aube、dart、flutter。包规格解析逻辑在parse_package_spec按第一个:切分为 (ecosystem, package)格式不对会报错invalid package spec ... expected format: ecosystem:package见 src/cli/deps/mod.rs。多个包会按生态分组批量执行例如mise deps add npm:react npm:vue pnpm:foo会分别调用一次 npm 与一次 pnpm见 src/cli/deps/add.rs。添加/移除前会先构建并安装 toolset确保 npm 等工具可用命令在带工具 PATH 的环境中执行见 src/cli/deps/add.rs。不支持的生态会报错provider xxx does not support adding/removing packages见 src/deps/mod.rs。Monorepo 支持默认情况下mise deps只运行当前配置根下的 providers。要运行所有显式配置的 monorepo 根下的 providers使用--monorepomonorepo_root true [monorepo] config_roots [apps/*, packages/*]mise deps --monorepo要点需要显式配置[monorepo].config_rootsmise不会自动搜索任意子目录来找依赖 provider。monorepo 根配置中的 providers 也会被包含因为该配置属于每个选中 config root 的层级的一部分行为与mise install --monorepo一致。Monorepo 模式下 provider ID 会带上 config root 作用域因此同一 provider 可出现在多个项目中。例如两个 uv provider 分别命名为//apps/api:uv和//apps/worker:uv需用限定名配合--only、--skip或位置参数mise deps --monorepo --only //apps/api:uv mise deps install //apps/worker:uv --monorepo不带//前缀的depends依赖在同一 config root 内解析apps/api中depends [uv]实际指向//apps/api:uv。作用域解析与回退逻辑见 src/deps/engine.rs 的ScopedDepsProvider。对单个嵌套项目而言dir选项是更简单的替代方案[deps.uv] dir apps/api依赖排序、并行执行与失败处理Providers 之间可以通过depends声明依赖一个 provider 会等待其所有依赖成功完成后才运行见 docs/dev-tools/deps.md 的 Dependencies 一节[deps.uv] auto true [deps.ansible-galaxy] auto true depends [uv] run ansible-galaxy install -r requirements.yml touch .galaxy-installed sources [requirements.yml] outputs [.galaxy-installed]语义说明depends只做顺序编排不会声明缺失的 provider也不会安装包管理器本身。无depends的 providers并行运行并发数受[settings] jobs限制如jobs 4。若某个依赖失败所有依赖它的 provider 都会被跳过循环依赖会被检测到并跳过相关 provider 同时告警。依赖方会因 inactive 依赖被跳过并给出警告见 src/deps/engine.rs 的阻断传播逻辑。自动安装Auto-Install与--no-deps当 provider 设置auto true时它会在以下命令之前自动运行mise run任务执行mise xexec 命令自动检查使用与mise deps相同的 sources 和 outputs确保跟踪的变更在执行前已被处理但不会把包升级到最新上游版本。对应实现位于 src/cli/exec.rs执行前以auto_only: true调用DepsEngine::run只运行 auto 的 providers。单次调用跳过自动安装mise run --no-deps build mise x --no-deps -- npm test过期告警Staleness Warnings使用mise activate时如果任何 auto-enabled provider 的依赖过期mise 会给出警告mise WARN deps: npm may need update, run mise deps该机制由notify_if_stale实现在 shim 模式或 quiet 模式下跳过且受settings.status.show_deps_stale控制见 src/deps/mod.rs。可关闭[settings] status.show_deps_stale false命令行速查# 安装所有项目依赖 mise deps # 只安装某个 provider mise deps install npm # 展示 provider 是 fresh 还是 stale 的原因 mise deps install npm --explain # 只展示将要运行的步骤不实际执行 mise deps install --dry-run # 即使输出新鲜也强制运行 mise deps install --force # 列出可用的 deps providers mise deps install --list # 跳过特定 provider mise deps install --skip npm # 添加 / 移除包 mise deps add npm:react mise deps remove npm:lodash完整示例全栈项目以下示例假设仓库根目录同时存在 npm 与 uv 项目、lockfile 均已提交、Prisma 是项目依赖、npm 有codegen脚本[settings] experimental true [tools] node 24 python 3.14 uv latest [deps.npm] auto true [deps.uv] auto true [deps.prisma] auto true depends [npm] sources [prisma/schema.prisma, package-lock.json] outputs [node_modules/.prisma/] run npx --no-install prisma generate [deps.frontend-codegen] depends [npm] sources [schema.graphql, codegen.ts, package-lock.json] outputs [src/generated/] run npm run codegen执行效果mise deps并行运行过期的 npm 与 uv providersprisma 与 frontend-codegen 等待 npm 完成后再相互并行codegen provider 没有auto true因此只通过显式的mise deps命令触发不会在每次mise exec或任务调用前自动运行。源码与测试速查想深入理解实现可以顺着以下路径阅读命令入口与参数定义src/cli/deps/mod.rs、src/cli/deps/install.rs、src/cli/deps/add.rs、src/cli/deps/remove.rs核心引擎发现、排序、并行执行src/deps/engine.rs配置结构、模板渲染与校验src/deps/rule.rs新鲜度状态持久化blake3 哈希src/deps/state.rsProvider 特性与命令构造src/deps/mod.rs内置 provider 实现src/deps/providers/npm、yarn、pnpm、bun、deno、go、pip、poetry、uv、bundler、composer、dart、git-submodule、custom 等e2e 行为测试e2e/cli/test_deps、e2e/cli/test_deps_builtin_path_overrides依赖管理相关的全局参考还包括 docs/dev-tools/deps.md功能总览、docs/cli/deps/add.md、docs/cli/deps/install.md、docs/cli/deps/remove.md以及 docs/cli/ 下的全部命令参考。【免费下载链接】misedev tools, env vars, task runner项目地址: https://gitcode.com/GitHub_Trending/mi/mise创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考