开发工具【免费下载链接】dsa.js-data-structures-algorithms-javascriptData Structures and Algorithms explained and implemented in JavaScript eBook项目地址https://gitcode.com/gh_mirrors/ds/dsa.js-data-structures-algorithms-javascript点击查看免费下载导读本文基于 CONTRIBUTING.md 展开系统讲解如何为 dsa.jsData Structures Algorithms in JavaScript一个以源码 电子书形式实现的算法与数据结构开源仓库提交高质量贡献涵盖 Issue 提交、Pull Request 全流程、基于 Conventional Commits 的提交信息规范以及由 ESLint 与 Jest 驱动的测试/CI 机制。读完本文你将掌握一套可直接复用的开源协作流程并理解仓库中package.json、.eslintrc.js、jest.config.js等配置文件是如何支撑这些规则的。说明仓库当前为只读镜像本文只介绍查看、安装、运行与配置方式不涉及对仓库内容的修改操作。贡献方式总览dsa.js 欢迎任何形式的贡献包括 Issue、评论与 Pull Request。文档给出的三条核心原则是协作的基石写测试如果适用仓库尽量接近 100% 代码覆盖率任何新代码都应配套测试。遵循 Linter项目使用 ESLint 并采用 Airbnb JavaScript StyleguideCI 构建Travis/CircleCI中会执行npm run lint。不确定就提问实现修复或功能时如有疑问可以创建 Issue 询问维护者。这三条原则并非空话仓库的配置文件给出了具体落地证据代码风格由 .eslintrc.js 定义它extends: airbnb-base并启用了jest插件在env中声明jest: true测试框架与覆盖率在 package.json 的脚本中体现test运行jest --verboseci运行npm run lint:base jest --coverage代码提交前的质量门禁由 husky 提供pre-push: npm run ci见 package.json 的husky.hooks也就是说每次git push都会先自动跑完 lint 测试 覆盖率不合格则推送被阻止。提交 Issue 的指南在提交 Issue 之前请先搜索 issue 跟踪器也许你的问题已有人提出相关讨论可能直接给出了可用的 workaround避免重复劳动。这条前置检查与提交 PR 前的先搜索、再动手原则一脉相承是高效协作的第一步。提交 Pull RequestPR的完整流程提交前的准备在动手写代码前文档要求依次确认以下事项先搜索已有的 open 或 closed PR确认没有重复工作确保有一个 Issue 描述了你要修复的问题或记录了你要实现的功能设计——先讨论设计再提交代码这样维护者更容易接受你的工作将amejiarosario/dsa.js仓库 fork 到自己名下基于 master 新建一个功能分支git checkout -b my-fix-branch master创建你的补丁务必包含相应的测试用例运行完整测试套件确保全部通过用描述性的提交信息提交变更必须遵循本文下半部分的提交信息规范因为release notes 是由这些提交信息自动生成的git commit -a注git commit -a可选的-a选项会自动对已修改add和已删除rm的文件执行暂存。推送分支到 GitHubgit push origin my-fix-branch在 GitHub 上向dsa.js:master发送 Pull Request。根据反馈修改如果维护者建议修改你需要完成要求更新重新运行测试套件确认仍然通过Rebase 分支并强制推送以更新 PRgit rebase master -i git push -fPR 合并之后的清理PR 合并后即可安全地删除分支并同步上游# 删除远程分支可通过 GitHub Web UI或在本地 shell 执行 git push origin --delete my-fix-branch # 切回 master git checkout master -f # 删除本地分支 git branch -D my-fix-branch # 用最新上游版本更新你的 master git pull --ff upstream masterCommit Message 规范为什么它如此重要dsa.js 的提交信息之所以有严格格式文档明确说明了两点一是让项目历史更易读、易追溯二是项目用提交信息自动生成 change log。仓库的 package.json 证实了这一点release配置使用semantic-release其插件链包含semantic-release/commit-analyzer、semantic-release/release-notes-generator、semantic-release/changelog等devDependencies中还有commitizen与cz-conventional-changelog用于交互式生成符合规范的提交信息。也就是说一条不合规的 commit message 会直接影响版本号决策与 CHANGELOG 的质量。仓库根目录的 CHANGELOG.md 就是这套机制的直接产物例如## 2.7.6 (2021-11-30) ### Bug Fixes * **graph:** minor typo in bfs code documentation (...), closes #110 ## 2.7.5 (2021-05-24) ### Bug Fixes * **bst:** on duplicates values the same node is returned (...), closes #99可见每个变更都带上了 typeBug Fixes、scopegraph/bst与 closes 引用这正是下面格式规范的成果。提交信息格式每条提交信息由header、body和footer组成header 又包含type、scope与subjecttype(scope): subject 空行 body 空行 footer一个包含 header、body、footer 的完整示例fix(linked-list): insert in the middle bug One reference was not updated when inserting an item in the middle of a linked list. Fixes: #8硬性约束包括header 是必填的其中的 scope 可选提交信息每一行不能超过 100 个字符以保证在 GitHub 和各种 git 工具中易读footer 中应包含 issue 的关闭引用如Fixes: #8、Closes #234如果存在的话。更多示例feat(heap): add error handling for heaps BREAKING CHANGE: size is now an attribute rather than a method. Similar to the built-in Map.size and Set.sizefix(book/solutions): fix missing solutionsRevert回滚提交如果某次提交是对先前提交的回滚信息应以revert:开头并紧跟被回滚提交的 headerbody 中应写明This reverts commit hash.其中 hash 是被回滚提交的 SHA。Type三种必选类型fixBug 修复feat新功能choreCI 配置文件与脚本的变更示例 scopeCircle、BrowserStack、SauceLabs。仓库的 package.jsonconfig.commitizen.types也印证了这三类并为它们定义了 CHANGELOG 分组标题Features ✨ / Bug Fixes / Chores 同时还补充了各自的适用语义feat是在代码和/或书上引入新功能fix是修复代码或书上的 bugchore是不修改代码或书文件的其他变更。Scope以主目录名为准scope 应使用主目录名推荐的示例包括listmaptreegraphsortingbook等等这些 scope 与仓库实际目录一一对应src/data-structures 下的linked-lists、maps、trees、graphs、stacks、queues、heaps、sets、arrayssrc/algorithms 下的sorting目录以及 book 目录。CHANGELOG 中的graph、bst、book、linkedlist、hashmap、test等 scope 都是这一约定的实际应用。Subject简洁描述使用祈使句、一般现在时写 change而不是 changed 或 changes首字母不要大写结尾不要加句号。Body动机与对比body 与 subject 一样使用祈使句、一般现在时应包含变更的动机并与先前行为作对比。FooterBreaking Changes 与 Issue 引用footer 用于记录BREAKING CHANGES信息也是引用本次提交所Closes的 GitHub issue 的位置Closes #234Breaking Changes应以BREAKING CHANGE:开头后跟空格或两个换行其余内容接着书写。破坏性变更的常见示例包括删除或重新定义现有 API 参数改变返回值删除或修改 options 参数对象上的现有属性添加或移除错误改变某个事件的预期触发时机改变使用特定 API 的副作用。仓库中的测试与 CI 落地规则如何被执行贡献指南要求的写测试 100% 覆盖率 过 lint在仓库中有完整的工具链支撑新贡献者可以在提交前用以下命令本地自检见 package.json 的scriptsnpm run lint # npm run lint:base -- --format codeframe对 src 与 book/interview-questions 下的 js 执行 ESLint带修复 npm test # jest --verbose npm run ci # npm run lint:base jest --coverage与 husky pre-push 挂钩 npm run coverage # jest --coverage 并打开 lcov 覆盖率报告几个值得注意的实现细节Lint 范围lint:base为npx eslint --fix {src,book/interview-questions}/**/*.js即只检查src目录和 book/interview-questions 目录该目录存放电子书附带的面试题实现与.spec.js测试ESLint 规则.eslintrc.js 基于airbnb-base并针对算法/数据结构代码做了三处定制——no-param-reassign允许给对象参数添加属性、no-plusplus允许 for 循环更新表达式中的/--、no-restricted-syntax允许for..of同时通过 jest 插件把jest/no-focused-tests设为 error禁止把.only留在测试中测试范围jest.config.js 通过testPathIgnorePatterns排除了/node_modules/、/dist/、/lab/、/benchmarks/、/coverage/即正式测试聚焦于src与book/interview-questions而lab练习与benchmarks基准不纳入常规测试测试风格仓库测试统一从 src/index.js 导出入口引入被测结构例如 stack.spec.js 中const { Stack } require(../../index)然后按describe → beforeEach → it组织用例覆盖边界行为如空栈pop()返回null。提交新功能时参照同目录下已有*.spec.js的写法即可保持一致版本发布semantic-release按 tag 格式${version}发布semantic-release/git会自动生成chore(release)提交进一步印证了commit message 决定 changelog的机制。贡献自检清单提交 PR 前对照以下清单逐项确认可大幅提高被合并的概率已搜索 issue / PR确认无重复工作已有对应 Issue 描述问题或功能设计基于新分支开发git checkout -b my-fix-branch master新代码附带了完整的*.spec.js测试用例并覆盖边界情况本地npm run ci全部通过lint 测试 覆盖率提交信息遵循type(scope): subject格式行宽 ≤ 100 字符必要时包含 body 与 footer如需破坏性变更已在 footer 中标注BREAKING CHANGE:PR 被要求修改后执行git rebase master -i与git push -f更新分支。遵循这些约定你的贡献不仅能顺利合并还会自动成为 CHANGELOG.md 与 npm 版本发布记录的一部分——这正是用规范换取自动化的开源协作精髓。赞分享开发工具【免费下载链接】dsa.js-data-structures-algorithms-javascriptData Structures and Algorithms explained and implemented in JavaScript eBook项目地址https://gitcode.com/gh_mirrors/ds/dsa.js-data-structures-algorithms-javascript点击查看免费下载相关推荐HIXL 开源贡献实战指南从 Issue 协作、PR 规范到 pre-commit 合规检查的完整流程HIXL 开源贡献实战指南从 Issue 协作、PR 规范到 pre commit 合规检查的完整流程 HIXLHuawei Xfer Library是昇通信网络高性能计算CANNAscendCANN graph-autofusion 贡献指南从 Issue 讨论、代码规范到 pre-commit 与 PR 合入的完整实战流程CANN graph autofusion 贡献指南从 Issue 讨论、代码规范到 pre commit 与 PR 合入的完整实战流程 本篇技术指南以 CA人工智能模型编译AscendKlavis AI贡献者手册从提交规范到PR流程Klavis AI贡献者手册从提交规范到PR流程 贡献者协议与行为准则 在参与Klavis AI开源项目前所有贡献者需签署 贡献者许可协议 CLA httpAI 应用LLM 网关MCP 服务工具调用上一篇OpenLLaMA 3B进阶技巧调整max_new_tokens参数提升长文本生成质量下一篇3个步骤掌握gifski让GIF动图告别马赛克的专业编码器创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考