Zed 扩展发布前置要求全解析通过 Extension Registry 审核的合规清单与实用指南【免费下载链接】zedCode at the speed of thought – Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.项目地址: https://gitcode.com/GitHub_Trending/ze/zed在向 Zed Extension Registry 提交扩展之前作者必须逐项核对发布前置要求Publishing Prerequisites否则发布会被延迟甚至被直接拒绝。本文基于官方发布前置要求文档结合 Zed 开源仓库中 扩展清单解析实现 与真实扩展示例逐条拆解通用要求与各类型扩展语言、语言服务器、调试器、主题、图标主题、代码片段、MCP Server 等的特殊约束帮助你在提交前完成一次可自查、可落地的合规体检并据此顺畅进入 发布流程。为什么发布前必须先过“前置要求”这道关Zed 的扩展通过Extension Registry分发开发者在 扩展发布仓库 中通过 Pull Request 提交自己的扩展维护者maintainers审核通过后扩展才会被打包并发布到注册表供所有用户安装。由于审核与打包是半自动化的维护者会在发布过程中直接指出不合规之处。在提交前先在本地 Zed 中、在你将要提交的那个 submodule 提交点上手动测试你的扩展确保它能正常工作。应当发布注册表中尚不存在的功能。如果你是想改进某个已有扩展官方建议优先向该扩展本身贡献代码而不是另起炉灶具体要求见常见问题中关于“报告问题与改进”的说明。不要滥用扩展 API 去绕开其当前限制。个别情况下维护者可能酌情接受合理的工作区workaround是否接受完全由维护者裁量。只包含扩展运行所必需的资源把打包体积与攻击面都控制到最小。扩展必须使用 允许的许可证之一 授权。所有面向用户的文本必须使用英文。在发布流程publishing-guide中还有更严格的 PR 纪律每个 PR 只能新增或更新恰好一个扩展、同时最多保持3 个未关闭 PR、对维护者反馈须在3 周内响应否则 PR 会被关闭多次违规可能导致暂停甚至禁止提交。因此前置要求本质上是进入这套审核机制前的“门禁”。通用要求每个扩展都必须遵守的底线1. 使用合规的扩展 ID扩展 IDid是扩展在注册表中的唯一标识也是extension.toml与上层extensions.toml中引用扩展的键。它必须同时满足约束说明唯一unique不得与注册表中已有扩展冲突kebab-case全小写、以连字符分隔单词如my-language不含zed/extension避免与平台自身命名撞车、引起混淆能表达功能ID 应能清楚指示该扩展“提供什么”下文按类型还有更细的约定从源码看ExtensionManifest 中的id被用于注册表索引、本地缓存目录与版本管理是区分扩展归属的核心字段因此 ID 一旦定错在注册表语境下会造成歧义与维护混乱。2. 尊重扩展运行环境边界不要读取或修改Zed 为你的扩展指定的环境之外的任何内容。读取/修改环境应通过Zed Rust Extension APIzed_extension_api完成。对 Zed 提供给扩展的工作目录可以使用 Rust 标准库方法进行读写。除此之外需要用户自行完成的环境改动应明确让用户自己操作而非由扩展代为越权执行。这一约束在仓库中有完整的工程化支撑capabilities 文档 描述了扩展声明式的能力白名单扩展清单解析 中的allow_exec会校验“命令 参数”是否落在 manifest 声明的process:exec等能力范围内否则直接报错拒绝执行。也就是说“不乱动环境”不仅是审核约定也被宿主运行时强制兜底。3. 面向用户的文案全部使用英文所有在 UI、日志、提示、README 描述中展示给用户的文本必须为英文。这与 Zed 面向全球多语言用户的生态定位一致也便于维护者审核与用户搜索。4. 遵守开源许可证要求扩展必须采用注册表接受的许可证且许可证文件的命名必须以LICENSE或LICENCE开头不区分大小写以便 CI 识别。常见误区与详细说明如“许可证只需覆盖扩展自身代码不必覆盖其下载的语言服务器等外部依赖”见许可证要求。按扩展类型细分的要求不同类型扩展的“功能边界”不同前置要求也逐类收紧。一个普遍原则是扩展的类型应与其 ID、名称和实际提供的功能严格一致。这与源码中 ExtensionManifest::provides() 的思路一致——Zed 运行时正是依据 manifest 中声明的themes、icon_themes、languages、grammars、language_servers、context_servers、snippets、debug_adapters等字段推断扩展究竟提供哪些能力。语言扩展Language Extensions只支持你目标语言及其直接相关的方言不要顺手“包办”无关语言。为你提供的每一种语言都在扩展的extension.toml中定义 grammar语法。Tree-sitter grammar 通过[grammars.name]段注册指定repositorygrammar 仓库地址本地开发可用file://URL与revGit 修订版本例如[grammars.my-language] repository https://example.com/user/tree-sitter-my-language rev 58b7cac8fc14c92b0677c542610d8738c373fa81你可以额外为该语言提供语言服务器、调试器与代码片段但不强求。扩展 ID 与名称应当与主语言名接近或一致例如为 Rust 贡献语法时使用rust之类的命名语义。若扩展不提供任何语言服务器就不要包含任何 Rust 代码——纯语法类扩展保持“纯数据grammar queries language 配置”形态便于审核与分发。仓库内的 html、glsl、proto 扩展以及用于测试的 test-extension 都是语言类扩展的现成样例可作为格式与目录组织的参照。语言服务器扩展Language Server Extensions如果扩展只提供语言服务器ID 必须体现这一点例如以-language-server或-lsp作为后缀如my-language-lsp。不要把语言服务器二进制打包进扩展。应当通过 Zed Rust Extension API 在用户环境中检查/下载语言服务器而非随扩展分发。这与 Zed 扩展的“宿主负责下载运行”模型一致大型二进制随扩展分发会显著放大下载体积、升级链路与平台兼容问题。调试器扩展Debugger Extensions如果扩展只提供调试器ID 应以-debugger结尾以明确类型。与语言服务器同理不要捆绑 debug adapter应通过 Zed Rust Extension API 下载或在用户环境中检测其存在。主题扩展Theme Extensions只提供主题不夹带其他功能。ID 需体现主题属性例如以-theme结尾帮助用户在扩展列表中一眼识别。图标主题扩展Icon Theme Extensions只提供图标主题不夹带其他功能。ID 需体现图标主题属性例如以-icon-theme或-icons结尾。代码片段扩展Snippet Extensions如果扩展只提供代码片段ID 应以-snippets结尾。代码片段的作用域应克制只有确实合适时才声明为全局global面向特定语言的片段必须限定到对应语言作用域避免污染其他语言的文件。MCP Server 扩展MCP Server Extensions官方提示MCP server 扩展未来将被MCP registry取代相关进展在 Zed 仓库 issue #59351 中跟踪。建议同时把你的 server 发布到该注册表以确保在未来的 Zed 版本中可用。只提供一个 MCP server不夹带其他功能。ID 需体现 MCP server 属性例如以mcp-server-为前缀或以-mcp-server为后缀。不要把 MCP server 随扩展打包通过 Zed Rust Extension API 下载或在用户环境中检测。在源码层面MCP 对应 manifest 中的context_servers字段extension_manifest.rs并由 mcp-extensions 文档 描述其开发形态——因此这类扩展的清单声明与运行约束都能在仓库内找到对应实现。Agent Server 与 Slash Command 扩展已弃用Agent server 与 slash command 扩展已被弃用不再接受新提交。若你想在 Zed 内提供 agent server请改为将其发布到ACP RegistryAgent Client Protocol Registry。仓库中对应的slash_commands字段仍保留解析逻辑以兼容旧数据但发布侧已经关闭入口。从源码理解这些约束的底层逻辑前置要求之所以能如此“强制”是因为它对应着 Zed 扩展系统的核心安全与分发模型——声明式清单declarative manifest 能力白名单capability allowlist 宿主下载运行时。以 ExtensionManifest 为例一份典型的extension.toml会声明这些核心键id my-language name My Language version 0.0.1 schema_version 1 description ... # 声明的能力由运行时按 provides() 汇总并与注册表侧的类型约定对应 [grammars.my-language] repository https://example.com/user/tree-sitter-my-language rev ... [languages] languages/my-language ... [capabilities] # 只有显式声明的进程/下载等能力才会被宿主放行 { kind process:exec, command *, args [**] }provides()extension_manifest.rs会依据这些字段把扩展归类为Themes、IconThemes、Languages、Grammars、LanguageServers、ContextServers、Snippets、DebugAdapters等能力集合——这也解释了为什么“主题扩展只能放主题”“纯语言服务器扩展不携带 Rust 代码”这类类型纪律会成为硬性要求它保证了注册表内容的可预测性与审计成本可控。同样capabilities白名单详见 Extension Capabilities如process:exec、download_file、npm:install把“只通过 Zed Rust Extension API 与环境交互”落到实处扩展要么通过 API 沙箱化的接口访问受控资源要么被allow_exec直接拒绝从而呼应“不读取/修改指定环境之外内容”的通用要求。提交前自查清单发布前建议逐条打勾已在本机 Zed 中于提交的 submodule commit 上手动验证扩展可用提供的功能在注册表中尚不存在或已尝试向既有扩展贡献未通过滥用扩展 API 规避限制扩展 ID 唯一、kebab-case、不含zed/extension、能表明用途且符合所属类型的命名约定如-lsp、-debugger、-theme、-icon-theme、-snippets、-mcp-server打包内容仅包含运行所需资源未捆绑应下载的语言服务器/调试器/MCP server已添加被接受的许可证文件以LICENSE/LICENCE开头且位于扩展所在目录内面向用户的文本均为英文未读取/修改 Zed 指定环境之外的内容所有 IO 均经 Zed Rust Extension API 或工作目录内的标准库调用完成语言类扩展为每种语言在extension.toml中注册了 grammar且未携带多余的 Rust 代码代码片段作用域合理全局片段确有全局必要性语言特定片段已限定语言属于 Agent server / slash command 的新扩展已转为发布 ACP Registry而非提交到扩展仓库全部通过后即可按 发布指南 走 Fork、Clonegit submodule init git submodule update、以 HTTPS 方式添加 submodule、写入顶层extensions.toml条目并执行pnpm sort-extensions的流程提交 PR成功发布后可再参考 更新与维护 了解后续迭代与淘汰机制。【免费下载链接】zedCode at the speed of thought – Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.项目地址: https://gitcode.com/GitHub_Trending/ze/zed创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考