在 Devin 中试用 DeepWiki 处理私有仓库
DeepWiki

sveltejs/svelte

菜单

CI/CD 与贡献流程

相关源文件

本文档记录了 Svelte 仓库的持续集成、持续交付流水线和贡献流程。它涵盖了项目如何管理其构建、测试和发布过程，并为贡献者提供了在提交更改时应遵循的工作流指南。

贡献工作流程概述

Svelte 项目遵循结构化的贡献工作流，以维护代码质量并确保顺畅的审查过程。

来源： CONTRIBUTING.md1-147 .github/PULL_REQUEST_TEMPLATE.md1-12 .github/workflows/ci.yml1-80

设置开发环境

在贡献 Svelte 之前，您需要设置您的开发环境。

先决条件

  • Node.js（请参阅 CI 工作流中的支持版本）
  • pnpm（9.0.0 或更高版本）

安装步骤

  1. Fork 并克隆仓库
  2. 安装依赖项
  1. 构建项目

项目使用 pnpm workspaces 来管理 monorepo 结构。

项目结构

该存储库被组织为一个 monorepo，包含多个包和站点。

svelte-monorepo/
├── packages/
│   ├── svelte/         # Main Svelte package
│   └── ...             # Other packages
├── sites/              # Documentation and demo sites
├── .github/            # GitHub configuration and workflows
└── ...

来源： package.json1-49 CONTRIBUTING.md74-79

运行测试和检查

Svelte 使用全面的测试套件来确保代码质量并防止回归。

测试命令

命令描述
pnpm test运行所有测试
pnpm test <suite-name>运行特定的测试套件
pnpm test <suite-name> -- -t <test-name>运行套件中的特定测试
pnpm lint运行 ESLint 和 Prettier 检查
pnpm format使用 Prettier 格式化代码
pnpm check类型检查代码库
pnpm bench运行基准测试

更新测试快照

有些测试会与保存的快照进行比较。要更新这些快照，请

来源： CONTRIBUTING.md92-120 package.json16-29

CI/CD 流水线

Svelte 使用 GitHub Actions 进行持续集成和交付。

来源： .github/workflows/ci.yml1-80 .github/workflows/pkg.pr.new.yml1-43 .github/workflows/pkg.pr.new-comment.yml1-117

CI 工作流作业

CI 工作流包含多个作业，这些作业在不同的操作系统和 Node.js 版本上运行。

  1. 测试：在多个平台（Windows、macOS、Ubuntu）和 Node.js 版本（18、20、22）上运行测试套件。
  2. Lint：执行类型检查、linting，并验证生成的类型是否与已提交的文件匹配。
  3. Benchmarks：运行性能基准测试。

每个作业都必须通过才能合并拉取请求。

来源： .github/workflows/ci.yml14-79

PR 预览包

对于每个拉取请求，都会发布一个临时包，允许在合并之前在实际项目中进行测试。

工作流

  1. 构建 Svelte 包
  2. 将其发布到 pkg.pr.new
  3. 向 PR 添加一个包含安装说明的注释
  4. 提供一个 playground 链接来测试更改

示例注释

<!-- pkg.pr.new comment -->

[Playground](https://svelte.net.cn/playground?version=pr-123)

pnpm add https://pkg.pr.new/svelte@123

来源： .github/workflows/pkg.pr.new.yml1-43 .github/workflows/pkg.pr.new-comment.yml1-117

类型生成与验证

TypeScript 类型定义是 Svelte 的重要组成部分。该项目有一个专门的类型生成和验证流程。

类型定义使用 generate-types.js 脚本生成，该脚本

  1. 从源文件打包 TypeScript 定义
  2. 使用 stripInternal 选项移除内部类型
  3. 对生成的类型执行验证检查

在 CI 期间，工作流会验证已提交的类型定义是否与当前源代码生成的类型匹配。

来源： packages/svelte/scripts/generate-types.js1-77 .github/workflows/ci.yml62-64

Changesets 用于版本管理

Svelte 使用 changesets 来管理版本和变更日志的生成。

添加 Changeset

当进行会影响版本号的更改时

  1. 在存储库的根目录下运行 npx changeset
  2. 选择已更改的包
  3. 选择合适的 semver 增量（patch、minor、major）
  4. 撰写更改说明

Changesets 存储在 .changeset 目录中，并在发布过程中用于确定版本增量和生成变更日志条目。

来源： CONTRIBUTING.md146 .changeset/config.json1-11

发布流程

发布过程通过 GitHub Actions 自动化。

发布工作流

  1. 在推送到 main 分支时运行
  2. 构建包以确保所有内容都能编译
  3. 使用 changesets/action 来
    • 创建一个 PR 来更新版本和变更日志（如果存在未发布的 changeset）
    • 当版本 PR 合并后，将包发布到 npm

来源： .github/workflows/release.yml1-49

版本策略

该项目通过 changesets 系统使用语义化版本控制，该系统

  1. 根据 changesets 自动确定版本增量
  2. 生成包含相关 PR 链接的变更日志
  3. 为发布的包提供 npm 来源证明

来源： .changeset/config.json1-11 .github/workflows/release.yml40-48

拉取请求指南

提交拉取请求时，请遵循以下准则，以确保顺畅的审查流程：

  1. 为 PR 标题添加前缀：使用诸如 feat:、fix:、chore: 或 docs: 之类的​​前缀。
  2. 包含测试计划：描述您如何测试您的更改。
  3. 添加 Changeset：如果您的更改影响了 Svelte 包，请添加一个 changeset。
  4. 保持 PR 的专注性：每个 PR 都应解决单一问题。
  5. 通过所有检查：在请求审查之前，请确保测试和 linting 通过。

对于破坏性更改，请包含以下信息：

  • 受影响的人员
  • 如何迁移
  • 为什么需要进行破坏性更改
  • 严重程度（受影响人数 x 工作量）

来源： .github/PULL_REQUEST_TEMPLATE.md1-12 CONTRIBUTING.md138-160

生态系统 CI

Svelte 拥有一个生态系统 CI 系统，用于测试与其他生态系统项目的集成。

维护者可以通过在拉取请求上评论 /ecosystem-ci run 来触发生态系统测试。这将与其他 Svelte 生态系统项目运行一套集成测试，以确保兼容性。

来源： .github/workflows/ecosystem-ci-trigger.yml1-95

问题管理

问题经过分类和管理，以实现高效的分类和优先级排序。

问题模板

存储库为以下内容提供了结构化模板：

  1. Bug 报告 - 包括重现步骤、系统信息和严重性。
  2. 功能请求 - 描述问题和建议的解决方案。

带有 good first issue 标签的问题是新贡献者的理想选择。

来源：.github/ISSUE_TEMPLATE/bug_report.yml1-51 .github/ISSUE_TEMPLATE/feature_request.yml1-36 CONTRIBUTING.md22-29

来源：CONTRIBUTING.md31-43