emdash-github-actions

分类: 工具与效率 | 上传者: jdevalk | 下载: 0 | 版本: v1.0（最新）

为 EmDash 插件设置 GitHub Actions CI/CD 工作流程 — TypeScript 类型检查、ESLint linting、Vitest 测试、npm 发布和自动发布。当用户想要为 EmDash 插件创建、添加、设置或配置 GitHub Actions、CI/CD、自动检查或部署工作流程时，请始终使用此技能 - 即使他们不使用确切的短语“GitHub Actions”。这包括任何以下请求：向 EmDash 插件存储库添加自动类型检查或 linting；在 CI 中为插件设置测试；自动从 GitHub 将插件发布到 npm；将安全扫描或依赖项审核添加到插件管道；或者通常“添加 CI”、“添加自动检查”、“设置工作流程”或“自动化”与 EmDash 插件的 GitHub 存储库相关的任何内容。当有人想要对 PR 进行质量控制或正在设置新的 EmDash 插件存储库并想要自动化的最佳实践时也会触发。如果用户位于 EmDash 插件存储库中并提及有关自动化测试、代码质量、部署或 GitHub 工作流程的任何内容，请使用此技能。 --- # EmDash 插件 GitHub Actions 此技能可帮助您使用 GitHub Actions 为 EmDash 插件设置全面的 CI/CD 管道。 EmDash 是一个基于 Astro 的全栈 TypeScript CMS，因此它的插件生态系统完全基于 TypeScript。 ## 这项技能涵盖的内容一个健康的 EmDash 插件应该具备几个类别的工作流程。并非每个插件都需要所有这些 - 正确的组合取决于插件的复杂性、是否有 React 管理 UI、是否有测试等。您的工作是找出哪些是相关的并进行设置。

更新日志: Source: GitHub https://github.com/jdevalk/skills

目录结构

当前层级: tree/main/emdash-github-actions/

📁 references/
- 📄 workflows.md 9.6 KB
📄 SKILL.md 6.5 KB

SKILL.md

---
name: emdash-github-actions
description: |
  Sets up GitHub Actions CI/CD workflows for EmDash plugins — TypeScript type-checking, ESLint linting, Vitest testing, npm publishing, and automated releases. ALWAYS use this skill when a user wants to create, add, set up, or configure GitHub Actions, CI/CD, automated checks, or deployment workflows for an EmDash plugin — even if they don't use the exact phrase "GitHub Actions". This includes any request to: add automated type-checking or linting to an EmDash plugin repo; set up testing in CI for a plugin; auto-publish a plugin to npm from GitHub; add security scanning or dependency auditing to a plugin pipeline; or generally "add CI", "add automated checks", "set up workflows", or "automate" anything related to an EmDash plugin's GitHub repository. Also trigger when someone wants quality gates on PRs or is setting up a new EmDash plugin repo and wants best practices for automation. If the user is inside an EmDash plugin repository and mentions anything about automated testing, code quality, deployment, or GitHub workflows, use this skill.
---

# EmDash Plugin GitHub Actions

This skill helps you set up a comprehensive CI/CD pipeline for EmDash plugins using GitHub Actions. EmDash is a full-stack TypeScript CMS based on Astro, so its plugin ecosystem is entirely TypeScript-based.

## What this skill covers

There are several categories of workflows that a healthy EmDash plugin should have. Not every plugin needs all of them — the right mix depends on the plugin's complexity, whether it has a React admin UI, whether it has tests, etc. Your job is to figure out which ones are relevant and set them up.

The workflows fall into these categories:

1. **Type checking** — TypeScript strict mode with emdash peer dependency
2. **Code quality** — ESLint with TypeScript support
3. **Testing** — Vitest or similar TypeScript-native test runner
4. **Security** — npm audit for dependency vulnerabilities
5. **Deployment** — Automated npm publish on tag/release

Read `references/workflows.md` for the detailed configuration of each workflow, including ready-to-use YAML templates and configuration files.

## How to approach a request

### Step 1: Understand the plugin

Before writing any workflow files, figure out what you're working with:

