Skip to content

Latest commit

 

History

History
155 lines (114 loc) · 6.16 KB

README.md

File metadata and controls

155 lines (114 loc) · 6.16 KB

CCMS Components

Build Status npm version npm downloads coverage

组件 API 文档

开发指南 Angular1.x + ES6 开发风格指南 ccms开发指南

安装与使用

# 安装 ccms-components 和相关依赖
npm install --save ccms-components angular angular-resource angular-ui-router

引入方式

ES6

import angular from 'angular';
import ngResource from 'angular-resource';
import uiRouter from 'angular-ui-router';

import ccmsComponents from 'ccms-components';

angular.module('app', [ngResource, uiRouter, ccmsComponents]);

ES5

<link rel="stylesheet" href="/node_modules/ccms-components.css">

<script src='/node_modules/angular/angular.js'></script>
<script src='/node_modules/angular-resource/angular-resource.js'></script>
<script src="/node_modules/angular-ui-router/release/angular-ui-router.js"></script>

<script src='/node_modules/ccms-components.js'></script>

注意事项

  • 使用 ccms-portal 的项目不需要重复打包 ccms-components。

    由于 ccms-portal 中已经引入 ccms-components,所以相关项目在使用 webpack 打包时可忽略 ccms-components,配置如下:

    externals: {'ccms-components': '\'ccms.components\''}
  • 在 console 中运行下面这条语句可以查看 ccms-components 版本:

    angular.module('ccms.components').version
    

贡献代码

组件库规范

在遵照基本的开发指南基础上,组件库额外的规范:

  1. 需要对外暴露的服务,以 $cc 为前缀,如 $ccModal
  2. 组件库组件均以 cc-xx 形式提供,如cc-grid. (cc => ccms-component 首字母)
  3. 提交的组件, Controller 部分需同时提交单元测试,不符合无法通过review。如果是开发的新 feature ,同时需要提供 docs 文档及相应demo。
  4. 其他规范遵照目前已有组件的风格。

开发步骤

  1. ccms-components 组内的人员直接 clone 本项目;其它人员请 fork 本项目。
  2. 基于 dev 分支创建你的分支,例如 feature/abc, bugfix/abc, docs/abc
  3. 开发完成之后,在 github 网页中创建一个 pull request,base 为 dev,compare 为你的分支名
  4. 等待上游 review,merge pull request
  5. 在开始另一个功能开发创建新分支之前,应当先将 dev 分支同步为最新的状态。
    # 对于 ccms-components 组内的人员,在 dev 分支拉取更新
    git pull
    
    # 对于 fork 本项目的人员,需要先将本项目添加为一个 git remote,再拉取更新,参考以下操作
    # step 1,添加一个 remote
    git remote add ccms https://github.com/ShuyunFF2E/ccms-components
    # step 2, 在 dev 分支拉取 ccms 的更新
    git pull ccms
  6. 重复 2~5 的操作,创建新分支继续其它功能的开发

发现 bug 怎么办

  1. 提交 issue 描述问题,与相关人员确认是否是 bug
  2. 确认是 bug
    • 如果对 bug 修复时效很敏感(影响产品发布时间)。遵照以下步骤(推荐):
      1. 将相应组件的代码 copy 到自己项目(通常为组件文件夹),在原始组件代码基础上修复 bug,并给组件起一个别名(如 cc-menu 改为 cc-xxx-menu ),项目中改为使用 cc-xxx-menu。
      2. 项目测试提交,确认修复代码可行后,将代码提交给组件库,等待组件库合并代码。提交步骤
      3. 组件库合并提交代码后发布版本,portal 更新组件库后发布。
      4. 将项目里的 cc-xxx-menu 还原成 cc-menu。
    • 如果对 bug 修复时效不敏感,等待/提醒 组件库相关维护人员修复 bug 并发布版本。最后 portal 发布新版本组件库时,bug 自动修复。(周期通常较长,deprecated!)

提交代码、pull request 准则

提交代码的 commit message 和 pull request 标题需按如下格式:

<type>(<scope>): <subject>
  • <type>,变更的类型,可用的类型有以下几种:
    • feat,A new feature
    • fix,A bug fix
    • docs,Documentation only changes
    • style,Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
    • refactor,A code change that neither fixes a bug nor adds a feature
    • perf,A code change that improves performance
    • test,Adding missing tests
    • chore,Changes to the build process or auxiliary tools and libraries such as documentation generation
  • <scope>,标记变更的范围,通常为你的模块名
  • <subject>,用于描述的文字

发布脚本

release 脚本

# 正式版本
npm run release -- <version_category: major | minor | patch>

# 测试版本
npm run release -- <version_category: major | minor | patch> --branch <branch_name>

以下是 release 脚本内部所执行的子任务,包含[1, 2, 3]。当 release 脚本出错中断时,可以手动运行对应的脚本进行发布(需要注意参数)。

  1. 处理分支,打标签

    # 正式版本
    npm run prepare-production -- <version_category: major | minor | patch>
    
    # 测试版本
    npm run prepare-test -- <version_category: major | minor | patch> --branch <branch_name>
  2. build

    # build 代码,产出到 dist/ 中
    # 可以指定 git_revision 参数(如 master / v2.0.1 / 0abcdef),默认 build 当前 working tree 代码
    npm run build [-- <git_revision>]
  3. 发布 npm 包

    # 将 dist/ 中 build 好的代码上传到 npm 仓库
    npm run publish:package