有时候由于非代码原因，需要手动触发 github actions，比如：测试、部署等。

手动触发 github actions 可以通过以下两种方式：

• 通过 Actions 页面手动触发
• 通过 Actions 页面的 Run workflow 按钮触发

在提交代码时遇见了点问题，以为只是暂时的网络问题，没太注意。知道后来提交尝试很多次，发现 ping github.com 也不通。于是，开始查找原因。

ping 可以通过发送 ICMP 协议包检测当前设备于目标服务器之间的🛜连通性。但在 DNS 被污染时，是没有办法甄别。

所以需要使用添加 IP 直连的方式，来绕过 DNS 解析。

合并提交​

若是频繁的为小改动，可以在推送前合并为一次提交

git rebase -i HEAD~3

上面的代码将合并最近三次的提交。

1. 找到需要合并的提交，修改为squash，其他保持不变。
2. 保存并退出。
3. 推送到远程仓库。

这样，你的改动将会被合并为一次提交，并保留你的贡献者信息。

在项目添加单独 eslint 配置时，执行 npx eslint . 后空台台显示一个提示 package.json 缺失 type 属性。但显示并不是错误，而是提示 package.json 的 type 属性缺失，可以忽略，但建议配置 "type": "module"。

手快的我直接在 package.json 文件中添加了该属性。

a few days later...

为了保证代码风格统一，使用 husky + lint-staged + prettier + eslint 提交代码前自动格式化代码。

背景​

当使用 husky 后，在 git commit 时：

• 自动执行 pre-commit 钩子
• 然后执行 lint-staged
• 再执行 prettier
• 最后执行 eslint

操作会自动用 Prettier 和 ESLint 格式化暂存区（git add 过的文件）的代码，并检查代码是否符合规范。格式化的改动会自动添加到本次提交，无需手动操作。

在使用命令 git tag v0.1.0 -v 时发现在展示的信息末尾包含了一句 “error: no signature found”。一检索，才发现是自己在查看 commit 标签时使用错了命令。正确应当是 git show v0.1.0。于是捎带脚的查了下 [GPG]

1. 核心运行原理​

GitHub Actions 是 GitHub 提供的 托管式自动化服务，其运行特点如下： • 按需创建：每次触发工作流程时，GitHub 会在其服务器集群中动态创建虚拟机实例（称为 Runner） • 环境隔离：每个 Job 都在全新的独立环境中执行，任务完成后销毁实例 • 多系统支持：提供 Linux (Ubuntu)、Windows 和 macOS 三种托管运行环境

测试覆盖率是测试代码的质量，它表示代码被测试的百分比。

在系统学习构建 npm 包时，发现在推荐的徽章展示中包含测试覆盖率的徽章，有助于帮助用户了解代码的质量。

但是貌似遇见了我的知识盲区，遂学且记之。

一个基本包在构建时还需要考虑的其他方面的内容。

模块化与架构设计​

模块化分割​

• 按功能划分：将核心逻辑、业务逻辑、工具函数等，分别打包到不同的模块中，方便维护和复用。
• 支持插件系统：允许用户自定义插件，实现对不同环境、不同场景的兼容。

初始化 package.json​

执行初始化​

npm init -y