- **What does the plugin do?** Check the `package.json` description and `src/index.ts` exports. EmDash plugins typically hook into `page:metadata`, `page:fragment`, content hooks, or provide admin UI.
- **Does it have a React admin UI?** Check for `.tsx` files or `admin.tsx`. If yes, the type-check needs `@types/react` and `--jsx react-jsx`.
- **Does it have tests?** Check for a `tests/` or `__tests__/` directory, or a `vitest.config.ts`. If yes, set up the test workflow. If not, mention that adding tests would be valuable but don't force it.
- **What are its peer dependencies?** Check `package.json` for `peerDependencies`. EmDash plugins always depend on `emdash` and may depend on `react`, `astro`, etc.
- **Does it use additional npm dependencies?** Check for `dependencies` in `package.json`. If yes, the CI needs an `npm install` step.
- **Is it published to npm?** Check if the package name is scoped (e.g., `@org/emdash-plugin-foo`) and whether it has a `publishConfig`. If yes, the deploy workflow is relevant.

### Step 2: Recommend a set of workflows

Based on what you found, recommend which workflows to set up. A good default for most plugins:

- TypeScript type-check (almost always — this is the most valuable check)
- ESLint (if the plugin has more than a handful of files)
- npm audit (cheap security check, almost always worth it)

And conditionally:

- Vitest tests (if tests exist)
- npm publish (if the plugin is published to npm)

### Step 3: Create the workflow files

Create each workflow as a separate YAML file in `.github/workflows/`. Using separate files rather than one monolithic workflow gives clearer feedback in PRs (each check shows independently) and makes it easier to enable/disable individual checks.

Use the templates from `references/workflows.md` as starting points, but adapt them to the specific plugin. Common adaptations include:

- Adding `@types/react` if the plugin has `.tsx` files
- Adding additional peer dependencies that provide types
- Adjusting file paths for the type-check and lint commands
- Configuring the npm publish scope and access level

### Step 4: Create supporting config files

Depending on which workflows you set up, you may also need:

- `tsconfig.json` — TypeScript configuration (if not already present)
- `eslint.config.js` — ESLint flat config with TypeScript support
- `vitest.config.ts` — Vitest configuration

### Step 5: Set up secrets reminder

If you're adding the npm publish workflow, remind the user that they need to configure a repository secret in GitHub:

- `NPM_TOKEN` — Their npm access token with publish permissions

Walk them through: Repository Settings > Secrets and variables > Actions > New repository secret.

For scoped packages (`@org/package-name`), the token must have access to the organization.

## Naming conventions

Use descriptive workflow file names that make it obvious what each one does:

- `ci.yml` — TypeScript type-checking (the primary CI check)
- `lint.yml` — ESLint
- `test.yml` — Vitest/test runner
- `security.yml` — npm audit
- `publish.yml` — npm publish on release

## Important details

**Node.js version**: Use Node.js 22 as the default. EmDash is built on modern TypeScript and Astro, so there's no need to support older Node versions. Use `actions/checkout@v5` and `actions/setup-node@v5` (v5 runs on Node.js 24 runners, avoiding the Node.js 20 deprecation).

**Peer dependency installation**: EmDash plugins declare `emdash` as a peer dependency. For type-checking in CI, you must explicitly install `emdash` (and `@types/react` if the plugin has `.tsx` files) since peer dependencies aren't auto-installed in a standalone plugin repo.

**The `--skipLibCheck` flag**: Use `--skipLibCheck` when running `tsc` in CI. EmDash and its transitive dependencies may have internal type issues that aren't relevant to the plugin author. `--skipLibCheck` skips checking `.d.ts` files while still fully checking the plugin's own source code.

**The `find` command for file discovery**: Don't use shell globs like `src/**/*.ts` in CI commands — they fail when no files match at a given depth. Use `$(find src -name '*.ts' -o -name '*.tsx')` instead.

**Branch naming**: Most EmDash plugin repos use `main` as the default branch. Always check the actual repo and use the correct branch name in workflow triggers.

登录后下载/点赞/收藏 ❤ 16 | ★ 0

emdash-github-actions

目录结构

SKILL.md

举报内容

提示