# create-component-app

**Repository Path**: marketing-activity-platform/create-component-app

## Basic Information

- **Project Name**: create-component-app
- **Description**: 营销活动平台组件脚手架工具，通过该脚手架创建、开发调试以及发布组件项目
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2022-11-17
- **Last Updated**: 2024-07-13

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

t# create-component-app

搭建平台组件开发工具（命令行工具 cli、调试、编译及发布上线）

## Documentation

gi

## Command

```bash
# start docs
yarn docs:serve

# publish packages
yarn pub
# more publish command
yarn pub from-git       # 从上一次中断的位置继续发布（例如：因无权限而导致的发布失败了，添加权限后可通过此命令继续发布，避免造成版本号再次提升）
yarn pub from-package   # 将本地领先版本的包全部发布一次（适用场景：某些原因，可能本地的包版本被提升，但未发布，或者，直接手动修改大版本号后发布）


# commit cmd, to replace git commit
yarn commit
```

## How to dev the packages?

1. @activity-maker/create-component-app

   可以使用 `npm link` 的方式去调试，但并不推荐，因为有更好的办法。

   本仓库配置了 vscode nodejs 调试，请按照以下方式去调试。

   1. 在 vscode 中按快捷键 `F5`，将自动启动 `packages/create-component-app/index.js`

   2. 按需去修改 `.vscode/launch.json` 的 `args` 属性配置启动参数

      已给出需要的各类参数，去切换使用即可，根据参数调试不同场景。

2. @activity-maker/component-template

   1. 修改 template 代码

   2. 从本地生成项目

      - 推荐直接通过 `.vscode/launch.json` 的 `args` 属性，配置 `-t` 参数从本地调试（优点：本地的 `create-component-app`、`component-template` 一起调试）。

      - 或者，运行以下命令去生成。

        ```bash
        # -t/--template 指定模板路径，file: 协议从本机文件系统查找
        npx -p @activity-maker/create-component-app create-component-app -t file:/Users/eleven/Documents/CODE/create-component-app/packages/component-template
        ```

   3. 调试代码，确认无误后发布

3. 剩余的其它包（@activity-maker/component-scripts、@activity-maker/component-devtools 等）

   推荐使用 [yalc](https://github.com/wclr/yalc)，自行前往了解使用，简单概括：

   - 替代 `npm link`，解决了 `npm link` 存在的若干问题
   - 包发布在本地全局 store，从本地安装，过程模拟真实的包发布、安装。

   **调试步骤：**

   1. 修改各个包的代码

   2. cd 到该包目录下，代码更改后发布（yalc 的机制，发布在本地的全局 store 中，而非真实发布）

      ```bash
      yalc publish
      ```

   3. 在任意组件中进行调试（更推荐自己新建一个专用于测试的组件）

      - 使用 `add` 命令添加上一步发布在本地（store）的包

        ```bash
        # 例如调试 @activity-maker/component-scripts
        yalc add @activity-maker/component-scripts
        ```

      - 若已 `add` 添加，使用 `update` 更新即可

        ```bash
        # 无需指定包名，将更新所有已 add 的包
        yalc update
        ```

   4. 正常启动调试

      ```bash
      # 测试什么，敲什么
      yarn start
      yarn build
      ```

   5. 调试、运行无问题，即可前往 `create-component-app` 正常发布包

      如需移除测试组件中 `add` 的包，`yalc remove --all` 即可。

## Commit & CHANGELOG

执行 `yarn pub` 发布包时，将自动根据之前 Git 提交的 type/message 生成 Changelog，推送代码到仓库，将依靠 GitLab CI 自动处理后续的 Changelog 更新、部署。

代码提交时，推荐遵循以下准则：

- 始终使用 `yarn commit` 命令，替代 `git commit` 提交代码
- 代码成块提交，在一个功能、一个需求完成后 `yarn commit`
- 注意 commit message 书写规范，内容简约而表达清楚，这些将出现在 `CHANGELOG.md` 中

内置了 `commitlint`，校验规则遵循 [@commitlint/config-conventional](https://www.npmjs.com/package/@commitlint/config-conventional)。

commit type 的选择，请遵循以下准则：

| 类型       | 说明                                                                                                                      | 版本规则                              |
| ---------- | ------------------------------------------------------------------------------------------------------------------------- | ------------------------------------- |
| `feat`     | 需求迭代                                                                                                                  | 提升次版本                            |
| `perf`     | 优化更新                                                                                                                  | 提升小版本                            |
| `fix`      | Bug 修复                                                                                                                  | 提升小版本                            |
| `refactor` | 没有新增功能或修复 bug（代码重构相关优化更新）                                                                            | 提升小版本                            |
| `WIP`      | Work in progress（工作未完成，临时提交 [#38](https://github.com/conventional-commits/conventionalcommits.org/issues/38)） | --                                    |
| `docs`     | 文档更新                                                                                                                  | 提升小版本（但不生成 changelog 内容） |
| `chore`    | 改变构建流程、或者增加依赖库、工具等                                                                                      | 提升小版本（但不生成 changelog 内容） |
| `test`     | 测试用例，包括单元测试、集成测试                                                                                          | 提升小版本（但不生成 changelog 内容） |
| `style`    | 仅仅是对格式进行修改，如逗号、缩进、空格等，不改变代码逻辑                                                                | 提升小版本（但不生成 changelog 内容） |
| `revert`   | 版本回滚                                                                                                                  | 提升小版本（但不生成 changelog 内容） |

若有大版本更新时，勾选 breaking changes 即可自动提升大版本。

前往[官方文档](https://www.npmjs.com/package/@commitlint/config-conventional)了解更多。

## Deploy Docs

GitLab CI 自动部署文档，仅需推送代码到 `master` 分支，无需额外操作。

## About Docsify

1. 借助 [docsify-plugin-flexible-alerts](https://github.com/fzankl/docsify-plugin-flexible-alerts) 编写实用的提示标签

## About activity-maker-shell

与 [`@activity-maker/activity-maker-shell`](http://gitlab.ximalaya.com/commercial-activity-maker/activity-maker-shell) 有何关联？

@activity-maker/activity-maker-shell 是搭建发布页面的外壳（如：全局基础逻辑等），而本地调试时，这些全局的壳逻辑放置在 `packages/component-scripts/web/` 目录下。两者需要保持一致，因此，关键性的逻辑有更新时，需要一起修改。

@activity-maker/activity-maker-shell 是后来重构的最新代码，因此与 `packages/component-scripts/web/` 的逻辑编写并不完全一致，理论上，我们最正确的做法是：

☞ [引入 @activity-maker/activity-maker-shell，替换 component-scripts/web 壳逻辑](http://gitlab.ximalaya.com/commercial-activity-maker/create-component-app/issues/19)

替换工作需要对本地调试的流程、代码有相当程度的了解，风险与收益并存。