CMS后端前端插件系统【免费下载链接】emdashEmDash is a full-stack TypeScript CMS based on Astro; the spiritual successor to WordPress项目地址https://gitcode.com/gh_mirrors/emdas/emdash点击查看免费下载emdash-cms/plugin-cli二进制名emdash-plugin是 EmDash 生态中面向插件作者的官方命令行工具覆盖插件从脚手架初始化、开发构建、本地验证到 atproto PDS 发布以及基于 GitHub Actions 的委派发布全流程。本文以 packages/plugin-cli/README.md 为主体结合 plugin-cli 源码 与测试用例完整讲解每个命令的用法、emdash-plugin.jsonc清单的字段语义、发布安全模型与委派发布的授权机制。读完本文你将能够独立完成一个沙箱化 EmDash 插件的创作、构建、发布与自动化发布链路配置。一、认识 emdash-plugin一个面向 atproto 的插件工具链EmDash 的插件体系与传统 CMS 的上传 zip模式不同插件发布在发布者自己的 atproto PDSPersonal Data Server上通过实验性聚合器aggregator做索引与检索。emdash-plugin是这套体系的发布者侧工具它需要完成三类职责身份与凭据基于 atproto OAuth 的登录login、会话管理logout/whoami/switch构建与打包把src/plugin.ts构建成运行时可加载的产物build/dev/bundle发布与协作把构建产物上传到 PDS 并写入发布记录publish以及配置基于 GitHub Actions 的委派发布profile/release。需要特别强调的是当前 CLI 处于EXPERIMENTAL阶段init、build、dev、bundle、login、whoami、switch、publish已经可以针对任意 atproto PDS 工作而检索类命令search、info依赖聚合器——实验性聚合器默认指向registry.emdashcms.com该默认值定义在 src/config.ts 的DEFAULT_AGGREGATOR_URL常量中是代码里唯一需要更新的地方。由于 RFC 0001 仍在推进NSID命名空间标识符和记录结构可能变化生产环境务必固定到精确版本如emdash-cms/plugin-cli0.11.0。所有子命令都在 src/index.ts 中通过citty的defineCommand注册。注意该入口在runMain正常完成后会主动process.exit(0)——这是有意为之login/logout的 OAuth 环回 HTTP 路径会留下存活句柄导致 CLI 挂起强制退出能让你立刻回到 shell源码注释 说明了这一点。二、安装与脚手架初始化2.1 三种安装方式方式一零安装初始化推荐。用pnpm dlx直接脚手架一个插件不污染全局环境pnpm dlx emdash-cms/plugin-cli init my-plugin交互式初始化会依次收集发布者publisher、作者与安全联系信息等元数据自动探测当前使用的包管理器并在写盘前展示项目摘要供确认。脚手架产物包含一个基于 workerd 的 Vitest 测试宿主AGENTS.md规范的skills/creating-plugins技能通过.agents/skills与.claude/skills符号链接共享仓库内的技能源文件见 skills/creating-plugins/SKILL.mdClaude 指令链接覆盖全部校验与发布命令的 package scripts若选用 pnpm还会写入 pnpm 的 build-script 策略onlyBuiltDependencies之类。方式二在已有插件中安装。脚手架生成的插件已把emdash-cms/plugin-cli作为固定版本的 devDependency。若要在既有插件中使用 CLIpnpm add -D emdash-cms/plugin-cli然后统一用pnpm exec emdash-plugin运行项目命令。这样做的好处是每次执行都使用插件锁定pin的版本而不是为每条命令临时下载一个可能不同的版本。方式三全局安装npm install -g emdash-cms/plugin-cli emdash-plugin init my-plugin2.2 非交互式初始化CI 或脚本场景需要跳过交互此时必须显式提供所有权元数据pnpm dlx emdash-cms/plugin-cli init my-plugin --yes \ --publisher did:plc:abc123def456 \ --author-name Jane Doe \ --security-email securityexample.com两个补充开关--package-manager npm|pnpm|yarn|bun覆盖调用方探测结果--use-detected仅当你希望命令使用当前激活的发布者会话、本地 Git 身份或仓库元数据时使用。交互式环境的探测与元数据收集逻辑位于 src/init 目录其中 environment.ts 负责包管理器探测、scaffold.ts 与 templates.ts 负责模板渲染与文件写盘对应的行为验证见 tests/init-command.test.ts 与 tests/init-environment.test.ts。三、命令全景emdash-plugin的完整子命令如下与 README 命令表 及 src/index.ts 注册表 一致emdash-plugin init [name] Scaffold a new sandboxed plugin emdash-plugin build Build dist/ artifacts (plugin.mjs, manifest.json, index.mjs) emdash-plugin dev Watch sources and rebuild on change emdash-plugin bundle Pack dist/ assets into a registry tarball emdash-plugin publish Build, upload, and publish a release emdash-plugin profile setup Create or prepare the signed package profile emdash-plugin release setup Create the permanent GitHub release workflow emdash-plugin release plan Plan repository releases for GitHub Actions emdash-plugin release prepare slug[ver] Prepare one repository package for GitHub Actions emdash-plugin release delegate Print a publisher delegation browser handoff emdash-plugin release revoke Print an authority revocation browser handoff emdash-plugin release workload Print a workload policy browser handoff emdash-plugin release enrol Print a passkey enrolment browser handoff emdash-plugin release approve intent-id Print a passkey approval browser handoff emdash-plugin release reject intent-id Print a passkey rejection browser handoff emdash-plugin release dry-run release.json Validate delegated release admission with GitHub OIDC emdash-plugin release submit release.json Submit a delegated release with GitHub OIDC emdash-plugin release status intent-id Read a delegated release intent emdash-plugin release cancel intent-id Cancel an unpublished delegated release intent emdash-plugin validate [path] Validate emdash-plugin.jsonc against the v1 schema emdash-plugin login handle-or-did Interactive atproto OAuth login emdash-plugin logout [--did did] Revoke the active session emdash-plugin whoami Show stored sessions emdash-plugin switch did Switch the active publisher session emdash-plugin search query Free-text search emdash-plugin info handle-or-did slug Show package details or listing-check status通用约定所有非交互输出命令支持--json以输出机器可读结果检索类命令search、info支持--registry-url url或通过环境变量EMDASH_REGISTRY_URL指定聚合器info还支持--labeler-url origin或环境变量EMDASH_LABELER_URL用于那些使用其他 labeler 的注册表。URL 的解析优先级是显式 flag 环境变量 默认值实现见 src/config.ts 的resolveAggregatorUrl/resolveLabelerUrl。聚合器与 labeler 默认值均为实验性托管地址在 phase 1 切换时会退役替换依赖特定聚合器的话务必通过 flag 固定。人读输出中注册表包统一标识为publisher-handle/slug格式构建诊断需要显示 npm 包名时会额外标注为npm package。格式化逻辑集中在 src/package-identifier.tsformatPackageIdentifier、formatPackageReleaseIdentifier。四、插件创作两个文件与三个构建产物4.1 package.json 脚本一个典型插件的package.json只需两个脚本{ scripts: { build: emdash-plugin build, dev: emdash-plugin dev } }4.2 作者只需写两个文件emdash-plugin.jsonc——身份 信任契约slug、publisher 构成身份capabilities、allowedHosts、storage 构成信任契约再加上 license、author、security 等 profile 字段详见第六节。src/plugin.ts——运行时行为实现 hooks 与 routes赋值给一个emdash/plugin中SandboxedPlugin类型的常量并作为默认导出。4.3emdash-plugin build的三个产物dist/plugin.mjs ( dist/plugin.d.mts) 运行时字节码集成方进程内或沙箱 isolate加载它 dist/manifest.json 线格式清单含从 src/plugin.ts 探测出的 hooks routes dist/index.mjs ( dist/index.d.mts) 描述符模块默认导出一个裸 PluginDescriptor消费者直接 import构建的探测probing与清单生成实现在 src/manifest 与 src/build 目录bundle命令则负责把dist/与资源打包成注册表 tarball见 src/bundle其逻辑验证见 tests/bundle.test.ts 与 tests/bundle-utils.test.ts。4.4 生成测试环境跨越沙箱边界脚手架生成的vitest.config.ts用emdash-cms/plugin-test构建插件并通过cloudflare/vitest-plugin提供 D1、Worker Loader 与生产环境的PluginBridge。生成的测试通过沙箱边界调用 hooks 与 routes而不是手工构造一个残缺的PluginContext——这样测试环境与生产运行环境的隔离语义保持一致。五、发布构建、上传与审核5.1 两步发布emdash-plugin login handle-or-did emdash-plugin publishlogin走交互式 atproto OAuthloopback 流程会话状态默认存放在~/.emdash/oauthsrc/config.ts 的DEFAULT_OAUTH_DIR与emdash-cms/registry-client的凭据存储同目录方便统一清理。publish会先构建插件再把发布产物上传到你的 PDS 并写入发布记录。5.2 外部托管 bundle如果 tarball 托管在别处用--url指定emdash-plugin publish --url https://example.com/foo-1.0.0.tar.gzCLI 会下载该 URL 以校验字节并计算校验和multihash 计算见 src/multihash.tsrelease.artifacts中声明的 listing 图片仍会上传到你的 PDS。5.3 首次发布的 profile 引导首次发布必须提供--license与--security-email或--security-url来引导包 profile更推荐的方式是把它们直接写进emdash-plugin.jsonc见第六节。5.4 发布后的状态跟踪发布成功后CLI 会打印未来的公开插件页 URL 和一条info --version version --watch命令。状态命令直接读取 labeler 的有效检查结果而聚合器会把未批准的包元数据挡在公开结果之外——插件页在 listing 被批准之前保持不可用。这是发布 ≠ 立即可见的两阶段模型PDS 上已有记录但公开可见性取决于审核labeler/聚合器。六、emdash-plugin.jsonc 清单详解把emdash-plugin.jsonc放在插件的package.json旁边CLI 会自动从当前目录读取。通过内置的 JSON Schema 可获得 IDE 补全schema 生成脚本见 scripts/gen-schema.ts产物在 schemas/emdash-plugin.schema.json。{ $schema: ./node_modules/emdash-cms/plugin-cli/schemas/emdash-plugin.schema.json, slug: gallery, publisher: did:plc:abc123def456, license: MIT, author: { name: Jane Doe, url: https://example.com }, security: { email: securityexample.com }, // Optional name: Gallery, description: Image gallery block for EmDash., keywords: [gallery, images], repo: https://github.com/example/plugin-gallery, // Trust contract capabilities: [content:read], allowedHosts: [], storage: {}, }6.1 JSONC 与便捷形态清单是 JSONC允许注释与尾随逗号。多作者或多安全联系人时改用数组形态authors: [...]与securityContacts: [...]单作者形态author/security与数组形态不能混用schema 会拒绝。version可选——省略时 CLI 从相邻的package.json读取version。6.2 字段级约束源码级佐证清单的 Zod schema 在 src/manifest/schema.ts 中逐字段定义每个字段都带.meta({ description })因此约束描述会直接流进生成的 JSON Schema 成为编辑器悬停提示。关键约束字段约束说明slug小写字母开头随后为小写字母/数字/-/_≤64 字符PLUGIN_SLUG_RE与发布记录的 rkey 同语法slug publisher 构成包主键versionsemver 2.0 子集禁止build-metadataatproto 记录键字母表没有每次发布都要提升license非空 SPDX 表达式≤256 字符SPDX 语法由聚合器做最终校验首次发布必填后续发布以既有 profile 为准authorname必填url/email至少建议其一匿名但有名字的作者形态合法但会被警告securityurl与email至少有一个Lexicon 无法表达required one-ofschema 在此强制空联系人在此即失败避免进入聚合器才被拒publisher结构校验DID 语法或 handle 语法实际解析在发布时经atcute/identity-resolver完成capabilities非空字符串数组≤32 项逐项做成员校验变更信任契约必须升版本因为已安装用户同意的是旧契约allowedHosts每项 ≤256 字符禁止 scheme/路径/空白*.前缀表示子域通配≤64 项交叉规则声明了network:request且未声明network:request:unrestricted时allowedHosts必须非空storage集合名[a-z][a-z0-9_]*值含indexes/uniqueIndexes集合名会直接作为 SQL 表后缀语法必须安全requires键为env:name或包 DID值为 semver range4.16、^4.0.0与安装门禁共用emdash-cms/registry-client/env的求值器adminpages/widgets/settingsSchema/fieldWidgets/editorPanels/editorActions危险编辑动作style: danger必须带confirmsections五个 FAIR 认可键description/installation/faq/changelog/security每节 ≤20000 字节 / ≤2000 字素grapheme值可为内联 CommonMark 或{ file: ... }引用release.artifactsicon/banner单文件screenshots数组 ≤8 项图片在发布时被读取、哈希、测量像素并上传 PDS关于capabilities的另一个细节当前能力词表在 schema.ts 的CURRENT_CAPABILITIES中维护如content:read、content:write、media:write、email:send、network:request等已弃用的能力名会被硬拒绝并提示替代名isDeprecatedCapabilityCAPABILITY_RENAMES——弃用窗口只服务于已发布插件不服务新创作。6.3 清单加载与错误定位emdash-plugin validate在不发布的前提下校验清单。加载器在 src/manifest/load.ts 中实现失败路径有四个可编程错误码MANIFEST_NOT_FOUND—— 文件不存在MANIFEST_TOO_LARGE—— 超过 1 MiB 上限MANIFEST_MAX_BYTES采用预分配缓冲区 哨兵字节的无 TOCTOU有界读取MANIFEST_PARSE_ERROR—— JSONC 语法错误含行:列定位重复键duplicate key也会在此报告——这是安全设计防止git diff评审者被文件后部的恶意publisher键遮蔽顶部的诚实值MANIFEST_VALIDATION_ERROR—— 通过解析但违反 Zod schema含字段路径如authors[0].email与源码定位。错误信息刻意对齐tsc/eslint风格的指针方便 CI 与编辑器工作流。CLI 标志--license、--author-name等优先于清单值CI 场景有用--no-manifest可完全跳过清单。七、Publisher 钉扎DID 是身份handle 只是别名7.1 首次发布写回第一次成功发布后CLI 会把当前会话的 DID 写回清单作为publisher{ license: MIT, publisher: did:plc:abc123def456, ... }写回不是覆盖式编辑它用jsonc-parser的modifyapplyEdits在license之后插入保持规范顺序并嗅探原文件的缩进风格publisher.tsdetectIndent通过 tmpfile rename 原子写盘写前还会重新哈希文件做 TOCTOU 收窄——文件在发布期间被并发改动就放弃写回而不是覆盖用户编辑。若会话有 handle还会在插入的 DID 行尾追加// handle注释便于人读git diffCLI 永不读回该注释。7.2 钉扎校验与 MANIFEST_PUBLISHER_MISMATCH此后每次发布CLI 都会校验激活会话是否与钉扎的publisher一致逻辑见 src/manifest/publisher.ts 的checkPublisher错误码触发点见 src/commands/publish.tsDID 钉扎与会话 DID 逐字比较不一致即拒绝handle 钉扎发布时经atcute/identity-resolver解析为 DID 再比较解析失败会得到独立的MANIFEST_PUBLISHER_UNRESOLVED错误码以便区分handle 写错与账号不对。不匹配时发布以MANIFEST_PUBLISHER_MISMATCH拒绝防止你把插件误发到别的账号。解决方式二选一切换会话emdash-plugin switch did若在把插件转移给新发布者则更新清单中的publisherDIDs 是身份不是 handle。内部始终比较会话 DID 与钉扎 DIDhandle 钉扎只是更友好的别名。handle 是可变的如果发布者域名易主、解析器指向了不同的 DID发布会拒绝。DID 持久是长寿命插件的推荐钉扎方式。八、委派发布把发布交给 GitHub Actions委派发布解决的核心问题是让 CI 无需长期持有你的 PDS 会话凭据就能代表发布者安全地发布插件。发布者把受限授权仅创建发布记录与上传文件委派给 release-serviceGitHub Actions 工作流通过 OpenID ConnectOIDC向服务证明自己的身份。8.1 初始化release setup在插件目录而非 monorepo 根执行从其他位置运行时加--dir plugin-directorypnpm exec emdash-plugin login handle-or-did pnpm exec emdash-plugin release setup该命令从emdash-plugin.jsonc读取插件元数据与发布者若包 profile 不存在提供创建若 profile 早于委派发布功能提供在保留既有包元数据的前提下追加签名仓库与发布策略默认策略要求发布者的 Atmosphere 账户在插件权限增加时批准发布可选择 every-release 选项以要求每次发布都批准。repo可直接写进emdash-plugin.jsonc或在提示时确认规范 GitHub 仓库 URL若清单省略reposetup 会探测 Gitoriginremote 作为提示默认值。独立的emdash-plugin profile setup只准备包 profile然后展示手动发布或配置 GitHub Actions 的命令。两个 setup 命令共同支持--repository url --confirmation escalation-only|always --yesrelease setup额外支持--service-url、--action-ref、--trigger auto|changesets|tags|manual与--force。默认托管服务地址为https://releases.emdashcms.com。8.2 生成的工作流文件release setup会在Git 仓库根创建.github/workflows/emdash-release.yml嵌套的插件包复用同一工作流。审阅并提交该文件命令不会推送也不会替换已存在的其他工作流——确需替换时显式传--force。非交互环境必须传--yes接受默认批准策略无法提示且无--yes时命令宁可失败也不创建或改动 profile。8.3 三种触发变体默认--trigger auto会在 Git 仓库根探测有效的.changeset/config.json交互式询问 EmDash 应跟随 Changesets 发布、包标签还是手动运行非交互检测到 Changesets 就选它否则选包标签。Changesets 变体是可复用工作流。调用方 job 需把 Changesets Action 的published-packages输出传给它Changesets Action v1 命名该步骤输出为publishedPackagesv2 为published-packages它把 npm 包名映射到emdash-plugin.jsonc的 slug、忽略普通包、核验报告版本并将匹配的插件作为矩阵发布。对仅 EmDash 的私有包需在.changeset/config.json中同时设置privatePackages.version与privatePackages.tag为true任一缺失 setup 都会警告。包标签变体把slugversion标签解析为唯一的插件清单。手动运行接受插件 ID 并使用其清单版本。每种变体都会构建选中包、创建带签名的 GitHub 构建来源证明Sigstore attestation并发布。私有/内部 GitHub 仓库不受支持——其证明使用私有 Sigstore 信任根release verifier 不信任它。8.4 首次运行的仓库批准用拥有插件的 Atmosphere 账户登录 release-service 仪表盘并授权 EmDash 创建插件发布。然后按 setup 选择的来源触发发布让 Changesets 发布包、推送gallery1.2.3之类的包标签、或手动运行工作流。服务先核验签名的galleryprofile 确实指名了该 GitHub 仓库随后该 ref scope 的首次运行会等待并在 GitHub job summary 中追加仓库批准链接。打开链接核对仓库、工作流文件、分支或标签与环境确认连接后同一运行继续。对于从标签发起的发布仪表盘可授权所有包版本标签或仅当前标签手动运行在其分支首次使用时请求批准。确认另一 scope 是扩展连接而非替换既有 scope。仓库与工作流路径保持精确匹配当另一包签名的 profile 指名同一仓库时可复用已批准的 scope。旧包级工作流创建的策略不会给另一包复用。8.5 服务端执行链工作流把 bundle 与原始 Sigstore 证明上传到私有、瞬时的服务端存储每个请求都使用全新的 GitHub Actions OIDC token。服务核验确切字节把插件 bundle 上传到发布者的 PDS并发布一条含 PDS blob 引用的发布记录。发布的来源证明 URL 指向不可变的已核验证明。服务在接受上传前会检查包 profile 存在、包含委派发布设置、指名同一 GitHub 仓库。缺失或不兼容时以PACKAGE_PROFILE_REQUIRED失败——本地运行emdash-plugin profile setup后重启工作流即可。release-service 不能创建或编辑包 profile因为其保留的授权仅限创建发布记录与上传文件。8.6 底层自动化命令dry-run、submit、status、cancel供自定义工作流使用它们以当前 GitHub Actions OIDC 身份认证接受手工编写的 URL-source 发布记录emdash-plugin release submit release.json \ --service-url https://release.example.com \ --publisher-did did:web:publisher.example.com设EMDASH_RELEASE_SERVICE_URL与EMDASH_PUBLISHER_DID可省略两个目标 flag默认幂等键使用 GitHub run ID重跑会复用既有 intent--idempotency-key用于跨 job 重放手工编写记录中的每个包或 listing 图片产物必须使用校验和绑定的 HTTPSurl且不得含blob发布后的记录只含 PDS blob 引用不含产物来源 URL--no-wait让命令在服务接受 intent 后立即返回。status与cancel需要相同的发布者与 GitHub workload 身份emdash-plugin release status 01JABCDEFGHJKMNPQRSTVWXYZ0 emdash-plugin release cancel 01JABCDEFGHJKMNPQRSTVWXYZ0这些命令在 GitHub Actions 之外会失败无 OIDC 请求端点标准工作流请使用release setup。8.7 浏览器交接命令Atmosphere 授权与 passkey 仍是浏览器操作。以下命令打印经校验的浏览器链接而不是把 OAuth 会话或 passkey 断言复制进终端emdash-plugin release delegate --service-url https://release.example.com emdash-plugin release workload --service-url https://release.example.com emdash-plugin release enrol --service-url https://release.example.com emdash-plugin release approve 01JABCDEFGHJKMNPQRSTVWXYZ0 \ --service-url https://release.example.com \ --publisher-did did:web:publisher.example.comrelease revoke打开发布者权限撤销release reject打开拒绝仪式。服务的应用会话 cookie 与 passkey 仪式都保持在服务自己的源origin上。委派发布的完整发布者旅程release-service 授权、首次仓库批准、passkeys、故障排查可进一步参考仓库内 skills/creating-plugins 技能及其 references相关实现位于 src/release-setup.ts、src/release-prepare.ts 与 src/release-service/operations.ts行为验证见 tests/release-setup.test.ts 与 tests/release-service-operations.test.ts。九、编程 API不经子进程调用emdash-cms/plugin-cli也导出面向工具链编辑器、自定义构建脚本、其他 CLI的编程接口入口见 src/api.tsimport { buildPlugin, bundlePlugin } from emdash-cms/plugin-cli; await buildPlugin({ dir: ./my-plugin }); const result await bundlePlugin({ dir: ./my-plugin });该包还导出发布相关 APIpublishRelease、setupPackageProfile、slug/版本校验工具isPluginSlug、isPluginVersion、deriveSlugFromId、PLUGIN_SLUG_RE、PLUGIN_VERSION_RE、清单类型PluginManifest、PluginCapability、PluginStorageConfig等与sha256Multihash。其中 slug/版本工具与清单类型是从emdash-cms/plugin-types复导出——新的工具链代码应直接从emdash-cms/plugin-types导入。检索与凭据存储则从emdash-cms/registry-client导入plugin-cli是发布者侧表面bundle、publish聚合器检索与 OAuth 凭据存储属于 registry-client 的职责。十、本地开发与贡献从干净检出开始先安装再构建然后做 scoped 类型检查pnpm install pnpm build pnpm --filter emdash-cms/plugin-cli typecheck构建会产出内部工作区类型声明供 scoped typecheck 使用与 CI 的 build-then-typecheck 顺序一致对应 package.json 的 scripts。包内测试用pnpm --filter emdash-cms/plugin-cli testvitest运行覆盖清单 schema 漂移tests/schema-drift.test.ts、publisher 钉扎tests/manifest-publisher.test.ts、发布流程tests/publish.test.ts等关键路径其中 tests/fixtures 提供了minimal-plugin与bad-plugin两个对照样本。结语从脚手架到持续发布的完整闭环回到开篇的流程图式理解emdash-plugin把插件生命周期组织成三条清晰的路径——本地创作init→ 手写emdash-plugin.jsoncsrc/plugin.ts→build/dev/bundle、手动发布login→publishDID 钉扎保证账号正确、labeler/聚合器把关公开可见性、委派发布release setup生成工作流GitHub OIDC 仓库批准 Atmosphere 授权共同构成最小权限链。无论走哪条路径emdash-plugin.jsonc都是单一事实来源身份、信任契约与 profile 都在一个可 IDE 补全的 JSONC 文件中schema 的严格模式与行:列错误定位让配置错误在本地而非线上暴露。对于任何准备把插件交付给 EmDash 用户的开发者这套工具链值得按本文顺序完整走一遍。赞分享CMS后端前端插件系统【免费下载链接】emdashEmDash is a full-stack TypeScript CMS based on Astro; the spiritual successor to WordPress项目地址https://gitcode.com/gh_mirrors/emdas/emdash点击查看免费下载相关推荐AERIS-10开源相控阵雷达:几万元预算自制10.5GHz探测系统AERIS 10开源相控阵雷达:几万元预算自制10.5GHz探测系统 AERIS 10 是一套完全开源的 10.5 GHz 脉冲线性调频 PLFM,即发射信号频CMS后端前端插件系统Handsontable 插件开发完全指南从插件契约、生命周期到注册清单的实战手册Handsontable 插件开发完全指南从插件契约、生命周期到注册清单的实战手册 Handsontable 的插件系统是其可扩展性的核心全部 40 余个内前端UI组件vConsole 插件 Event 事件列表全解析从 init 到 remove 的完整生命周期指南vConsole 插件 Event 事件列表全解析从 init 到 remove 的完整生命周期指南 vConsole 为插件开发者提供了一套完整的事件Ev前端开发工具调试器上一篇如何使用ReflectionDocBlockPHP文档注释解析的终极指南下一篇Leaflet-search未来展望地图搜索技术的发展趋势与路线图创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/23 17:02:44 · 阅读 1.2k EmDash 插件 CLI 实战指南：从 init 脚手架到委派发布的插件全生命周期
CMS后端前端插件系统【免费下载链接】emdashEmDash is a full-stack TypeScript CMS based on Astro; the spiritual successor to WordPress项目地址https://gitcode.com/gh_mirrors/emdas/emdash点击查看免费下载emdash-cms/plugin-cli二进制名emdash-plugin是 EmDash 生态中面向插件作者的官方命令行工具覆盖插件从脚手架初始化、开发构建、本地验证到 atproto PDS 发布以及基于 GitHub Actions 的委派发布全流程。本文以 packages/plugin-cli/README.md 为主体结合 plugin-cli 源码 与测试用例完整讲解每个命令的用法、emdash-plugin.jsonc清单的字段语义、发布安全模型与委派发布的授权机制。读完本文你将能够独立完成一个沙箱化 EmDash 插件的创作、构建、发布与自动化发布链路配置。一、认识 emdash-plugin一个面向 atproto 的插件工具链EmDash 的插件体系与传统 CMS 的上传 zip模式不同插件发布在发布者自己的 atproto PDSPersonal Data Server上通过实验性聚合器aggregator做索引与检索。emdash-plugin是这套体系的发布者侧工具它需要完成三类职责身份与凭据基于 atproto OAuth 的登录login、会话管理logout/whoami/switch构建与打包把src/plugin.ts构建成运行时可加载的产物build/dev/bundle发布与协作把构建产物上传到 PDS 并写入发布记录publish以及配置基于 GitHub Actions 的委派发布profile/release。需要特别强调的是当前 CLI 处于EXPERIMENTAL阶段init、build、dev、bundle、login、whoami、switch、publish已经可以针对任意 atproto PDS 工作而检索类命令search、info依赖聚合器——实验性聚合器默认指向registry.emdashcms.com该默认值定义在 src/config.ts 的DEFAULT_AGGREGATOR_URL常量中是代码里唯一需要更新的地方。由于 RFC 0001 仍在推进NSID命名空间标识符和记录结构可能变化生产环境务必固定到精确版本如emdash-cms/plugin-cli0.11.0。所有子命令都在 src/index.ts 中通过citty的defineCommand注册。注意该入口在runMain正常完成后会主动process.exit(0)——这是有意为之login/logout的 OAuth 环回 HTTP 路径会留下存活句柄导致 CLI 挂起强制退出能让你立刻回到 shell源码注释 说明了这一点。二、安装与脚手架初始化2.1 三种安装方式方式一零安装初始化推荐。用pnpm dlx直接脚手架一个插件不污染全局环境pnpm dlx emdash-cms/plugin-cli init my-plugin交互式初始化会依次收集发布者publisher、作者与安全联系信息等元数据自动探测当前使用的包管理器并在写盘前展示项目摘要供确认。脚手架产物包含一个基于 workerd 的 Vitest 测试宿主AGENTS.md规范的skills/creating-plugins技能通过.agents/skills与.claude/skills符号链接共享仓库内的技能源文件见 skills/creating-plugins/SKILL.mdClaude 指令链接覆盖全部校验与发布命令的 package scripts若选用 pnpm还会写入 pnpm 的 build-script 策略onlyBuiltDependencies之类。方式二在已有插件中安装。脚手架生成的插件已把emdash-cms/plugin-cli作为固定版本的 devDependency。若要在既有插件中使用 CLIpnpm add -D emdash-cms/plugin-cli然后统一用pnpm exec emdash-plugin运行项目命令。这样做的好处是每次执行都使用插件锁定pin的版本而不是为每条命令临时下载一个可能不同的版本。方式三全局安装npm install -g emdash-cms/plugin-cli emdash-plugin init my-plugin2.2 非交互式初始化CI 或脚本场景需要跳过交互此时必须显式提供所有权元数据pnpm dlx emdash-cms/plugin-cli init my-plugin --yes \ --publisher did:plc:abc123def456 \ --author-name Jane Doe \ --security-email securityexample.com两个补充开关--package-manager npm|pnpm|yarn|bun覆盖调用方探测结果--use-detected仅当你希望命令使用当前激活的发布者会话、本地 Git 身份或仓库元数据时使用。交互式环境的探测与元数据收集逻辑位于 src/init 目录其中 environment.ts 负责包管理器探测、scaffold.ts 与 templates.ts 负责模板渲染与文件写盘对应的行为验证见 tests/init-command.test.ts 与 tests/init-environment.test.ts。三、命令全景emdash-plugin的完整子命令如下与 README 命令表 及 src/index.ts 注册表 一致emdash-plugin init [name] Scaffold a new sandboxed plugin emdash-plugin build Build dist/ artifacts (plugin.mjs, manifest.json, index.mjs) emdash-plugin dev Watch sources and rebuild on change emdash-plugin bundle Pack dist/ assets into a registry tarball emdash-plugin publish Build, upload, and publish a release emdash-plugin profile setup Create or prepare the signed package profile emdash-plugin release setup Create the permanent GitHub release workflow emdash-plugin release plan Plan repository releases for GitHub Actions emdash-plugin release prepare slug[ver] Prepare one repository package for GitHub Actions emdash-plugin release delegate Print a publisher delegation browser handoff emdash-plugin release revoke Print an authority revocation browser handoff emdash-plugin release workload Print a workload policy browser handoff emdash-plugin release enrol Print a passkey enrolment browser handoff emdash-plugin release approve intent-id Print a passkey approval browser handoff emdash-plugin release reject intent-id Print a passkey rejection browser handoff emdash-plugin release dry-run release.json Validate delegated release admission with GitHub OIDC emdash-plugin release submit release.json Submit a delegated release with GitHub OIDC emdash-plugin release status intent-id Read a delegated release intent emdash-plugin release cancel intent-id Cancel an unpublished delegated release intent emdash-plugin validate [path] Validate emdash-plugin.jsonc against the v1 schema emdash-plugin login handle-or-did Interactive atproto OAuth login emdash-plugin logout [--did did] Revoke the active session emdash-plugin whoami Show stored sessions emdash-plugin switch did Switch the active publisher session emdash-plugin search query Free-text search emdash-plugin info handle-or-did slug Show package details or listing-check status通用约定所有非交互输出命令支持--json以输出机器可读结果检索类命令search、info支持--registry-url url或通过环境变量EMDASH_REGISTRY_URL指定聚合器info还支持--labeler-url origin或环境变量EMDASH_LABELER_URL用于那些使用其他 labeler 的注册表。URL 的解析优先级是显式 flag 环境变量 默认值实现见 src/config.ts 的resolveAggregatorUrl/resolveLabelerUrl。聚合器与 labeler 默认值均为实验性托管地址在 phase 1 切换时会退役替换依赖特定聚合器的话务必通过 flag 固定。人读输出中注册表包统一标识为publisher-handle/slug格式构建诊断需要显示 npm 包名时会额外标注为npm package。格式化逻辑集中在 src/package-identifier.tsformatPackageIdentifier、formatPackageReleaseIdentifier。四、插件创作两个文件与三个构建产物4.1 package.json 脚本一个典型插件的package.json只需两个脚本{ scripts: { build: emdash-plugin build, dev: emdash-plugin dev } }4.2 作者只需写两个文件emdash-plugin.jsonc——身份 信任契约slug、publisher 构成身份capabilities、allowedHosts、storage 构成信任契约再加上 license、author、security 等 profile 字段详见第六节。src/plugin.ts——运行时行为实现 hooks 与 routes赋值给一个emdash/plugin中SandboxedPlugin类型的常量并作为默认导出。4.3emdash-plugin build的三个产物dist/plugin.mjs ( dist/plugin.d.mts) 运行时字节码集成方进程内或沙箱 isolate加载它 dist/manifest.json 线格式清单含从 src/plugin.ts 探测出的 hooks routes dist/index.mjs ( dist/index.d.mts) 描述符模块默认导出一个裸 PluginDescriptor消费者直接 import构建的探测probing与清单生成实现在 src/manifest 与 src/build 目录bundle命令则负责把dist/与资源打包成注册表 tarball见 src/bundle其逻辑验证见 tests/bundle.test.ts 与 tests/bundle-utils.test.ts。4.4 生成测试环境跨越沙箱边界脚手架生成的vitest.config.ts用emdash-cms/plugin-test构建插件并通过cloudflare/vitest-plugin提供 D1、Worker Loader 与生产环境的PluginBridge。生成的测试通过沙箱边界调用 hooks 与 routes而不是手工构造一个残缺的PluginContext——这样测试环境与生产运行环境的隔离语义保持一致。五、发布构建、上传与审核5.1 两步发布emdash-plugin login handle-or-did emdash-plugin publishlogin走交互式 atproto OAuthloopback 流程会话状态默认存放在~/.emdash/oauthsrc/config.ts 的DEFAULT_OAUTH_DIR与emdash-cms/registry-client的凭据存储同目录方便统一清理。publish会先构建插件再把发布产物上传到你的 PDS 并写入发布记录。5.2 外部托管 bundle如果 tarball 托管在别处用--url指定emdash-plugin publish --url https://example.com/foo-1.0.0.tar.gzCLI 会下载该 URL 以校验字节并计算校验和multihash 计算见 src/multihash.tsrelease.artifacts中声明的 listing 图片仍会上传到你的 PDS。5.3 首次发布的 profile 引导首次发布必须提供--license与--security-email或--security-url来引导包 profile更推荐的方式是把它们直接写进emdash-plugin.jsonc见第六节。5.4 发布后的状态跟踪发布成功后CLI 会打印未来的公开插件页 URL 和一条info --version version --watch命令。状态命令直接读取 labeler 的有效检查结果而聚合器会把未批准的包元数据挡在公开结果之外——插件页在 listing 被批准之前保持不可用。这是发布 ≠ 立即可见的两阶段模型PDS 上已有记录但公开可见性取决于审核labeler/聚合器。六、emdash-plugin.jsonc 清单详解把emdash-plugin.jsonc放在插件的package.json旁边CLI 会自动从当前目录读取。通过内置的 JSON Schema 可获得 IDE 补全schema 生成脚本见 scripts/gen-schema.ts产物在 schemas/emdash-plugin.schema.json。{ $schema: ./node_modules/emdash-cms/plugin-cli/schemas/emdash-plugin.schema.json, slug: gallery, publisher: did:plc:abc123def456, license: MIT, author: { name: Jane Doe, url: https://example.com }, security: { email: securityexample.com }, // Optional name: Gallery, description: Image gallery block for EmDash., keywords: [gallery, images], repo: https://github.com/example/plugin-gallery, // Trust contract capabilities: [content:read], allowedHosts: [], storage: {}, }6.1 JSONC 与便捷形态清单是 JSONC允许注释与尾随逗号。多作者或多安全联系人时改用数组形态authors: [...]与securityContacts: [...]单作者形态author/security与数组形态不能混用schema 会拒绝。version可选——省略时 CLI 从相邻的package.json读取version。6.2 字段级约束源码级佐证清单的 Zod schema 在 src/manifest/schema.ts 中逐字段定义每个字段都带.meta({ description })因此约束描述会直接流进生成的 JSON Schema 成为编辑器悬停提示。关键约束字段约束说明slug小写字母开头随后为小写字母/数字/-/_≤64 字符PLUGIN_SLUG_RE与发布记录的 rkey 同语法slug publisher 构成包主键versionsemver 2.0 子集禁止build-metadataatproto 记录键字母表没有每次发布都要提升license非空 SPDX 表达式≤256 字符SPDX 语法由聚合器做最终校验首次发布必填后续发布以既有 profile 为准authorname必填url/email至少建议其一匿名但有名字的作者形态合法但会被警告securityurl与email至少有一个Lexicon 无法表达required one-ofschema 在此强制空联系人在此即失败避免进入聚合器才被拒publisher结构校验DID 语法或 handle 语法实际解析在发布时经atcute/identity-resolver完成capabilities非空字符串数组≤32 项逐项做成员校验变更信任契约必须升版本因为已安装用户同意的是旧契约allowedHosts每项 ≤256 字符禁止 scheme/路径/空白*.前缀表示子域通配≤64 项交叉规则声明了network:request且未声明network:request:unrestricted时allowedHosts必须非空storage集合名[a-z][a-z0-9_]*值含indexes/uniqueIndexes集合名会直接作为 SQL 表后缀语法必须安全requires键为env:name或包 DID值为 semver range4.16、^4.0.0与安装门禁共用emdash-cms/registry-client/env的求值器adminpages/widgets/settingsSchema/fieldWidgets/editorPanels/editorActions危险编辑动作style: danger必须带confirmsections五个 FAIR 认可键description/installation/faq/changelog/security每节 ≤20000 字节 / ≤2000 字素grapheme值可为内联 CommonMark 或{ file: ... }引用release.artifactsicon/banner单文件screenshots数组 ≤8 项图片在发布时被读取、哈希、测量像素并上传 PDS关于capabilities的另一个细节当前能力词表在 schema.ts 的CURRENT_CAPABILITIES中维护如content:read、content:write、media:write、email:send、network:request等已弃用的能力名会被硬拒绝并提示替代名isDeprecatedCapabilityCAPABILITY_RENAMES——弃用窗口只服务于已发布插件不服务新创作。6.3 清单加载与错误定位emdash-plugin validate在不发布的前提下校验清单。加载器在 src/manifest/load.ts 中实现失败路径有四个可编程错误码MANIFEST_NOT_FOUND—— 文件不存在MANIFEST_TOO_LARGE—— 超过 1 MiB 上限MANIFEST_MAX_BYTES采用预分配缓冲区 哨兵字节的无 TOCTOU有界读取MANIFEST_PARSE_ERROR—— JSONC 语法错误含行:列定位重复键duplicate key也会在此报告——这是安全设计防止git diff评审者被文件后部的恶意publisher键遮蔽顶部的诚实值MANIFEST_VALIDATION_ERROR—— 通过解析但违反 Zod schema含字段路径如authors[0].email与源码定位。错误信息刻意对齐tsc/eslint风格的指针方便 CI 与编辑器工作流。CLI 标志--license、--author-name等优先于清单值CI 场景有用--no-manifest可完全跳过清单。七、Publisher 钉扎DID 是身份handle 只是别名7.1 首次发布写回第一次成功发布后CLI 会把当前会话的 DID 写回清单作为publisher{ license: MIT, publisher: did:plc:abc123def456, ... }写回不是覆盖式编辑它用jsonc-parser的modifyapplyEdits在license之后插入保持规范顺序并嗅探原文件的缩进风格publisher.tsdetectIndent通过 tmpfile rename 原子写盘写前还会重新哈希文件做 TOCTOU 收窄——文件在发布期间被并发改动就放弃写回而不是覆盖用户编辑。若会话有 handle还会在插入的 DID 行尾追加// handle注释便于人读git diffCLI 永不读回该注释。7.2 钉扎校验与 MANIFEST_PUBLISHER_MISMATCH此后每次发布CLI 都会校验激活会话是否与钉扎的publisher一致逻辑见 src/manifest/publisher.ts 的checkPublisher错误码触发点见 src/commands/publish.tsDID 钉扎与会话 DID 逐字比较不一致即拒绝handle 钉扎发布时经atcute/identity-resolver解析为 DID 再比较解析失败会得到独立的MANIFEST_PUBLISHER_UNRESOLVED错误码以便区分handle 写错与账号不对。不匹配时发布以MANIFEST_PUBLISHER_MISMATCH拒绝防止你把插件误发到别的账号。解决方式二选一切换会话emdash-plugin switch did若在把插件转移给新发布者则更新清单中的publisherDIDs 是身份不是 handle。内部始终比较会话 DID 与钉扎 DIDhandle 钉扎只是更友好的别名。handle 是可变的如果发布者域名易主、解析器指向了不同的 DID发布会拒绝。DID 持久是长寿命插件的推荐钉扎方式。八、委派发布把发布交给 GitHub Actions委派发布解决的核心问题是让 CI 无需长期持有你的 PDS 会话凭据就能代表发布者安全地发布插件。发布者把受限授权仅创建发布记录与上传文件委派给 release-serviceGitHub Actions 工作流通过 OpenID ConnectOIDC向服务证明自己的身份。8.1 初始化release setup在插件目录而非 monorepo 根执行从其他位置运行时加--dir plugin-directorypnpm exec emdash-plugin login handle-or-did pnpm exec emdash-plugin release setup该命令从emdash-plugin.jsonc读取插件元数据与发布者若包 profile 不存在提供创建若 profile 早于委派发布功能提供在保留既有包元数据的前提下追加签名仓库与发布策略默认策略要求发布者的 Atmosphere 账户在插件权限增加时批准发布可选择 every-release 选项以要求每次发布都批准。repo可直接写进emdash-plugin.jsonc或在提示时确认规范 GitHub 仓库 URL若清单省略reposetup 会探测 Gitoriginremote 作为提示默认值。独立的emdash-plugin profile setup只准备包 profile然后展示手动发布或配置 GitHub Actions 的命令。两个 setup 命令共同支持--repository url --confirmation escalation-only|always --yesrelease setup额外支持--service-url、--action-ref、--trigger auto|changesets|tags|manual与--force。默认托管服务地址为https://releases.emdashcms.com。8.2 生成的工作流文件release setup会在Git 仓库根创建.github/workflows/emdash-release.yml嵌套的插件包复用同一工作流。审阅并提交该文件命令不会推送也不会替换已存在的其他工作流——确需替换时显式传--force。非交互环境必须传--yes接受默认批准策略无法提示且无--yes时命令宁可失败也不创建或改动 profile。8.3 三种触发变体默认--trigger auto会在 Git 仓库根探测有效的.changeset/config.json交互式询问 EmDash 应跟随 Changesets 发布、包标签还是手动运行非交互检测到 Changesets 就选它否则选包标签。Changesets 变体是可复用工作流。调用方 job 需把 Changesets Action 的published-packages输出传给它Changesets Action v1 命名该步骤输出为publishedPackagesv2 为published-packages它把 npm 包名映射到emdash-plugin.jsonc的 slug、忽略普通包、核验报告版本并将匹配的插件作为矩阵发布。对仅 EmDash 的私有包需在.changeset/config.json中同时设置privatePackages.version与privatePackages.tag为true任一缺失 setup 都会警告。包标签变体把slugversion标签解析为唯一的插件清单。手动运行接受插件 ID 并使用其清单版本。每种变体都会构建选中包、创建带签名的 GitHub 构建来源证明Sigstore attestation并发布。私有/内部 GitHub 仓库不受支持——其证明使用私有 Sigstore 信任根release verifier 不信任它。8.4 首次运行的仓库批准用拥有插件的 Atmosphere 账户登录 release-service 仪表盘并授权 EmDash 创建插件发布。然后按 setup 选择的来源触发发布让 Changesets 发布包、推送gallery1.2.3之类的包标签、或手动运行工作流。服务先核验签名的galleryprofile 确实指名了该 GitHub 仓库随后该 ref scope 的首次运行会等待并在 GitHub job summary 中追加仓库批准链接。打开链接核对仓库、工作流文件、分支或标签与环境确认连接后同一运行继续。对于从标签发起的发布仪表盘可授权所有包版本标签或仅当前标签手动运行在其分支首次使用时请求批准。确认另一 scope 是扩展连接而非替换既有 scope。仓库与工作流路径保持精确匹配当另一包签名的 profile 指名同一仓库时可复用已批准的 scope。旧包级工作流创建的策略不会给另一包复用。8.5 服务端执行链工作流把 bundle 与原始 Sigstore 证明上传到私有、瞬时的服务端存储每个请求都使用全新的 GitHub Actions OIDC token。服务核验确切字节把插件 bundle 上传到发布者的 PDS并发布一条含 PDS blob 引用的发布记录。发布的来源证明 URL 指向不可变的已核验证明。服务在接受上传前会检查包 profile 存在、包含委派发布设置、指名同一 GitHub 仓库。缺失或不兼容时以PACKAGE_PROFILE_REQUIRED失败——本地运行emdash-plugin profile setup后重启工作流即可。release-service 不能创建或编辑包 profile因为其保留的授权仅限创建发布记录与上传文件。8.6 底层自动化命令dry-run、submit、status、cancel供自定义工作流使用它们以当前 GitHub Actions OIDC 身份认证接受手工编写的 URL-source 发布记录emdash-plugin release submit release.json \ --service-url https://release.example.com \ --publisher-did did:web:publisher.example.com设EMDASH_RELEASE_SERVICE_URL与EMDASH_PUBLISHER_DID可省略两个目标 flag默认幂等键使用 GitHub run ID重跑会复用既有 intent--idempotency-key用于跨 job 重放手工编写记录中的每个包或 listing 图片产物必须使用校验和绑定的 HTTPSurl且不得含blob发布后的记录只含 PDS blob 引用不含产物来源 URL--no-wait让命令在服务接受 intent 后立即返回。status与cancel需要相同的发布者与 GitHub workload 身份emdash-plugin release status 01JABCDEFGHJKMNPQRSTVWXYZ0 emdash-plugin release cancel 01JABCDEFGHJKMNPQRSTVWXYZ0这些命令在 GitHub Actions 之外会失败无 OIDC 请求端点标准工作流请使用release setup。8.7 浏览器交接命令Atmosphere 授权与 passkey 仍是浏览器操作。以下命令打印经校验的浏览器链接而不是把 OAuth 会话或 passkey 断言复制进终端emdash-plugin release delegate --service-url https://release.example.com emdash-plugin release workload --service-url https://release.example.com emdash-plugin release enrol --service-url https://release.example.com emdash-plugin release approve 01JABCDEFGHJKMNPQRSTVWXYZ0 \ --service-url https://release.example.com \ --publisher-did did:web:publisher.example.comrelease revoke打开发布者权限撤销release reject打开拒绝仪式。服务的应用会话 cookie 与 passkey 仪式都保持在服务自己的源origin上。委派发布的完整发布者旅程release-service 授权、首次仓库批准、passkeys、故障排查可进一步参考仓库内 skills/creating-plugins 技能及其 references相关实现位于 src/release-setup.ts、src/release-prepare.ts 与 src/release-service/operations.ts行为验证见 tests/release-setup.test.ts 与 tests/release-service-operations.test.ts。九、编程 API不经子进程调用emdash-cms/plugin-cli也导出面向工具链编辑器、自定义构建脚本、其他 CLI的编程接口入口见 src/api.tsimport { buildPlugin, bundlePlugin } from emdash-cms/plugin-cli; await buildPlugin({ dir: ./my-plugin }); const result await bundlePlugin({ dir: ./my-plugin });该包还导出发布相关 APIpublishRelease、setupPackageProfile、slug/版本校验工具isPluginSlug、isPluginVersion、deriveSlugFromId、PLUGIN_SLUG_RE、PLUGIN_VERSION_RE、清单类型PluginManifest、PluginCapability、PluginStorageConfig等与sha256Multihash。其中 slug/版本工具与清单类型是从emdash-cms/plugin-types复导出——新的工具链代码应直接从emdash-cms/plugin-types导入。检索与凭据存储则从emdash-cms/registry-client导入plugin-cli是发布者侧表面bundle、publish聚合器检索与 OAuth 凭据存储属于 registry-client 的职责。十、本地开发与贡献从干净检出开始先安装再构建然后做 scoped 类型检查pnpm install pnpm build pnpm --filter emdash-cms/plugin-cli typecheck构建会产出内部工作区类型声明供 scoped typecheck 使用与 CI 的 build-then-typecheck 顺序一致对应 package.json 的 scripts。包内测试用pnpm --filter emdash-cms/plugin-cli testvitest运行覆盖清单 schema 漂移tests/schema-drift.test.ts、publisher 钉扎tests/manifest-publisher.test.ts、发布流程tests/publish.test.ts等关键路径其中 tests/fixtures 提供了minimal-plugin与bad-plugin两个对照样本。结语从脚手架到持续发布的完整闭环回到开篇的流程图式理解emdash-plugin把插件生命周期组织成三条清晰的路径——本地创作init→ 手写emdash-plugin.jsoncsrc/plugin.ts→build/dev/bundle、手动发布login→publishDID 钉扎保证账号正确、labeler/聚合器把关公开可见性、委派发布release setup生成工作流GitHub OIDC 仓库批准 Atmosphere 授权共同构成最小权限链。无论走哪条路径emdash-plugin.jsonc都是单一事实来源身份、信任契约与 profile 都在一个可 IDE 补全的 JSONC 文件中schema 的严格模式与行:列错误定位让配置错误在本地而非线上暴露。对于任何准备把插件交付给 EmDash 用户的开发者这套工具链值得按本文顺序完整走一遍。赞分享CMS后端前端插件系统【免费下载链接】emdashEmDash is a full-stack TypeScript CMS based on Astro; the spiritual successor to WordPress项目地址https://gitcode.com/gh_mirrors/emdas/emdash点击查看免费下载相关推荐AERIS-10开源相控阵雷达:几万元预算自制10.5GHz探测系统AERIS 10开源相控阵雷达:几万元预算自制10.5GHz探测系统 AERIS 10 是一套完全开源的 10.5 GHz 脉冲线性调频 PLFM,即发射信号频CMS后端前端插件系统Handsontable 插件开发完全指南从插件契约、生命周期到注册清单的实战手册Handsontable 插件开发完全指南从插件契约、生命周期到注册清单的实战手册 Handsontable 的插件系统是其可扩展性的核心全部 40 余个内前端UI组件vConsole 插件 Event 事件列表全解析从 init 到 remove 的完整生命周期指南vConsole 插件 Event 事件列表全解析从 init 到 remove 的完整生命周期指南 vConsole 为插件开发者提供了一套完整的事件Ev前端开发工具调试器上一篇如何使用ReflectionDocBlockPHP文档注释解析的终极指南下一篇Leaflet-search未来展望地图搜索技术的发展趋势与路线图创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考