遵守约定进行开发。约定主要包括以下：

1. package.json

  1. scripts
    1. clean
    2. lint: lint-staged（tslint、prettier）
    3. test
    4. test-live
    5. coverage
    6. build
    7. ci 专门用于 travis
  2. build
    1. cjs
    2. ems
    3. umd（可选，只有 g2, g2-plot g 等上层包需要打 dist 文件）
  3. main
    1. main
    2. module
    3. browser（可选，umd 需要）
    4. types
  4. husky 添加 pre-commit（lint、build、test）（请勿使用 git commit -n）
  5. commit msg 请自己规范一下，暂时没有 lint 工具。例如： fix(axis): fix axis style ， fix: fix axis style
  6. 删除无用文件，如果不知道是干啥的就删除
  7. ci 需要运行 lint test build

2. npm 包内容

仅保留：

  • package.json
  • lib
  • esm
  • dist
  • LICENSE
  • README.md
  • CHANGELOG.md

可以使用 package.json 中 配置 files 的方式，请勿 npm publish 非上述文件或者目录。

3. 代码组织

  1. 代码目录 src
  2. 单测目录 tests
  3. 全部使用 typescript 语言，包括单测，注意类型定义，尽量少用 any
  4. tslint & prettier 必须添加，且保持一致（参考 scale 写法）
  5. package-lock.json 无需 git 提交
  6. 每个目录都必须要有 index.ts 文件
  7. 文件、目录命名采用 abc-def 形式
  8. 常量使用全大写
  9. 变量请勿大写开头
  10. 私有成员在加 private 关键字的前提下
  11. 方法之间换且换一行
  12. 无用代码删除，而不是注释

4. 代码规范

按照目前 tslint 和 prettier 即可，后续会逐步添加不规范的写法。tslint 规则目前使用下面的规则默认：

  • “tslint:recommended”
  • “tslint-config-prettier”

后续可按照需求添加和移除。

5. 协作流程

多人协作开发的流程。

G2 4.0 开发规范 - 图1

  • PR 合并时候，在 GitHub 上使用 “rebase and merge”，让 commit 记录干净一些（其他两个都会在 commit 增加一个 merge commit）

image.png

  • 合并分支之后，删除原 pr 分支

发布规范

严格遵循 Semantic Versioning 2.0.0 语义化版本规范。

发布周期

  1. •    修订版本号：每周都会进行日常 bugfix 更新，发布日定在周四。（如果有紧急的 bugfix，则任何时候都可发布）<br />    •    次版本号：每个迭代发布一个带有新特性的向下兼容的版本，发布时间有迭代时间决定。<br />    •    主版本号：含有破坏性更新和新特性，不在发布周期内。

发布流程

  1. 提交命名为 release-${version} 的 PR，该 PR 内容包括：
    1. 更新日志
    2. 更新版本号
  2. 以上 PR 合入 master 后，运行 npm publish 发布 npm 包，同时使用链接中的工具发布对应的 CDN 连接
  3. 分支切到 v4.0.x，merge master 代码，然后在 v4.0.x 分支上打 tag，tag 命名规范： v${version} 以 ‘v’ 开头，如 v4.0.1
  1. $ git co master
  2. $ git pull origin master
  3. $ git co v4.0.x && git merge origin/master && git tag v4.0.1
  4. $ git push origin v4.0.1
  1. 编辑https://github.com/antvis/G2/releases 页面
  2. 部署网站，如果有 API 的变动，需要重新更新 API 文档:
  1. # 如果 API 有变动，更新 API 文档
  2. $ npm run doc
  3. # 部署网站
  4. $ npm run site:deploy

7. 其他

  • 写更简洁的代码。能用 es6 的方法就不要用 es5 去拼接
  • common、util、helper 等代码请勿滥抽，确定复用性
  • 相同职责、模块的代码在一个目录结构中，减少代码跳跃
  • 尽可能清晰的代码，模块化的代码，都是为了一定程度的复用，多考虑代码的维护性、可测性
  • 注释完善，请勿信奉“代码即注释”，大型项目，函数命名尤其有难度，起有注释作用的命名，几乎不可能