企业官网建设流程全解析

js-logger发布流程剖析：从publish.sh校验到uglifyjs压缩的完整npm发布指南

【免费下载链接】js-loggerLightweight, unobtrusive, configurable JavaScript logger.项目地址: https://gitcode.com/gh_mirrors/js/js-logger

想弄清楚一个 JavaScript 日志库是如何安全地发布到 npm 的？本文以 js-logger（一个轻量、无侵入、可配置的 JavaScript logger）为例，完整剖析它的发布脚本publish.sh：从工作区校验、CHANGELOG 版本核对，到build:version版本号注入与 uglifyjs 压缩生成logger.min.js，最后 commit、打 tag、npm publish一条龙，帮你掌握小型开源项目 npm 发布的标准姿势。

为什么值得拆解 js-logger 的发布脚本？

js-logger 零运行时依赖，源码只有一个文件src/logger.js，但它的发布流程却相当严谨。整个流程浓缩在两个地方：

• 发布入口：项目根目录的publish.sh（共 67 行 shell 脚本）
• 构建配置：package.json的scripts字段（lint、test、build 三段流水线）

一个 67 行的脚本就能撑起一个生产级发布流程，这正是新手最该学习的地方——把"容易出错的环节"全部交给脚本强制校验。

publish.sh 的四道发布前硬校验

脚本开头定义了三个工具函数（die、workspace_is_clean、git_branch_name），随后依次执行 4 道校验，任何一道失败都会打印错误并立即退出：

| 顺序 | 校验项 | 实现方式 | 防住的事故 | | :--: | -- | -- | -- | | 1 | 工作区干净 |git diff-index --quiet HEAD| 带着未提交改动就发版 | | 2 | 当前分支是 master |git rev-parse --abbrev-ref HEAD| 从特性分支误发 npm | | 3 | 本地与远程同步 |git fetch后比对HEAD与@{u}| 推送后他人拿到落后代码 | | 4 | CHANGELOG 首行等于版本号 | 比对## ${PKG_VERSION}| 忘记更新更新日志 |

几点细节值得学习：

• 版本号唯一来源：脚本用node -p "require('./package.json').version"读取 package.json 中的version（当前为1.6.1），避免手输版本出错。
• CHANGELOG 核对：脚本取CHANGELOG.md第一行，必须严格等于## 1.6.1这样的格式，否则会提示实际内容是什么，方便定位。
• 人工确认环节：脚本会打印 CHANGELOG 前 10 行（加>前缀排版），然后交互式询问"does this look correct?"，只有输入Y/y才继续——发布前的最后人工保险。
• npm install 幂等校验：执行npm install后再次检查工作区是否干净，防止package-lock.json变动被忽略。

构建流水线：lint → test → build

校验全部通过后，脚本按顺序执行三个 npm script，对应 package.json 中的配置：

1️⃣npm run lint：代码风格底线

使用 jshint 检查src/*.js与test-src/*.js，并排除压缩产物src/*.min.js——注意这个--exclude很关键，否则 lint 工具会被混淆后的单行代码"折磨"。

2️⃣npm run test：三重质量门

test 其实串联了三件事：

• prettier --check .：格式规范检查（不是格式化，只检查）
• test:unit：用node-qunit-phantomjs跑test-src/index.html里的 QUnit 单测
• test:tsd：用 ts-node 编译运行test-src/typescript-consumer/下的 TypeScript 消费示例，验证 logger.d.ts 类型声明对外可用

这一步保证了JS 行为和 TS 类型声明同时正确，对带类型声明发布的库非常重要。

3️⃣npm run build：版本号注入 + uglifyjs 压缩

build 由两个子步骤组成，这是理解 js-logger 产物的关键：

第一步build:version——版本号注入

用cross-env+replace工具做正则替换，把src/logger.js第 13 行的

Logger.VERSION = "…"

统一替换为package.json中的$npm_package_version。这样版本号只有一个来源（package.json），源码里的Logger.VERSION常量自动跟随，不会出现"包版本 1.6.1、代码里写着 1.6.0"的尴尬。

第二步build:minify——uglifyjs 压缩

uglifyjs src/logger.js --mangle --compress -o src/logger.min.js

两个参数各司其职：

• --mangle：把变量名混淆成e、t、c等短名
• --compress：压缩死代码、合并语句

压缩产物src/logger.min.js就是用户通过<script>标签引入的浏览器版本，开头形如!function(e){"use strict";…c.VERSION="1.6.1"…，一眼就能看到版本号被正确注入。

收尾动作：commit → tag → push → publish

build 结束后，publish.sh完成最后的发布仪式：

1. git add . && git commit -m "Release v${PKG_VERSION}"——把压缩产物logger.min.js连同改动一起提交（构建产物直接入库，用户拉仓库即可用）
2. git push origin master
3. git tag "v${PKG_VERSION}"并推送 tag——为这个版本打上 git 标签，方便日后git checkout v1.6.1回查
4. npm publish——真正上传到 npm

同时package.json的files字段白名单式地控制发布内容：只包含/src、CHANGELOG、MIT-LICENSE.txt、README，测试目录和脚本都不会被发到 npm 上；main指向src/logger.js，typings指向src/logger.d.ts，Node 与 TypeScript 用户开箱即用。

新手可复用的发布清单 ✅

把 js-logger 的流程抽象出来，任何小项目都能照搬：

• 发布前：工作区干净、在发布分支、本地与远程同步
• 版本单一来源：版本号只写在package.json，构建时注入源码
• 更新日志强校验：CHANGELOG 首行必须等于当前版本号
• 人工确认：发布前打印关键信息，交互确认一次
• 质量门：lint + 单元测试 + 类型检查，全部通过才继续
• 产物入库：压缩文件提交到仓库并打 git tag
• 白名单发包：用files字段精确控制 npm 包内容

小结

js-logger 的发布流程看似简单，实则把"发布最容易翻车的每一步"都用publish.sh固化成了硬性检查，再用build:version与 uglifyjs 保证了源码版本号和压缩产物的一致性。对新手来说，这套 67 行脚本 + 6 个 npm script 的组合，就是一份开箱即用的 npm 发布参考实现。

【免费下载链接】js-loggerLightweight, unobtrusive, configurable JavaScript logger.项目地址: https://gitcode.com/gh_mirrors/js/js-logger