gitee-ent

GiteeEnt

目录

• GiteeEnt
  • 目录
  • 简介
  • 安装
  • 开发
  • 构建
  • 规范
    • 组件规范
    • CSS 规范
    • JavaScript 规范
    • 提交信息规范
    • 开发流程规范
  • 发布

简介

GiteeEnt 是码云企业版组件库，包含了企业版页面中用到的较为稳定的组件，源码目录结构和构建脚本参考自 element-ui。

安装

npm install gitee-ent --save

开发

先克隆此仓库到本地，然后使用如下命令：

# 进入 gitee-ent 源码目录
cd path/to/gitee-ent

# 构建开发版的资源
npm run dev

# 将当前 gitee-ent 目录链接到全局 node_modules 目录中
npm link

## 进入 gitee 主仓库的目录
cd path/to/gitee

# 将全局 node_modules 目录中的 gitee-ent 链接到当前 node_modules 目录中
npm link gitee-ent

注：如果在主库 npm run dev:projects 之后报错找不到 css 资源，那么先在当前仓库下执行 npm run build:css，之后再到主库重新执行 npm run dev:projects

如果 webpack 构建报错找不到 gitee-ent 模块中的文件，可以试试修改 webpack 配置，在 resolve 配置中添加 symlinks: false，禁止将符号链接解析为链接目标位置。

构建

构建用于发布的资源：

npm run dist

在添加新组件后，需运行如下命令更新 src/index.js 文件：

npm run build:file

基础实用类的代码和组件代码是分开构建的，如果有改动 src 目录下的代码，则需要单独运行：

npm run build:utils

规范

组件规范

• 使用 npm run new 创建组件目录结构
• 如果包含父子组件，需要更改目录结构，参考 IssuePanel
• 组件内如果依赖了其他组件，需要在当前组件内引入，参考 Comments
• 组件不应该包含 css 代码

CSS 规范

常见的前端组件库的样式代码都是与组件代码分离的，这样做能方便用户自定义组件库的主题，例如：自定义主题色、字体、边框、阴影等样式。gitee-ent 是作为组件库来开发的，其目录结构和构建脚本参考自 Element UI，所以对 css 代码也有与 Element UI 类似的规范：

• 所有样式应该放到 theme-gitee 样式库中
• scss 文件命名采用小写+连接符风格
• 如果 scss 文件不输出为单独的 css 文件，则应该以下划线开头
• 每个 scss 文件应该对应一个组件
• css 代码应采用 BEM 命名风格

JavaScript 规范

遵循码云前端的 ESLint 即可。

提交信息规范

参考Git 提交信息规范文档。

开发流程规范

• 基于 master 创建一个新分支，然后在该分支上开发
• 开发完后，向 master 分支提交 PR
• 此次更新是否有阻断性改动？
  • 是，依赖主仓库的后端新功能以及相关样式文件，必须与后端一同更新上线
    • 手动创建 PR 专属的版本，版本号格式为：当前主版本-pr编号.子版本，例如：0.8.2-pr123.1
    • 修改 package.json 和 package-lock.json 中的版本号
    • 使用 npm publish --tag=pr 命令发布该版本
    • 主仓库中安装此版本，并按主仓库的开发流程提交 PR
    • 主仓库的 PR 审查和测试是否通过？
      • 否，从第 3 步重新开始，递增 PR 专属版本后面的子版本号，例如当前是 0.8.2-pr123.1，递增后则为 0.8.2-pr123.2
      • 是，进入下一步
  • 否，只是小改动，兼容现有线上环境，可单独更新
• 经管理员审查通过后合并此仓库的 PR 到 master
• 管理员打包发布测试版本，版本号遵循语义化版本控制规范，版本号格式为：1.x.x-beta.x，如果当天有多次更新，则应该只递增 beta 后面的编号
• 在主仓库中安装这一测试版本，本地测试无问题后再更新到 PR 上
• 如果测试版本还存在问题，需要继续修改，请重复上述流程

上线后的处理：

• 出现小问题：重复上述流程即可
• 出现严重问题且无法快速修复：回退主仓库中涉及 gitee-ent 版本更新的所有 Pull Requests
• 一切正常：第二天由管理员发布稳定版本，并向主仓库提交 Pull Request

手动发布

# 创建 beta 版的发行版
npm run release-beta

# 创建正式发行版
npm run release

# 发布测试版到 npm 服务器上
npm publish --tag=beta

# 发布正式版到 npm 服务器上
npm publish

流水线发布

发布 beta 版： 在创建的 PR 底下评论 Gitee Go Publish Beta 即可发布 v<verson>-beta-<构建ID> 的发行版

发布正式发行版： 在任意分支下执行 npm run release 即可发布正式版