Skip to content

contribution.md

Latest commit

 

History

History
94 lines (77 loc) · 4.36 KB

contribution.md

File metadata and controls

94 lines (77 loc) · 4.36 KB
Raw

贡献者指南

命名规范

  1. 代码中：$开头的为着“无副作用函数”，主要有两类：
    1. $+小写：为无副作用函数（需要在 jsdoc 中声明@inline）
    2. $+大写：为 TypeScript 类型定义与推断
  2. 代码中：纯大写+下划线 通常为“零成本抽象”定义，目前只有一类：const enum

代码提交规范

使用 Edit-Commit-Message 插件来辅助生成规范性的提交日志。

该规范有两个非常重要的概念：“动作概述”、“类目”。

动作概述

其中“动作概述”包括了最常见的几个种类：

  1. 代码相关·常用
    1. ✨ 新增内容 add-feature
    2. 🐛 问题修复 fix-bug
    3. ⚡️ 性能改进 performance
    4. 🪄 重构 refactor
    5. 👽️ 外部变更做出的适应 env-changes
  2. 代码相关·少用
    1. 🎨 统一风格 format-style
    2. 🚚 迁移 move/rename
    3. 🔥 删减 remove-code
    4. 🚑︎ 补充提交 hotfix
    5. ⏪️ 回滚提交 revert-changes
  3. 代码相关·很少用
    1. 🧪 实验 experiment
    2. 🔒️ 安全相关的问题 security-issues
    3. 🤡 模拟 mock-things
  4. 依赖管理
    1. 🔼 依赖升级 upgrade
    2. 🔽 依赖降级 downgrade
    3. ➕ 依赖增加 add-dependencies
    4. ➖ 依赖删减 remove-dependencies
  5. 最好别用的
    1. 🫧 无概述 none
    2. 💩 写了一坨屎，难以描述 bad-code
    3. ♾️ 大杂烩/缝合怪 mix

可以很简单地看出来，总共其实是分成两大类：“代码相关”与“依赖管理”。至于“最好别用的”，极少场景会用到，但总会用到。

其中代码相关分成三档：“常用”、“少用”、“很少用”。它们所描述的内容也越发精细。请尽可能使用精细的动作来概述内容。 比如说“🪄 重构 refactor”意味着对代码进行一定的重写，如果只是重命名，那么请选择“🚚 迁移 move/rename”，如果内容不仅仅包含重命名，还包含了一些“🎨 统一风格 format-style”以及“逻辑的调整”，并且这些变更没必要分成多个 commit，那么才会选择使用“🪄 重构 refactor”这个更加宽泛的概述。

类目

其中“类目”包括了常见的文件类型：

  1. 🏢 业务施工 main-working
  2. 业务施工·相关
    1. 🧊 模块 module
    2. 💄 样式 style
    3. 📄 组件 component
    4. 🍱 资源 assets
    5. 🪖 路由守卫 route-guard
    6. 🔄 路由加载 route-resolve
    7. 🏭 服务 service
    8. ✅ 测试 test
  3. 🔧 工具 tools
  4. 📝 文档 doc
  5. 🔖 新版本 new-version
  6. 📄 其它 others

其中“业务施工”是一个非常特殊的类目，通常是指直接的业务开发，包括 Angular 的 component/service/pipe 等等模块的的逻辑直接开发。

然后是“业务施工·相关”，涵盖了常用的 Angular 项目相关的文件，它们都是服务于“业务施工”的模块。

其余的关于“工具”、“文档”、“新版本”、“其它”，是“业务施工”更外一圈的东西。

如何组合使用？

我们以一些常用的场景来解释它们的组合。

  1. 比如说我创建了一个新的 page，那么这时候会提交大量文件：module.ts/component.ts/scss.ts/resolver.ts/pipe.ts/service.ts/cy.ts/stories.ts。

    这时候选择“✨🏢”即可。意味着“增加了新的业务”

  2. 接着我们对这个页面进行了样式进行了补充。

    这时候选择“✨💄”。意味着“新增了样式”

  3. 然后提交了 pr 之后：
    1. 代码存在的规范性问题。比如在 css 中写了@apply，需要搬迁到 html 的 clss 中去

      这时候选择“🎨💄”。意味着“根据规范调整了样式写法”

    2. component 的代码实现不够优美。找到更好的实现方案：

      这时候选择“🪄🏢”。意味着“重写了业务逻辑”

    3. 找到一些 BUG：

      这时候选择“🐛🏢”。意味着“修复了业务逻辑的 BUG”

    4. 有一些代码需要改写成Angular/resolve：

      这时候选择“🚚🔄”。意味着“迁移代码成路由守卫”。

  4. 然后产品看到结果不满意，找了设计，再改动了样式，最终我们对照新版设计稿做出调整

    这时候选择“👽️💄”。意味着“新增了样式”