低代码前端后端【免费下载链接】plasmicVisual builder for React. Build apps, websites, and content. Integrate with your codebase.项目地址https://gitcode.com/gh_mirrors/pl/plasmic点击查看免费下载导读本文以 Plasmic 开源仓库根目录的 CLAUDE.md 为主线系统梳理这个 monorepo 的目录结构、根目录集中管理工具、技术栈与 AI 辅助开发工作流约定。读完本文你将理解 Plasmic 平台应用platform/、SDK 包packages/与代码组件包plasmicpkgs/三大板块的边界与协作方式掌握pnpm工作区、版本管理、代码格式化的实际机制并熟悉在此仓库中开展开发、测试与提交的正确姿势。一、CLAUDE.md 是什么AI 辅助开发的仓库宪法在 Plasmic 仓库根目录CLAUDE.md是一份面向 AI 编码助手的规范指令文件。仓库中 AGENTS.md 是它的符号链接symlink两者指向同一份内容。项目约定明确修改时只编辑CLAUDE.md绝不直接编辑AGENTS.md以避免两份文件内容漂移。这份指令文件的价值在于它锚定了整个仓库的关键事实让 AI 助手以及新加入的开发者在最省力的前提下掌握根目录集中管理哪些工程化资产四个核心目录各自承担什么职责采用什么技术栈、包管理器与测试框架提交代码前有哪些流程与前置条件搜索文件时应避开哪些目录。此外指令是按目录作用域叠加的距离某个路径最近的CLAUDE.md对该路径生效并在根文件基础上做增量补充而非互相矛盾。例如平台侧的 platform/wab/CLAUDE.md 就专门针对 WABWeb Application BuilderPlasmic Studio 核心应用补充了关键命令与编码约定根文件明确要求修改platform/wab下任何内容之前先读它。二、根目录的集中管理资产CLAUDE.md 明确指出本目录是 monorepo 的根绝大多数开发在各自包内进行但根目录负责若干集中管理的工程化事项逐项展开如下。package.json统一依赖版本根 package.json 中存放的是希望全仓库使用同一版本的公共 devDependencies例如eslint、eslint-config-prettier、eslint-plugin-react、eslint-plugin-react-hooks等 lint 工具链prettier与prettier-plugin-organize-imports格式化链vitest、tstyche、storybook及storybook/*组件库测试链typescript、tsx、vite、esbuild、lerna、nx、knip等构建与工程工具husky、lint-staged等 git 钩子工具。其中的packageManager: pnpm11.10.0声明了仓库统一使用的包管理器版本配合 pnpm-workspace.yaml 定义整个工作区。依赖版本大量使用catalog:引用——这是 pnpm 的目录catalog特性版本号集中在 pnpm-workspace.yaml 的catalog段统一维护例如typescript: 5.2.2、react: 18.3.1、vitest: 4.1.10避免各包重复维护版本号。build.mjs统一的构建脚本build.mjs 是packages/的通用构建脚本其头部注释点明职责跨包一致地校验 package.json 并构建产物。从源码结构看build.mjs它主要完成三件事接收入口文件路径作为首个命令行参数并解析--use-client、--no-esm、--no-mjs、--watch等选项根据入口文件名生成期望的 package.json与实际 package.json 比对校验包括 react-server conditional exports保证产物导出结构符合约定调用 esbuild 构建 bundle并借助microsoft/api-extractor对 dts 进行 rollup产出统一的类型声明。这解释了为什么所有packages/下包的产物形态高度一致构建行为由根目录脚本集中治理。.eslintrc.js共享 lint 配置根 .eslintrc.js 定义了共享的 ESLint 配置其中最有特色的是按目录区分 client/server/test 文件的规则.eslintrc.jsclientFilesplatform/wab/src/wab/main.tsx与src/wab/client/**serverFilessrc/wab/server/**testFiles**/*.spec.ts(x)、**/*.test.ts(x)、**/*.stories.tsx、**/__testonly__/**、**/__mocks__/**等。它还实现了一个overlay查找机制findOverlayTargets.eslintrc.js自动识别foo.external.ts、foo.public.ts这类占位文件分别用于 public 与 enterprise 同步时替换真实实现确保 lint 覆盖到这类特殊文件。vitest.root.ts共享单测配置vitest.root.ts 是packages/与plasmicpkgs/共用的 Vitest 配置由根脚本pnpm testvitest run --config vitest.root.ts $TEST_CWD驱动。文件注释说明了两个设计决策命名为vitest.root.ts而非vitest.config.ts是因为 Vitest 会向父目录搜索配置——若在根放一个普通vitest.config.ts没有自己配置的包就会继承它去跑整个工作区配置以projects形式列出packages/、plasmicpkgs/、plasmicpkgs/commerce-providers下所有含 package.json 的目录packageDirs辅助函数动态扫描同时故意不用packages/*通配以避免把plasmicpkgs/README.md之类的非包文件误当项目。每个包仍保留自己的 vitest 设置环境、setup 文件等。knip.ts未使用依赖检查knip.ts 是 knip 的配置用来排查未使用的依赖通过根脚本knip:depsNODE_ENVtest knip --include dependencies运行。它ignoreWorkspaces了根、packages/**与plasmicpkgs/**而把检查重点放在platform/下的应用上并为platform/wab等 workspace 指定 entry/project 文件模式及ignoreDependencies白名单如coffeescript由 pegcoffee 使用、dotenv由tools/run.bash使用需显式豁免。三、关键目录一个 monorepo 的四层结构CLAUDE.md 用一句话定位了这个仓库Plasmic 是一个开源的可视化 Web 构建器并给出四个关键目录的职责划分目录内容定位platform/WAB、img-optimizer 等平台应用构成 Plasmic 平台本身packages/集成 Plasmic 的 npm 包SDK如 loader-react、loader-nextjs、hostplasmicpkgs/提供代码组件的 npm 包内置代码组件库examples/各类参考实现示例工程逐一核对仓库实际内容Platformplatform/除核心的wabPlasmic Studio 主应用含 React 客户端、主应用服务器、codegen 服务器与各种工具外还有canvas-packages、host-test、integration-tests、live-frame、loader-bundle-env、loader-html-hydrate、loader-tests、react-renderer、react-web-bundle、sub等平台支撑应用。这一层单独维护自己的package.json与pnpm-workspace.yamlplatform/package.json、platform/pnpm-workspace.yaml是仓库中体量最大的一块。SDK packagespackages/涵盖auth-api、auth-react、cli、create-plasmic-app、data-sources、host、loader-core、loader-edge、loader-fetcher、loader-gatsby、loader-nextjs、loader-react、loader-splits、nextjs-app-router、prepass、query、react-web、react-web-runtime、watcher等。其中packages/react-web提供运行时渲染内核packages/host承载registerComponent等注册 API。Plasmic packagesplasmicpkgs/提供开箱即用的代码组件如antd/antd5、chakra-ui、radix-ui、react-aria、react-chartjs-2、tiptap、contentful、framer-motion、google-maps、keen-slider、plasmic-basic-components等几十个包还包含commerce-providersShopify、Swell、Saleor、Commercetools 等电商提供商。Examplesexamples/nextjs-example、plasmic-cms-nextjs、supabase-auth-nextjs-pages-loader、react-dnd、scroll-aware-navbar等大量参考工程演示如何在真实框架中接入 Plasmic。四、技术栈与工程工具链CLAUDE.md 明确列出的技术栈如下基础设施Docker、k8s、TerraformJavaScript 工具链asdf 与 pnpm语言Node.js、TypeScript库React、MobX、TypeORM、Vitest、Playwright、Storybook。仓库中的佐证随处可见.tool-versions 声明nodejs 24.4.0、python 3.10.13、terragrunt 1.0.4正是 asdf 的版本管理文件根与 platform 两侧各有一份 pnpm-lock.yamldocker-compose.yml 定义了本地基础设施Postgres 等服务packages/下普遍配置 Vitest 与 Storybook平台侧loader-tests使用 Playwright 做端到端测试。工作区边界值得注意根 pnpm-workspace.yaml 的packages:段只收纳packages/*、plasmicpkgs/*、plasmicpkgs/commerce-providers/*与plasmicpkgs-dev并显式排除packages/loader-angular、packages/loader-svelte、packages/loader-vue、packages/plasmic这些无版本的弃用桩包而platform/是独立的一层 workspace见 platform/pnpm-workspace.yaml。该文件还通过catalog/catalogs统一依赖版本、overrides钉住冲突版本如 storybook 相关 shim 钉在 8.5.5、allowBuilds控制生命周期脚本如 esbuild/sharp 禁止构建、shamefullyHoist: true与linkWorkspacePackages: deep调整链接行为——这些都属于根目录集中治理的一部分。五、AI 助手与开发者的工作流约定CLAUDE.md 后半部分是面向 AI 助手的具体操作纪律也是日常提交代码时必须遵守的流程。沙箱检查文档开头的 Sandbox 一节提醒你可能身处一个受限沙箱环境应参考safehouse.sb沙箱配置。需要说明的是当前仓库镜像中未包含该文件docs/下仅有贡献相关文档但从根 package.json 的脚本可以看出这套约束的落地形态pnpm claude依次执行check-devcontainer要求必须在 devcontainer 中运行、check-no-fs确认无法读取~/.plasmic/secrets.json与~/.ssh/私钥、check-no-network确认无外网然后以--dangerously-skip-permissions --mcp-config.claude/.mcp.json启动 claudepnpm claude-safehouse只做check-no-fs检查用于较宽松的沙箱。也就是说CLAUDE.md 的沙箱提醒与根目录的check-*脚本共同构成一道安全门防止 AI 助手在不受控环境中接触密钥或外网。提交前的格式化与 git 钩子文档对格式化给出的约定是不要操心样式/格式——所有文件都会在 git hooks 阶段被统一格式化为同一风格该钩子由 husky 管理生成物是 gitignore 的.husky/_目录。这里隐含一个关键前提在一个全新的 worktree 中.husky/_尚不存在git 会静默跳过所有钩子。因此文档明确要求在第一次提交前先在 worktree 根目录运行pnpm install让 husky 生成钩子目录。根 package.json 中的prepare: husky正是安装阶段触发 husky 初始化的入口配合.lintstagedrc.js对暂存文件执行 eslint/prettier 修复。搜索文件时的边界文档规定搜索文件时几乎不要翻 node_modules/ 及其他被 gitignore 的文件除非有明确理由。这一点配合 .gitignore 生效既保护搜索效率也避免把依赖代码当作仓库事实。六、平台子目录的实践补充以 platform/wab 为例根 CLAUDE.md 的就近生效原则在platform/wab体现得最充分。platform/wab/CLAUDE.md 面向 WABPlasmic Studio 核心应用补充了可复制的日常命令# 在仓库根目录完成整体初始化setup 必须从根目录执行 cd ../.. pnpm setup-all # 启动完整开发环境前端 后端 host-server访问 http://localhost:3003 pnpm dev # 运行单元测试 pnpm test # 更新单元测试快照 pnpm test:update-snapshots # TypeScript 类型检查 pnpm typecheck # ESLint根目录使用 .eslintrc.js pnpm eslint-all # 构建生产前端 pnpm build此外它给出三条与根文件互补的编码约定platform/wab/CLAUDE.md写工具函数前先查src/wab/shared/common.ts——那里是共享杂货袋ensure、assert、withoutNils、maybe、only、tuple、spawn、xGroupBy等src/wab/commons/与 lodash 覆盖其余需求不要重复造轮子用ensure(x, msg)与assert(cond, msg)取代非空断言!与未检查的 cast让不变量在破坏处立即失败并给出期望信息对模型类的分派用switchType(...)而非instanceof链并以.result()收尾——这样只要新增模型类未处理类型检查就会失败而不是运行时静默穿透原生switch/if-else链则用assertNever/unreachable达到同样目的不完整或有风险的功能必须藏在 devflagsrc/wab/shared/devflags.ts后面只有部署即对所有人生效的用户可见行为变更才允许不加门控直接发布。这套约定解释了 WAB 这种数千文件规模代码库为何能长期保持可维护性共享工具集中、类型系统兜底、新功能渐进放量。七、版本管理plasmicapp 包如何保持同步CLAUDE.md 专门指出一个常见问题包版本不匹配或重复安装。关键事实与机制如下plasmicapp各包可能互相依赖且始终以精确版本exact version依赖彼此确保整组包永远同步、不会出现错配组合plasmicapp/host这类包还必须被 dedupe因为registerComponent等能力依赖全局变量与副作用多版本共存会导致用错实例同时各包类型紧密耦合npm 与 yarn 很容易让你落入版本错配/重复的陷阱应使用npm list确认唯一且 deduped 的版本问题还可能粘性残留npm/yarn 是有状态的必要时借助npm dedupe或删除重装 Plasmic 相关包含plasmicpkgs包并重置 package-lock.json/yarn.lock 来解除卡死与plasmicapp相反plasmicpkgs内置代码组件包把plasmicapp包声明为peer dependency 且用范围版本以给开发者选择核心包版本的一定灵活性。关于版本递增文档补充了两个事实精确版本不意味着每个包每次发布都升版本只有包自身或其依赖变化时才会递增递增由部署脚本运行lerna version patch --exact...自动完成该命令检测包自上次 git 打标签发布以来是否变化。从根 package.json 可以看到lerna作为 devDependency 存在lerna.json 配置了版本管理参数内部dependencies/devDependencies声明为workspace:*在 pack 时由pnpm publish替换为精确版本——这正是 pnpm-workspace.yaml 中linkWorkspacePackages: deep等设置的配套机制。八、贡献与许可速览贡献指南见 CONTRIBUTING.md平台侧更细的入门文档在 docs/contributing/platform/00-getting-started.md含配置工具链 01-config-tooling.md、集成 02-integrations.md、Figma 03-figma.md许可采用双轨制platform/之外全部内容遵循 MIT见 LICENSE.mdplatform/遵循 AGPL见 LICENSE.platform.md——CLAUDE.md 明确记录了这一点贡献代码前应据此判断自己改动的授权边界。结语根目录的 CLAUDE.md 虽然篇幅不长却是理解整个 Plasmic monorepo 的最小必要入口它划定了根目录集中治理的工程资产依赖、构建、lint、测试、依赖检查定义了platform/、packages/、plasmicpkgs/、examples/的职责边界规定了 pnpm 工作区与版本同步的底层机制并为 AI 助手和开发者提供了沙箱、格式化、文件搜索等可执行的工作流纪律。在此基础上再叠加各子目录尤其是platform/wab的局部指令你就能在这个大型仓库中快速定位代码、安全地开展开发与提交。赞分享低代码前端后端【免费下载链接】plasmicVisual builder for React. Build apps, websites, and content. Integrate with your codebase.项目地址https://gitcode.com/gh_mirrors/pl/plasmic点击查看免费下载相关推荐ClawHub 仓库开发指南读懂 CLAUDE.md 中的项目结构、构建命令与 CI 门禁ClawHub 仓库开发指南读懂 CLAUDE.md 中的项目结构、构建命令与 CI 门禁 导读 本文基于 ClawHubSkill Plugin Re后端前端AI 技能AI 插件搜索引擎Knip 源码仓库开发指南从 CLAUDE.md 读懂架构、调试、测试与性能实践Knip 源码仓库开发指南从 CLAUDE.md 读懂架构、调试、测试与性能实践 本文以 Knip 仓库根目录的 CLAUDE.md https://link代码质量静态分析CLICrawlee 仓库开发协作指南从 CLAUDE.md 读懂提交规范、构建测试与 Monorepo 架构Crawlee 仓库开发协作指南从 CLAUDE.md 读懂提交规范、构建测试与 Monorepo 架构 Crawlee 是一个面向 Node.js 的 We后端网页爬虫上一篇Jr多语言支持如何创建国际化静态网站下一篇如何在 Minecraft 服务器中快速部署 CoreProtect终极数据保护与回滚指南 ️创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考