前端状态管理【免费下载链接】jotai Primitive and flexible state management for React项目地址https://gitcode.com/gh_mirrors/jo/jotai点击查看免费下载Jotai 是一个面向 React 的原始且灵活的状态管理库其仓库当前版本 2.20.2MIT 许可由src/核心实现、tests/测试、docs/文档源与website/Gatsby 文档站点等模块组成。本篇指南以仓库根目录下的 CONTRIBUTING.md 为骨架结合 package.json、vitest.config.mts、rollup.config.mjs、website/gatsby-config.js 等真实配置文件完整梳理从报告问题、提交规范、编写失败测试、构建验证到提交 Pull Request 的每一步帮助你以符合项目预期的方式为 Jotai 贡献代码或文档。一、仓库结构速览贡献者需要先知道的关键目录在动手之前先了解仓库的目录组织这会直接影响测试与文档改动的位置src/全部核心源码分为三个子包——vanilla/与框架无关的状态核心含 atom.ts、store.ts、internals.ts 及utils/下的 atomFamily、selectAtom、splitAtom 等工具、react/React 绑定含 useAtom、useAtomValue、useSetAtom 及utils/、babel/babel 插件与预设如 plugin-debug-label、plugin-react-refresh。tests/测试目录与src/一一对应tests/vanilla、tests/react、tests/babel。docs/文档源文件MDX 格式按basics/、core/、guides/、recipes/、utilities/、extensions/等分类组织。website/基于 Gatsby 的官方文档站点工程。examples/ 与 benchmarks/示例项目与性能基准可用于验证改动。rollup.config.mjs、vitest.config.mts、eslint.config.mjs、babel.config.mjs构建、测试、代码检查与转译配置。二、报告问题与发起讨论Issue 之前的必经步骤Jotai 的贡献规范要求一切问题与功能建议都先从 GitHub Discussions 的讨论开始而不是直接提交 Issue。根据 CONTRIBUTING.md 的约定讨论按类别分流场景讨论类别预期结果怀疑发现了 bugbug-report在讨论中确认问题表现与复现路径使用上的疑问q-a获得社区与维护者的解答新功能建议ideas先讨论该功能的使用场景再讨论具体实现方案对于新功能文档明确要求先确认讨论区中是否已存在同类提议若不存在则发起ideas讨论。维护者会基于讨论确认用例是否成立进而敲定实现方式——这意味着功能贡献的代码工作应在讨论收敛之后开始避免方向偏差造成返工。三、提交规范遵循 Conventional CommitsJotai 严格采用 Conventional Commits 规范即约定式提交每一次提交的 type 必须是以下六种之一提交类型含义feat新增功能fix修复 bugrefactor既不修复 bug 也不新增功能的代码改动chore构建流程、配置、依赖、CI/CD 管道等辅助工具的改动docs仅涉及文档的改动test补充缺失的测试或修正现有测试格式要点type 作为提交信息的第一个单词后跟冒号与空格描述以小写字母开头feat: add a foo type support还可以在 type 后使用括号指定作用域scopefix(react): change the bar parameter type结合本仓库的源码组织作用域通常可以对应到具体子包例如vanilla、react、babel或docs、website等。规范化的提交信息不仅便于维护者快速审阅 PR也让 CHANGELOG 的生成与版本发布自动化成为可能。四、开发工作流总览General无论贡献代码还是文档主流程一致Fork 本仓库。基于main分支创建新的功能分支。依据下面核心代码贡献或文档贡献部分完成开发。运行pnpm run fix:format格式化代码。暂存改动并提交遵循上文提交规范。提交 Pull Request 等待评审。其中格式化环节在 package.json 中的定义是prettier . --write即对整个仓库执行 Prettier 写回。仓库为 Prettier 配置了semi: false不加分号与singleQuote: true单引号提交前务必执行以确保风格一致。与之配套的还有两个相关命令pnpm run fix:lint执行eslint . --fix自动修复可修复的 lint 问题pnpm run fix依次执行 lint 修复与格式修复fix:lintfix:format。从 eslint.config.mjs 可以看到仓库使用 ESLint 的 flat config启用了eqeqeq、curly、sort-imports、import/order按 builtin/external/internal/parent/sibling/index 分组并字母序排列等规则对tests/**目录额外启用了 vitest、testing-library、jest-dom 三套插件且测试文件中import/extensions被设为never即测试内导入不写扩展名而普通源码要求显式扩展名。五、核心代码贡献Core六步完成一次代码改动1. 安装依赖pnpm install在仓库根目录执行pnpm install。项目使用 pnpm workspace 管理pnpm-workspace.yaml 声明了两个包根目录.与website。同时 package.json 通过packageManager: pnpm11.3.0锁定包管理器版本可配合 corepack 使用环境要求 Node.js12.20.0。2. 为你的修复或新功能编写失败测试这是核心贡献流程中最先动手的一步——先写会失败的测试再实现代码确保改动有测试覆盖。测试文件放在 tests/ 目录命名约定为纯逻辑测试用.test.ts如 tests/vanilla/utils/atomFamily.test.ts涉及 React 渲染的用.test.tsx如 tests/vanilla/basic.test.tsx、tests/react/basic.test.tsx。测试基础设施由 vitest.config.mts 定义测试环境为jsdom并开启globals同时触发 React Testing Library 的自动 cleanup通过 alias 将jotai与jotai/xxx直接指向 src/index.ts 等源码文件因此测试中可以直接写import { atom } from jotai/vanilla来测试未构建的源码tests/setup.ts 引入testing-library/jest-dom/vitest提供 jest-dom 的自定义断言。例如 tests/vanilla/basic.test.tsx 展示了atom()的四种创建形式原始 atom、只读派生 atom、读写派生 atom 与只写派生 atom可作为编写新测试的模板参考。测试还覆盖了异步tests/react/async.test.tsx、依赖追踪tests/react/dependency.test.tsx、错误处理tests/react/error.test.tsx、内存泄漏tests/vanilla/memoryleaks.test.ts等专题新功能若涉及相应领域可在对应专题文件中补充用例。3. 实现你的改动在 src/ 对应子包中实现功能或修复。核心 API 的入口文件是 src/index.ts聚合 React 绑定、src/vanilla.ts 与 src/utils.ts子包内的工具函数位于各utils/目录。4. 构建库pnpm run buildpnpm run build是完整的发布前构建。从 package.json 的脚本定义看它依次执行prebuildshx rm -rf dist清空旧产物build:*并行运行全部子构建包括build:base主入口rollup -c、build:vanilla、build:vanilla:utils、build:vanilla:internals、build:react、build:react:utils、build:utils、build:babel:plugin-debug-label、build:babel:plugin-react-refresh、build:babel:preset等postbuild依次执行patch-d-ts修正声明文件中的导入路径、copy复制产物并生成 ts3.8 兼容类型与 ESM 声明、patch-ts3.8、patch-old-ts、patch-esm-ts、patch-readme等收尾脚本。构建配置集中在 rollup.config.mjs为每个入口产出 CJSdist/*.js、ESMdist/esm/*.mjs、UMDdist/umd/*.development.js与*.production.js生产版经 terser 压缩以及 SystemJSdist/system/*共多种格式并为 React 相关产物注入use client指令。提示如果只想在改动后持续监听并重新构建文档推荐使用pnpm run build-watch即pnpm run /^build:.*/ --watch它会在 watch 模式下运行全部子构建适合边改边验。5. 运行测试并确保全部通过执行pnpm run test。该命令会依次运行pnpm run /^test:.*/test:formatprettier . --list-different检查格式是否一致不通过说明需要先跑fix:formattest:typestsc --noEmit基于 tsconfig.json 做全量类型检查test:linteslint .静态代码检查test:specvitest run运行全部单元与集成测试。四者全部通过才算测试就绪。若改动涉及性能敏感路径仓库还提供pnpm run benchnpx tsx benchmarks/run-all.ts运行 benchmarks/ 下的性能基准可用于观察改动是否引入明显回归。6. 本地联调pnpm link 或 CodeSandbox CI canary构建与测试通过后你可以在自己的真实项目中验证改动pnpm link在仓库根目录执行pnpm link将开发中的包注册为全局软链接然后在目标项目中执行pnpm link jotai以及需要验证的子路径即可引用本地版本CodeSandbox CI canary提交 PR 后CodeSandbox CI 会自动生成 canary 版本你可以在自己的项目中安装该 canary 版本来验证改动而无需本地链接。完成以上步骤后回到开发工作流总览的第 4 步继续格式化 → 提交 → 提 PR。六、文档贡献Documentation在本地运行文档站点Jotai 的文档与代码同仓维护贡献文档有一套独立的本地预览流程进入 website/ 目录如cd website在该目录执行pnpm install安装站点依赖执行pnpm run dev启动开发服务器。根据 website/package.json该命令实为gatsby develop -H 0.0.0.0 -p 9000监听所有网卡、端口 9000浏览器访问http://localhost:9000查看文档修改 docs/ 目录下的文档文件MDX 格式浏览器会热重载展示你的改动完成后回到总览工作流第 4 步格式化 → 提交 → 提 PR。理解站点如何加载文档有助于定位改动位置website/gatsby-config.js 通过gatsby-source-filesystem将../docs即仓库根目录的 docs/注册为文档源配合gatsby-plugin-mdx将.md/.mdx渲染为页面并用 Algolia 建立全文搜索索引website/gatsby-config.js 中的 DOCS_QUERY 会抓取每篇文档的标题、description、keywords、H2 标题与正文。文档内容的组织方式可参考 docs/index.mdx 与 docs/core/atom.mdx 等既有页面保持风格与 API 描述的一致性。七、Pull Request 规范提交 PR 时注意两点保持范围聚焦尽量让 PR 只解决一个问题避免混入无关提交这能显著加快评审速度勾选 Allow edits from maintainers文档建议在 PR 页面勾选允许维护者编辑这样维护者可以直接在你的分支上做出小幅修正或补充减少来回沟通成本。提交后维护者会尽快响应过程中可能建议调整或要求改进届时在 PR 讨论中继续协作即可。结语整个贡献流程可以浓缩为一条主线先讨论、后实现、测试先行、构建验证、规范提交。无论你打算修复 src/ 中的核心逻辑、补充 tests/ 下的测试用例还是完善 docs/ 中的文档章节遵循 CONTRIBUTING.md 中描述的讨论分流、Conventional Commits 提交规范与 Core/Documentation 两套开发流程都能让改动更快地被维护者接纳。从一条fix: ...或docs: ...的规范提交开始你就已经进入了 Jotai 的协作节奏。赞分享前端状态管理【免费下载链接】jotai Primitive and flexible state management for React项目地址https://gitcode.com/gh_mirrors/jo/jotai点击查看免费下载相关推荐MkDocs 贡献指南从提交 Issue 到合入 Pull Request 的完整开发工作流MkDocs 贡献指南从提交 Issue 到合入 Pull Request 的完整开发工作流 MkDocs 是一个基于 Markdown 构建项目文档的静态站文档UniGetUI 贡献指南从 Issue 提交到 Pull Request 的完整开发协作流程UniGetUI 贡献指南从 Issue 提交到 Pull Request 的完整开发协作流程 导读 本文基于 UniGetUI 仓库根目录下的 CONTRI桌面应用开发工具跨平台PairDrop开源社区贡献指南Issue报告与Pull Request规范PairDrop开源社区贡献指南Issue报告与Pull Request规范 你是否在使用PairDrop时遇到过功能异常或者有绝佳的改进点子却不知如何提交后端前端上一篇Tensor Comprehensions入门指南如何用DSL自动生成高性能机器学习内核下一篇DeepSeek-V3.1进阶开发自定义专家路由与多模态扩展创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Jotai 贡献指南：从 Issue 报告到 Pull Request 提交的完整开发工作流
前端状态管理【免费下载链接】jotai Primitive and flexible state management for React项目地址https://gitcode.com/gh_mirrors/jo/jotai点击查看免费下载Jotai 是一个面向 React 的原始且灵活的状态管理库其仓库当前版本 2.20.2MIT 许可由src/核心实现、tests/测试、docs/文档源与website/Gatsby 文档站点等模块组成。本篇指南以仓库根目录下的 CONTRIBUTING.md 为骨架结合 package.json、vitest.config.mts、rollup.config.mjs、website/gatsby-config.js 等真实配置文件完整梳理从报告问题、提交规范、编写失败测试、构建验证到提交 Pull Request 的每一步帮助你以符合项目预期的方式为 Jotai 贡献代码或文档。一、仓库结构速览贡献者需要先知道的关键目录在动手之前先了解仓库的目录组织这会直接影响测试与文档改动的位置src/全部核心源码分为三个子包——vanilla/与框架无关的状态核心含 atom.ts、store.ts、internals.ts 及utils/下的 atomFamily、selectAtom、splitAtom 等工具、react/React 绑定含 useAtom、useAtomValue、useSetAtom 及utils/、babel/babel 插件与预设如 plugin-debug-label、plugin-react-refresh。tests/测试目录与src/一一对应tests/vanilla、tests/react、tests/babel。docs/文档源文件MDX 格式按basics/、core/、guides/、recipes/、utilities/、extensions/等分类组织。website/基于 Gatsby 的官方文档站点工程。examples/ 与 benchmarks/示例项目与性能基准可用于验证改动。rollup.config.mjs、vitest.config.mts、eslint.config.mjs、babel.config.mjs构建、测试、代码检查与转译配置。二、报告问题与发起讨论Issue 之前的必经步骤Jotai 的贡献规范要求一切问题与功能建议都先从 GitHub Discussions 的讨论开始而不是直接提交 Issue。根据 CONTRIBUTING.md 的约定讨论按类别分流场景讨论类别预期结果怀疑发现了 bugbug-report在讨论中确认问题表现与复现路径使用上的疑问q-a获得社区与维护者的解答新功能建议ideas先讨论该功能的使用场景再讨论具体实现方案对于新功能文档明确要求先确认讨论区中是否已存在同类提议若不存在则发起ideas讨论。维护者会基于讨论确认用例是否成立进而敲定实现方式——这意味着功能贡献的代码工作应在讨论收敛之后开始避免方向偏差造成返工。三、提交规范遵循 Conventional CommitsJotai 严格采用 Conventional Commits 规范即约定式提交每一次提交的 type 必须是以下六种之一提交类型含义feat新增功能fix修复 bugrefactor既不修复 bug 也不新增功能的代码改动chore构建流程、配置、依赖、CI/CD 管道等辅助工具的改动docs仅涉及文档的改动test补充缺失的测试或修正现有测试格式要点type 作为提交信息的第一个单词后跟冒号与空格描述以小写字母开头feat: add a foo type support还可以在 type 后使用括号指定作用域scopefix(react): change the bar parameter type结合本仓库的源码组织作用域通常可以对应到具体子包例如vanilla、react、babel或docs、website等。规范化的提交信息不仅便于维护者快速审阅 PR也让 CHANGELOG 的生成与版本发布自动化成为可能。四、开发工作流总览General无论贡献代码还是文档主流程一致Fork 本仓库。基于main分支创建新的功能分支。依据下面核心代码贡献或文档贡献部分完成开发。运行pnpm run fix:format格式化代码。暂存改动并提交遵循上文提交规范。提交 Pull Request 等待评审。其中格式化环节在 package.json 中的定义是prettier . --write即对整个仓库执行 Prettier 写回。仓库为 Prettier 配置了semi: false不加分号与singleQuote: true单引号提交前务必执行以确保风格一致。与之配套的还有两个相关命令pnpm run fix:lint执行eslint . --fix自动修复可修复的 lint 问题pnpm run fix依次执行 lint 修复与格式修复fix:lintfix:format。从 eslint.config.mjs 可以看到仓库使用 ESLint 的 flat config启用了eqeqeq、curly、sort-imports、import/order按 builtin/external/internal/parent/sibling/index 分组并字母序排列等规则对tests/**目录额外启用了 vitest、testing-library、jest-dom 三套插件且测试文件中import/extensions被设为never即测试内导入不写扩展名而普通源码要求显式扩展名。五、核心代码贡献Core六步完成一次代码改动1. 安装依赖pnpm install在仓库根目录执行pnpm install。项目使用 pnpm workspace 管理pnpm-workspace.yaml 声明了两个包根目录.与website。同时 package.json 通过packageManager: pnpm11.3.0锁定包管理器版本可配合 corepack 使用环境要求 Node.js12.20.0。2. 为你的修复或新功能编写失败测试这是核心贡献流程中最先动手的一步——先写会失败的测试再实现代码确保改动有测试覆盖。测试文件放在 tests/ 目录命名约定为纯逻辑测试用.test.ts如 tests/vanilla/utils/atomFamily.test.ts涉及 React 渲染的用.test.tsx如 tests/vanilla/basic.test.tsx、tests/react/basic.test.tsx。测试基础设施由 vitest.config.mts 定义测试环境为jsdom并开启globals同时触发 React Testing Library 的自动 cleanup通过 alias 将jotai与jotai/xxx直接指向 src/index.ts 等源码文件因此测试中可以直接写import { atom } from jotai/vanilla来测试未构建的源码tests/setup.ts 引入testing-library/jest-dom/vitest提供 jest-dom 的自定义断言。例如 tests/vanilla/basic.test.tsx 展示了atom()的四种创建形式原始 atom、只读派生 atom、读写派生 atom 与只写派生 atom可作为编写新测试的模板参考。测试还覆盖了异步tests/react/async.test.tsx、依赖追踪tests/react/dependency.test.tsx、错误处理tests/react/error.test.tsx、内存泄漏tests/vanilla/memoryleaks.test.ts等专题新功能若涉及相应领域可在对应专题文件中补充用例。3. 实现你的改动在 src/ 对应子包中实现功能或修复。核心 API 的入口文件是 src/index.ts聚合 React 绑定、src/vanilla.ts 与 src/utils.ts子包内的工具函数位于各utils/目录。4. 构建库pnpm run buildpnpm run build是完整的发布前构建。从 package.json 的脚本定义看它依次执行prebuildshx rm -rf dist清空旧产物build:*并行运行全部子构建包括build:base主入口rollup -c、build:vanilla、build:vanilla:utils、build:vanilla:internals、build:react、build:react:utils、build:utils、build:babel:plugin-debug-label、build:babel:plugin-react-refresh、build:babel:preset等postbuild依次执行patch-d-ts修正声明文件中的导入路径、copy复制产物并生成 ts3.8 兼容类型与 ESM 声明、patch-ts3.8、patch-old-ts、patch-esm-ts、patch-readme等收尾脚本。构建配置集中在 rollup.config.mjs为每个入口产出 CJSdist/*.js、ESMdist/esm/*.mjs、UMDdist/umd/*.development.js与*.production.js生产版经 terser 压缩以及 SystemJSdist/system/*共多种格式并为 React 相关产物注入use client指令。提示如果只想在改动后持续监听并重新构建文档推荐使用pnpm run build-watch即pnpm run /^build:.*/ --watch它会在 watch 模式下运行全部子构建适合边改边验。5. 运行测试并确保全部通过执行pnpm run test。该命令会依次运行pnpm run /^test:.*/test:formatprettier . --list-different检查格式是否一致不通过说明需要先跑fix:formattest:typestsc --noEmit基于 tsconfig.json 做全量类型检查test:linteslint .静态代码检查test:specvitest run运行全部单元与集成测试。四者全部通过才算测试就绪。若改动涉及性能敏感路径仓库还提供pnpm run benchnpx tsx benchmarks/run-all.ts运行 benchmarks/ 下的性能基准可用于观察改动是否引入明显回归。6. 本地联调pnpm link 或 CodeSandbox CI canary构建与测试通过后你可以在自己的真实项目中验证改动pnpm link在仓库根目录执行pnpm link将开发中的包注册为全局软链接然后在目标项目中执行pnpm link jotai以及需要验证的子路径即可引用本地版本CodeSandbox CI canary提交 PR 后CodeSandbox CI 会自动生成 canary 版本你可以在自己的项目中安装该 canary 版本来验证改动而无需本地链接。完成以上步骤后回到开发工作流总览的第 4 步继续格式化 → 提交 → 提 PR。六、文档贡献Documentation在本地运行文档站点Jotai 的文档与代码同仓维护贡献文档有一套独立的本地预览流程进入 website/ 目录如cd website在该目录执行pnpm install安装站点依赖执行pnpm run dev启动开发服务器。根据 website/package.json该命令实为gatsby develop -H 0.0.0.0 -p 9000监听所有网卡、端口 9000浏览器访问http://localhost:9000查看文档修改 docs/ 目录下的文档文件MDX 格式浏览器会热重载展示你的改动完成后回到总览工作流第 4 步格式化 → 提交 → 提 PR。理解站点如何加载文档有助于定位改动位置website/gatsby-config.js 通过gatsby-source-filesystem将../docs即仓库根目录的 docs/注册为文档源配合gatsby-plugin-mdx将.md/.mdx渲染为页面并用 Algolia 建立全文搜索索引website/gatsby-config.js 中的 DOCS_QUERY 会抓取每篇文档的标题、description、keywords、H2 标题与正文。文档内容的组织方式可参考 docs/index.mdx 与 docs/core/atom.mdx 等既有页面保持风格与 API 描述的一致性。七、Pull Request 规范提交 PR 时注意两点保持范围聚焦尽量让 PR 只解决一个问题避免混入无关提交这能显著加快评审速度勾选 Allow edits from maintainers文档建议在 PR 页面勾选允许维护者编辑这样维护者可以直接在你的分支上做出小幅修正或补充减少来回沟通成本。提交后维护者会尽快响应过程中可能建议调整或要求改进届时在 PR 讨论中继续协作即可。结语整个贡献流程可以浓缩为一条主线先讨论、后实现、测试先行、构建验证、规范提交。无论你打算修复 src/ 中的核心逻辑、补充 tests/ 下的测试用例还是完善 docs/ 中的文档章节遵循 CONTRIBUTING.md 中描述的讨论分流、Conventional Commits 提交规范与 Core/Documentation 两套开发流程都能让改动更快地被维护者接纳。从一条fix: ...或docs: ...的规范提交开始你就已经进入了 Jotai 的协作节奏。赞分享前端状态管理【免费下载链接】jotai Primitive and flexible state management for React项目地址https://gitcode.com/gh_mirrors/jo/jotai点击查看免费下载相关推荐MkDocs 贡献指南从提交 Issue 到合入 Pull Request 的完整开发工作流MkDocs 贡献指南从提交 Issue 到合入 Pull Request 的完整开发工作流 MkDocs 是一个基于 Markdown 构建项目文档的静态站文档UniGetUI 贡献指南从 Issue 提交到 Pull Request 的完整开发协作流程UniGetUI 贡献指南从 Issue 提交到 Pull Request 的完整开发协作流程 导读 本文基于 UniGetUI 仓库根目录下的 CONTRI桌面应用开发工具跨平台PairDrop开源社区贡献指南Issue报告与Pull Request规范PairDrop开源社区贡献指南Issue报告与Pull Request规范 你是否在使用PairDrop时遇到过功能异常或者有绝佳的改进点子却不知如何提交后端前端上一篇Tensor Comprehensions入门指南如何用DSL自动生成高性能机器学习内核下一篇DeepSeek-V3.1进阶开发自定义专家路由与多模态扩展创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考