Day.js 贡献者实战指南从代码风格规范到 100% 测试覆盖率的完整工作流【免费下载链接】dayjs⏰ Day.js 2kB immutable date-time library alternative to Moment.js with the same modern API项目地址: https://gitcode.com/gh_mirrors/da/dayjs本文基于 Day.js 仓库的 CONTRIBUTING.md 展开系统梳理向 Day.js 提交贡献PR、Bug 报告、locale/文档改进的完整流程与硬性规范并结合 package.json、ESLint/Jest 配置与 GitHub Actions 工作流源码讲清楚代码风格、语义化提交、测试覆盖与 CI 校验的底层实现帮助你在提交 Pull Request 前一次通过所有检查。一、贡献入口不只是写代码CONTRIBUTING.md 开篇明确贡献 Day.js 的方式远不止修代码一条路——提交 Bug 报告、改进 locale本地化语言包和文档、帮助社区成员都是被欢迎的贡献形式。仓库中约 140 个 src/locale/ 语言文件从 af.js 到 zh.js本身就为 locale 类贡献提供了大量落点。文档同时声明了社区基调友好、欢迎、专业不容忍辱骂、骚扰或其他不可接受的行为。二、代码风格ES6 ESLint 的硬性约束CONTRIBUTING.md 的 Style 章节给出三条规则Day.js 使用 ES6 编写使用 ESLint 检查代码提交 PR 前运行npm run lint使用语义化提交信息semantic commit message。2.1npm run lint到底检查什么package.json 中 lint 脚本的定义为lint: ./node_modules/.bin/eslint src/* test/* build/*即对src/、test/、build/三个目录做全量检查——这意味着你的新代码和改动涉及的测试文件都必须在风格上合规。具体规则来自 .eslintrc.json可以提炼出几个写代码时必须遵守的要点配置项取值实际含义extendsairbnb-base以 Airbnb 基础风格为基线semi[error, never]禁止使用分号comma-dangle[error, never]禁止尾随逗号no-param-reassign0允许给参数重新赋值import/no-unresolved忽略dayjs测试中直接import dayjs from dayjs不会被判为未解析依赖pluginsjestjest/globals: trueit/expect等 Jest 全局可用且启用 Jest 专用 lint 规则注意globals中声明了window: true与dayjs: true这与 Day.js 面向浏览器/Node 双环境的测试方式一致。2.2 更底层的编辑器约定除了 ESLint仓库还通过 .editorconfig 统一了最基本的编辑习惯字符集utf-8换行符lfLF即 Unix 风格文件末尾必须保留一个空行insert_final_newline true缩进 2 个空格这些约定决定了你本地编辑器的默认行为应与仓库保持一致避免 PR 中出现纯换行符/缩进类的噪音 diff。2.3 提交前还有 pre-commit 兜底package.json 中定义了 pre-commit 钩子pre-commit: [lint]配合 devDependencies 中的pre-commit包安装依赖后每次git commit会自动触发 lint风格问题在提交前即被拦截。三、语义化提交不只是规范要求还驱动自动发版Please use semantic commit message 在 Day.js 里并非形式主义。从 .releaserc 可以看到项目使用 semantic-release 做自动化发布发布分支为master发布时自动更新并提交CHANGELOG.mdsemantic-release/changelogsemantic-release/gitassets 为CHANGELOG.md。也就是说提交信息的 typefeat:、fix:等会被 semantic-release 用来判断版本号升级策略并生成 CHANGELOG.md 条目。此外 .github/workflows/release.yml 显示推送到master后CI 会先跑 lint test再执行npm run build npm run babel、npm audit signatures验证产物签名最后运行npx semantic-release完成发版。对贡献者而言遵循语义化提交等于让自动化工具正确对待你的改动。四、Bug 报告先搜索再按模板提交CONTRIBUTING.md 的 Bugs 章节给出四条要求逐条展开提交前先搜索已有 issues——你的问题可能已被讨论甚至解决即使 issue 已关闭也欢迎补充评论标题和报告要详尽不要遗漏重要细节请使用英文。仓库里为第 3 条提供了具体抓手.github/ISSUE_TEMPLATE/--bug-report.md 是 Bug 报告模板要求填写Describe the bug清晰描述问题Expected behavior期望行为InformationDay.js 版本号如 v1.0.0、操作系统、浏览器及版本如 chrome 62、时区如 GMT-07:00 DST。特别要注意时区这一项。Day.js 是日期时间库大量 Bug尤其是 DST、跨时区 diff、startOf/endOf与时区强相关模板强制填写时区与下文测试体系中的多时区验证思路一脉相承——缺少时区信息的日期 Bug 报告很难被复现。五、测试规范目录约定、100% 覆盖率与多时区策略CONTRIBUTING.md 的 Tests 章节是全文最硬核的部分如果现有测试文件都不适合你的用例可以新建test/*.test.js文件帮我们保持 100% 测试覆盖率提交 PR 前运行npm run test。下面结合仓库配置逐条落地。5.1 Jest 配置哪些文件会被识别为测试package.json 中的 Jest 配置jest: { roots: [test], testRegex: test/(.*?/)?.*test.js$, testURL: http://localhost, coverageDirectory: ./coverage/, collectCoverage: true, collectCoverageFrom: [src/**/*] }要点testRegex: test/(.*?/)?.*test.js$精确解释了 CONTRIBUTING 中新建test/*.test.js的含义文件名必须以.test.js结尾、且放在test/目录含子目录下才会被 Jest 识别。现有测试按主题分目录组织核心行为如 test/manipulate.test.js、test/get-set.test.js、插件test/plugin/ 下每个插件一个文件如 test/plugin/weekday.test.js、localetest/locale/以及针对具体 issue 的回归测试test/issues/。collectCoverageFrom: [src/**/*]collectCoverage: true覆盖率统计范围是整个src/目录含全部 locale 与 plugin 源码这正是100% 覆盖率目标的范围定义。5.2npm run test四遍时区 100% 行覆盖门槛test脚本比跑一遍 Jest复杂得多test: cross-env TZPacific/Auckland npm run test-tz cross-env TZEurope/London npm run test-tz cross-env TZAmerica/Whitehorse npm run test-tz npm run test-tz jest --coverage --coverageThreshold\{ \\\global\\\: { \\\lines\\\: 100} }\, test-tz: date jest test/timezone.test --coveragefalse它分两步执行多时区预检以TZPacific/Auckland新西兰、Europe/London伦敦与America/Whitehorse白horse北美依次运行 test/timezone.test.js每轮前先date打印系统时间便于排查最后一遍不设置 TZ使用执行环境默认时区再跑一次。这三处时区恰好覆盖南半球与北半球的夏令时DST切换差异全量测试 覆盖门槛jest --coverage --coverageThreshold{ \global\: { \lines\: 100 } }——行覆盖率低于 100% 会直接导致测试命令失败这就是 Help us keep 100% test coverage 的工程化保证你的 PR 若没有为新代码补测试本地npm run test就会红。5.3 测试代码怎么写从现有用例提取模式阅读 test/timezone.test.js 与 test/plugin.test.js 可以归纳出仓库测试的通用模式供你写新测试时参照1用 MockDate 冻结现在几乎所有测试都用mockdate包在beforeEach/afterEach中控制时间import MockDate from mockdate beforeEach(() { MockDate.set(new Date()) }) afterEach(() { MockDate.reset() })2以 moment 为参照实现做行为对齐devDependencies 中固定了moment: 2.29.2与moment-timezone: 0.5.31用途是对照基准test/timezone.test.js 中大量断言形如expect(dayjs(2018-04-01).add(1, d).format()).toBe(moment(2018-04-01).add(1, d).format())即验证 Day.js 在 DST 边界、diff、utcOffset 等场景下与 moment 行为一致。写涉及边界行为的测试时这是仓库认可的做法。3插件测试直接调用dayjs.extendtest/plugin.test.js 展示了最小插件测试的写法定义一个会修改c.prototype注入实例方法和d注入静态方法的插件函数再断言dayjs().newApi()与dayjs.newFunc()的行为——这与 src/plugin/ 下所有插件的(o, c, d) ...签名一致也是你为新插件写测试时的模板。4dayjs依赖通过 mock 指回源码test/mocks/dayjs.js 仅两行const dayjs require(../../src) module.exports dayjs它让测试中import dayjs from dayjs实际解析到本地src/保证测试始终针对仓库当前代码而非已发布的 npm 版本。六、提交前的本地验证清单与 CI 校验把 CONTRIBUTING.md 的要求落成一份可执行的提交前清单# 1. 安装依赖含 pre-commit 钩子注册 npm install # 2. 代码风格检查等价于 lint 脚本eslint src/* test/* build/* npm run lint # 3. 多时区测试 全量测试 100% 行覆盖门槛 npm run testCI 侧会再做一次同样的校验。从 .github/workflows/check.yml 与 .github/workflows/lint-test.yml 可见触发时机推送到dev分支或指向dev的 Pull Request环境ubuntu-latest Nodelts/*启用 npm 缓存步骤npm install→npm run lint→npm test可选上传覆盖率到 Codecov。也就是说本地清单里任何一项失败PR 在 CI 中同样会失败——提交前本地跑通npm run lint npm run test是最省时间的做法。七、其他相关规范与工具速查围绕 CONTRIBUTING.md 的核心流程仓库中还有几处值得贡献者了解的配套设施文档格式package.json 中prettier脚本为prettier --write docs/**/*.md配合 prettier.config.js用于统一docs/下文档的排版改进 docs/en/、docs/zh-cn/ 等多语言文档时可用它保持一致风格。构建与体积约束build脚本为cross-env BABEL_ENVbuild node build npm run sizebabel.config.js 中build环境使用babel/preset-envmodules: false, loose: true同时 package.json 的size-limit将dayjs.min.js上限锁在2.99 KB——任何可能增大核心包体的改动都需要格外谨慎这也是 Day.js 保持 2kB 体量的工程化手段之一。自动发版.releaserc release.yml patches/ 中的semantic-releasegithub11.0.4.patch经npx patch-package应用共同构成master 推送即自动发版的流水线贡献者理解这一点就能明白语义化提交与 PR 合入master之间的关系。八、总结环节CONTRIBUTING.md 要求仓库中的落地证据代码风格ES6 ESLintPR 前npm run lint.eslintrc.jsonairbnb-base、禁分号/尾逗号、.editorconfig、pre-commit 钩子提交信息语义化提交.releaserc 的 semantic-release 配置、release.ymlBug 报告先搜索 issues、信息详尽、使用英文ISSUE_TEMPLATE 要求版本/OS/浏览器/时区测试可新建test/*.test.js保持 100% 覆盖PR 前npm run testpackage.json Jest 配置collectCoverageFrom: src/**/*、行覆盖门槛 100%、四遍多时区test-tz预检遵循上述流程——按 ES6 ESLint 风格写代码、用语义化信息提交、按模板提交 Bug、为新代码补足让行覆盖率维持在 100% 的测试并在本地跑通npm run lint与npm run test——你的 Pull Request 就能在 Day.js 的 CIlint 多时区测试 覆盖率门槛中顺利通过这也是仓库对每位贡献者的完整技术期待。【免费下载链接】dayjs⏰ Day.js 2kB immutable date-time library alternative to Moment.js with the same modern API项目地址: https://gitcode.com/gh_mirrors/da/dayjs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Day.js 贡献者实战指南：从代码风格规范到 100% 测试覆盖率的完整工作流
Day.js 贡献者实战指南从代码风格规范到 100% 测试覆盖率的完整工作流【免费下载链接】dayjs⏰ Day.js 2kB immutable date-time library alternative to Moment.js with the same modern API项目地址: https://gitcode.com/gh_mirrors/da/dayjs本文基于 Day.js 仓库的 CONTRIBUTING.md 展开系统梳理向 Day.js 提交贡献PR、Bug 报告、locale/文档改进的完整流程与硬性规范并结合 package.json、ESLint/Jest 配置与 GitHub Actions 工作流源码讲清楚代码风格、语义化提交、测试覆盖与 CI 校验的底层实现帮助你在提交 Pull Request 前一次通过所有检查。一、贡献入口不只是写代码CONTRIBUTING.md 开篇明确贡献 Day.js 的方式远不止修代码一条路——提交 Bug 报告、改进 locale本地化语言包和文档、帮助社区成员都是被欢迎的贡献形式。仓库中约 140 个 src/locale/ 语言文件从 af.js 到 zh.js本身就为 locale 类贡献提供了大量落点。文档同时声明了社区基调友好、欢迎、专业不容忍辱骂、骚扰或其他不可接受的行为。二、代码风格ES6 ESLint 的硬性约束CONTRIBUTING.md 的 Style 章节给出三条规则Day.js 使用 ES6 编写使用 ESLint 检查代码提交 PR 前运行npm run lint使用语义化提交信息semantic commit message。2.1npm run lint到底检查什么package.json 中 lint 脚本的定义为lint: ./node_modules/.bin/eslint src/* test/* build/*即对src/、test/、build/三个目录做全量检查——这意味着你的新代码和改动涉及的测试文件都必须在风格上合规。具体规则来自 .eslintrc.json可以提炼出几个写代码时必须遵守的要点配置项取值实际含义extendsairbnb-base以 Airbnb 基础风格为基线semi[error, never]禁止使用分号comma-dangle[error, never]禁止尾随逗号no-param-reassign0允许给参数重新赋值import/no-unresolved忽略dayjs测试中直接import dayjs from dayjs不会被判为未解析依赖pluginsjestjest/globals: trueit/expect等 Jest 全局可用且启用 Jest 专用 lint 规则注意globals中声明了window: true与dayjs: true这与 Day.js 面向浏览器/Node 双环境的测试方式一致。2.2 更底层的编辑器约定除了 ESLint仓库还通过 .editorconfig 统一了最基本的编辑习惯字符集utf-8换行符lfLF即 Unix 风格文件末尾必须保留一个空行insert_final_newline true缩进 2 个空格这些约定决定了你本地编辑器的默认行为应与仓库保持一致避免 PR 中出现纯换行符/缩进类的噪音 diff。2.3 提交前还有 pre-commit 兜底package.json 中定义了 pre-commit 钩子pre-commit: [lint]配合 devDependencies 中的pre-commit包安装依赖后每次git commit会自动触发 lint风格问题在提交前即被拦截。三、语义化提交不只是规范要求还驱动自动发版Please use semantic commit message 在 Day.js 里并非形式主义。从 .releaserc 可以看到项目使用 semantic-release 做自动化发布发布分支为master发布时自动更新并提交CHANGELOG.mdsemantic-release/changelogsemantic-release/gitassets 为CHANGELOG.md。也就是说提交信息的 typefeat:、fix:等会被 semantic-release 用来判断版本号升级策略并生成 CHANGELOG.md 条目。此外 .github/workflows/release.yml 显示推送到master后CI 会先跑 lint test再执行npm run build npm run babel、npm audit signatures验证产物签名最后运行npx semantic-release完成发版。对贡献者而言遵循语义化提交等于让自动化工具正确对待你的改动。四、Bug 报告先搜索再按模板提交CONTRIBUTING.md 的 Bugs 章节给出四条要求逐条展开提交前先搜索已有 issues——你的问题可能已被讨论甚至解决即使 issue 已关闭也欢迎补充评论标题和报告要详尽不要遗漏重要细节请使用英文。仓库里为第 3 条提供了具体抓手.github/ISSUE_TEMPLATE/--bug-report.md 是 Bug 报告模板要求填写Describe the bug清晰描述问题Expected behavior期望行为InformationDay.js 版本号如 v1.0.0、操作系统、浏览器及版本如 chrome 62、时区如 GMT-07:00 DST。特别要注意时区这一项。Day.js 是日期时间库大量 Bug尤其是 DST、跨时区 diff、startOf/endOf与时区强相关模板强制填写时区与下文测试体系中的多时区验证思路一脉相承——缺少时区信息的日期 Bug 报告很难被复现。五、测试规范目录约定、100% 覆盖率与多时区策略CONTRIBUTING.md 的 Tests 章节是全文最硬核的部分如果现有测试文件都不适合你的用例可以新建test/*.test.js文件帮我们保持 100% 测试覆盖率提交 PR 前运行npm run test。下面结合仓库配置逐条落地。5.1 Jest 配置哪些文件会被识别为测试package.json 中的 Jest 配置jest: { roots: [test], testRegex: test/(.*?/)?.*test.js$, testURL: http://localhost, coverageDirectory: ./coverage/, collectCoverage: true, collectCoverageFrom: [src/**/*] }要点testRegex: test/(.*?/)?.*test.js$精确解释了 CONTRIBUTING 中新建test/*.test.js的含义文件名必须以.test.js结尾、且放在test/目录含子目录下才会被 Jest 识别。现有测试按主题分目录组织核心行为如 test/manipulate.test.js、test/get-set.test.js、插件test/plugin/ 下每个插件一个文件如 test/plugin/weekday.test.js、localetest/locale/以及针对具体 issue 的回归测试test/issues/。collectCoverageFrom: [src/**/*]collectCoverage: true覆盖率统计范围是整个src/目录含全部 locale 与 plugin 源码这正是100% 覆盖率目标的范围定义。5.2npm run test四遍时区 100% 行覆盖门槛test脚本比跑一遍 Jest复杂得多test: cross-env TZPacific/Auckland npm run test-tz cross-env TZEurope/London npm run test-tz cross-env TZAmerica/Whitehorse npm run test-tz npm run test-tz jest --coverage --coverageThreshold\{ \\\global\\\: { \\\lines\\\: 100} }\, test-tz: date jest test/timezone.test --coveragefalse它分两步执行多时区预检以TZPacific/Auckland新西兰、Europe/London伦敦与America/Whitehorse白horse北美依次运行 test/timezone.test.js每轮前先date打印系统时间便于排查最后一遍不设置 TZ使用执行环境默认时区再跑一次。这三处时区恰好覆盖南半球与北半球的夏令时DST切换差异全量测试 覆盖门槛jest --coverage --coverageThreshold{ \global\: { \lines\: 100 } }——行覆盖率低于 100% 会直接导致测试命令失败这就是 Help us keep 100% test coverage 的工程化保证你的 PR 若没有为新代码补测试本地npm run test就会红。5.3 测试代码怎么写从现有用例提取模式阅读 test/timezone.test.js 与 test/plugin.test.js 可以归纳出仓库测试的通用模式供你写新测试时参照1用 MockDate 冻结现在几乎所有测试都用mockdate包在beforeEach/afterEach中控制时间import MockDate from mockdate beforeEach(() { MockDate.set(new Date()) }) afterEach(() { MockDate.reset() })2以 moment 为参照实现做行为对齐devDependencies 中固定了moment: 2.29.2与moment-timezone: 0.5.31用途是对照基准test/timezone.test.js 中大量断言形如expect(dayjs(2018-04-01).add(1, d).format()).toBe(moment(2018-04-01).add(1, d).format())即验证 Day.js 在 DST 边界、diff、utcOffset 等场景下与 moment 行为一致。写涉及边界行为的测试时这是仓库认可的做法。3插件测试直接调用dayjs.extendtest/plugin.test.js 展示了最小插件测试的写法定义一个会修改c.prototype注入实例方法和d注入静态方法的插件函数再断言dayjs().newApi()与dayjs.newFunc()的行为——这与 src/plugin/ 下所有插件的(o, c, d) ...签名一致也是你为新插件写测试时的模板。4dayjs依赖通过 mock 指回源码test/mocks/dayjs.js 仅两行const dayjs require(../../src) module.exports dayjs它让测试中import dayjs from dayjs实际解析到本地src/保证测试始终针对仓库当前代码而非已发布的 npm 版本。六、提交前的本地验证清单与 CI 校验把 CONTRIBUTING.md 的要求落成一份可执行的提交前清单# 1. 安装依赖含 pre-commit 钩子注册 npm install # 2. 代码风格检查等价于 lint 脚本eslint src/* test/* build/* npm run lint # 3. 多时区测试 全量测试 100% 行覆盖门槛 npm run testCI 侧会再做一次同样的校验。从 .github/workflows/check.yml 与 .github/workflows/lint-test.yml 可见触发时机推送到dev分支或指向dev的 Pull Request环境ubuntu-latest Nodelts/*启用 npm 缓存步骤npm install→npm run lint→npm test可选上传覆盖率到 Codecov。也就是说本地清单里任何一项失败PR 在 CI 中同样会失败——提交前本地跑通npm run lint npm run test是最省时间的做法。七、其他相关规范与工具速查围绕 CONTRIBUTING.md 的核心流程仓库中还有几处值得贡献者了解的配套设施文档格式package.json 中prettier脚本为prettier --write docs/**/*.md配合 prettier.config.js用于统一docs/下文档的排版改进 docs/en/、docs/zh-cn/ 等多语言文档时可用它保持一致风格。构建与体积约束build脚本为cross-env BABEL_ENVbuild node build npm run sizebabel.config.js 中build环境使用babel/preset-envmodules: false, loose: true同时 package.json 的size-limit将dayjs.min.js上限锁在2.99 KB——任何可能增大核心包体的改动都需要格外谨慎这也是 Day.js 保持 2kB 体量的工程化手段之一。自动发版.releaserc release.yml patches/ 中的semantic-releasegithub11.0.4.patch经npx patch-package应用共同构成master 推送即自动发版的流水线贡献者理解这一点就能明白语义化提交与 PR 合入master之间的关系。八、总结环节CONTRIBUTING.md 要求仓库中的落地证据代码风格ES6 ESLintPR 前npm run lint.eslintrc.jsonairbnb-base、禁分号/尾逗号、.editorconfig、pre-commit 钩子提交信息语义化提交.releaserc 的 semantic-release 配置、release.ymlBug 报告先搜索 issues、信息详尽、使用英文ISSUE_TEMPLATE 要求版本/OS/浏览器/时区测试可新建test/*.test.js保持 100% 覆盖PR 前npm run testpackage.json Jest 配置collectCoverageFrom: src/**/*、行覆盖门槛 100%、四遍多时区test-tz预检遵循上述流程——按 ES6 ESLint 风格写代码、用语义化信息提交、按模板提交 Bug、为新代码补足让行覆盖率维持在 100% 的测试并在本地跑通npm run lint与npm run test——你的 Pull Request 就能在 Day.js 的 CIlint 多时区测试 覆盖率门槛中顺利通过这也是仓库对每位贡献者的完整技术期待。【免费下载链接】dayjs⏰ Day.js 2kB immutable date-time library alternative to Moment.js with the same modern API项目地址: https://gitcode.com/gh_mirrors/da/dayjs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考