给 Bagisto 提交代码前漏掉这 3 步CI 大概率红【免费下载链接】bagistoOpen Source eCommerce Multi-Vendor Marketplace Platform Built with Laravel for Enterprise-Scale Commerce, Supporting 10M SKUs项目地址: https://gitcode.com/gh_mirrors/ba/bagisto给 Bagisto 提交代码翻车几乎都发生在评审开始之前你照着 issue 写了两天的功能第二天打开仓库发现另一个人已经在同一个 issue 下留言并被指派你的 Pull Request 成了第二份整晚白干或者你信心满满提了 PRCI 却在你从没跑过的翻译检查上亮红——一个 key 只写进了 en剩下 22 个语言包全部缺位。下面这套流程就是帮你在本地提前拦住这些坑。一张表看清改什么、提哪里、跑什么Bagisto 当前有两条活跃分支2.4是正在维护的发布线master是下一条发布线。更早的1.x、2.1到2.3一律不再接收新改动别再往那里提了。提哪条、跑哪些检查照这张表走就行改动类型目标分支必跑检查修 bug受影响的那条发布线通常是2.4pint --testpest向后兼容的小改进同一条发布线同上动了文案再加翻译检查新特性、破坏性变更master全部三项检查规则只有一条从哪条线切分支PR 就提回哪条线别跨线混提。认领、对齐、切分支动手前的三件事⚠️ 1.先在 issue 下留言认领。一句简短的我想接这个就够了然后等被 assign。很多人会同时看上同一个 issue重复劳动往往要等第二份 PR 到达才被发现——认领这一步就是替别人省一个晚上。已被认领但很久没动静的回原帖问进展别开竞争性 PR。方向先在 issue 里对齐。新功能尤其如此先讨论方案最好能给出一个展示解决思路形态的最小实现别抛一个空想法。带着惊喜到达的 PR被拒的概率远高于方向明确但实现粗糙的 PR——拒绝理由通常是方向而不是代码质量。从目标分支切出工作分支命名跟 issue 走比如issue-1234。仓库里没有development分支也别找。写代码时随手对照一半交给工具一半靠人眼机器能查的和人眼要核的放在脑子里分成两组。机器能查的Pint 两个命令差在哪代码风格由 Laravel Pint 管pint.json 里就一行预设{preset: laravel}。开 PR 前跑一次检查命令它会只报告、不改写文件返回非零退出码就说明有风格问题CI 执行的正是这一条vendor/bin/pint # 自动修复直接改写文件 vendor/bin/pint --test # 只检查不修改CI 同款本地先用不带--test的那条把文件修干净再用--test确认一遍。另外注意 Pint 不管.blade.phpBlade 模板的格式只能手工把握——这里有个坑你改到的 Blade 文件里即使有历史风格问题评审时也会算在你头上。人眼要核的评审者会逐条过目的规则这几条没有任何工具帮你兜底每条对应一句为什么每个方法、属性、常量都带 docblock不管 public 还是 private——评审靠注释定位意图类成员按固定顺序常量 → 属性 → 构造函数 → public → protected → private——扫读结构时不用跳方法体内禁止注释PHP、Blade、JS、Vue 一视同仁——需要解释的代码抽一个命名方法让名字自解释数据库访问一律走 repository唯一例外是 DataGrid 的prepareQueryBuilder()——各包的Repositories/目录就是这条规则的落点比如 packages/Webkul/Core/src/Repositories所有面向用户的字符串必须走trans()且 key 要同步进全部 23 个语言目录en 加另外 22 个缺一个 CI 就红。PHPDoc 还有个小格式容易被挑param与类型之间、类型与变量名之间各留两个空格——param string|array $loader。原则是类型信息能写进函数签名就写签名param/return只补充原生类型说不出的东西比如数组的形状。编译产物别提交在包目录里构建Bagisto 的前端源码和构建产物有明确分界源码放在各包的src/Resources/assets/下产物输出到public/themes/*/*/build/。编译后的 bundle 又大又没法评审还是夹带恶意代码的现成通道所以由维护者统一生成提交你不该碰它。⚠️ 构建必须进你改动的包里执行从仓库根目录跑是无效的——Admin、Shop、Installer 各自维护独立的package.json与 vite.config.js。以 Admin 为例前端源码就分css/、js/、locales/等子目录构建完是这样一套完整主题这一步只在前端有变更时才需要跑cd packages/Webkul/Admin npm install npm run build # 换成 Shop 或 Installer 同理从本地到 CI提 PR 前的三级检查流第一级本地三条命令拦住 90% 的红灯第一条防风格检查打脸第二条防你机器上好的第三条防翻译漏项。动了任何trans()的 key 就必须跑第三条它以 en 为基准逐语言比对文件夹、文件、key 和结构vendor/bin/pint --test # 风格CI 同款命令 vendor/bin/pest # 单元与功能测试Pest 是主测试栈 php artisan bagisto:translations:check # 23 个语言包一致性最后一条的实现在 packages/Webkul/Core/src/Console/Commands/TranslationsChecker.php支持--locale、--package收窄范围--details给出带行号的 key 差异退出码非零即代表没同步好。第二级包内跑 Playwright拦住 UI 流程问题单元测不到的东西——页面跳转、表单提交——靠端到端测试兜底。它按包运行进包目录执行cd packages/Webkul/Admin npx playwright test --configtests/e2e-pw/playwright.config.tsplaywright.config.ts 里是串行执行workers: 1、60 秒用例超时失败时自动留存整页截图、视频和 tracebaseURL取自.env的APP_URL——也就是说你得先有一个能访问的本地 Bagisto 实例。第三级CI 标签触发按需跑浏览器测试CI 里 Playwright 不默认全量跑太贵。PR 打上Need Playwright Testing标签后才会触发标签在之后每次 push 都会再跑一遍。本地能跑包内 E2E 就先跑跑不动也别裸奔至少在 PR 描述里把跑了哪些检查、跳过了哪些、为什么如实写清——评审者靠这段话决定从哪看起。最容易翻车的五个细节❌ 把public/themes/*/build/里的编译产物一起提交 ✅ 只提交src/Resources/assets/下的源码产物留给维护者生成❌ 新文案只写进了 en 语言包觉得英文是母版就行 ✅ key 同步进全部 23 个语言目录本地先跑bagisto:translations:check验证❌ 在仓库根目录直接npm run build✅cd packages/Webkul/包名再构建各包各自维护构建配置❌ 只跑了vendor/bin/pest就提 PR风格问题留给 CI 发现 ✅ 先vendor/bin/pint修文件再vendor/bin/pint --test确认和 CI 对齐❌ PHPDoc 随手写param string $loader✅ 类型两侧各留两空格param string $loader类型优先写进函数签名把整条动线压成一屏一句话版本认领 issue 等指派 → 按改动类型从对应发布线切分支 → 前端改动在包内构建、不提交产物 → 提交前过 Pint、Pest 和翻译检查 → 必要时跑包内 Playwright 并贴好 CI 标签 → PR 描述如实交代检查范围。 直接复制收藏# 0. issue 下留言认领等 assign新功能先对齐方案 # 1. 从目标分支切工作分支bug 修复/小改进 → 2.4新特性 → master git checkout 2.4 git checkout -b issue-1234 # 2. 前端有改动时进包构建跳过产物提交 cd packages/Webkul/Admin npm install npm run build # 3. 本地三项验证 vendor/bin/pint --test vendor/bin/pest php artisan bagisto:translations:check # 改过 trans() key 才需要 # 4. 涉及 UI 流程包内跑端到端 cd packages/Webkul/Admin npx playwright test --configtests/e2e-pw/playwright.config.ts # 5. 给 PR 打 Need Playwright Testing 标签描述里写清跑过/跳过的检查【免费下载链接】bagistoOpen Source eCommerce Multi-Vendor Marketplace Platform Built with Laravel for Enterprise-Scale Commerce, Supporting 10M SKUs项目地址: https://gitcode.com/gh_mirrors/ba/bagisto创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
给 Bagisto 提交代码前漏掉这 3 步CI 大概率红【免费下载链接】bagistoOpen Source eCommerce Multi-Vendor Marketplace Platform Built with Laravel for Enterprise-Scale Commerce, Supporting 10M SKUs项目地址: https://gitcode.com/gh_mirrors/ba/bagisto给 Bagisto 提交代码翻车几乎都发生在评审开始之前你照着 issue 写了两天的功能第二天打开仓库发现另一个人已经在同一个 issue 下留言并被指派你的 Pull Request 成了第二份整晚白干或者你信心满满提了 PRCI 却在你从没跑过的翻译检查上亮红——一个 key 只写进了 en剩下 22 个语言包全部缺位。下面这套流程就是帮你在本地提前拦住这些坑。一张表看清改什么、提哪里、跑什么Bagisto 当前有两条活跃分支2.4是正在维护的发布线master是下一条发布线。更早的1.x、2.1到2.3一律不再接收新改动别再往那里提了。提哪条、跑哪些检查照这张表走就行改动类型目标分支必跑检查修 bug受影响的那条发布线通常是2.4pint --testpest向后兼容的小改进同一条发布线同上动了文案再加翻译检查新特性、破坏性变更master全部三项检查规则只有一条从哪条线切分支PR 就提回哪条线别跨线混提。认领、对齐、切分支动手前的三件事⚠️ 1.先在 issue 下留言认领。一句简短的我想接这个就够了然后等被 assign。很多人会同时看上同一个 issue重复劳动往往要等第二份 PR 到达才被发现——认领这一步就是替别人省一个晚上。已被认领但很久没动静的回原帖问进展别开竞争性 PR。方向先在 issue 里对齐。新功能尤其如此先讨论方案最好能给出一个展示解决思路形态的最小实现别抛一个空想法。带着惊喜到达的 PR被拒的概率远高于方向明确但实现粗糙的 PR——拒绝理由通常是方向而不是代码质量。从目标分支切出工作分支命名跟 issue 走比如issue-1234。仓库里没有development分支也别找。写代码时随手对照一半交给工具一半靠人眼机器能查的和人眼要核的放在脑子里分成两组。机器能查的Pint 两个命令差在哪代码风格由 Laravel Pint 管pint.json 里就一行预设{preset: laravel}。开 PR 前跑一次检查命令它会只报告、不改写文件返回非零退出码就说明有风格问题CI 执行的正是这一条vendor/bin/pint # 自动修复直接改写文件 vendor/bin/pint --test # 只检查不修改CI 同款本地先用不带--test的那条把文件修干净再用--test确认一遍。另外注意 Pint 不管.blade.phpBlade 模板的格式只能手工把握——这里有个坑你改到的 Blade 文件里即使有历史风格问题评审时也会算在你头上。人眼要核的评审者会逐条过目的规则这几条没有任何工具帮你兜底每条对应一句为什么每个方法、属性、常量都带 docblock不管 public 还是 private——评审靠注释定位意图类成员按固定顺序常量 → 属性 → 构造函数 → public → protected → private——扫读结构时不用跳方法体内禁止注释PHP、Blade、JS、Vue 一视同仁——需要解释的代码抽一个命名方法让名字自解释数据库访问一律走 repository唯一例外是 DataGrid 的prepareQueryBuilder()——各包的Repositories/目录就是这条规则的落点比如 packages/Webkul/Core/src/Repositories所有面向用户的字符串必须走trans()且 key 要同步进全部 23 个语言目录en 加另外 22 个缺一个 CI 就红。PHPDoc 还有个小格式容易被挑param与类型之间、类型与变量名之间各留两个空格——param string|array $loader。原则是类型信息能写进函数签名就写签名param/return只补充原生类型说不出的东西比如数组的形状。编译产物别提交在包目录里构建Bagisto 的前端源码和构建产物有明确分界源码放在各包的src/Resources/assets/下产物输出到public/themes/*/*/build/。编译后的 bundle 又大又没法评审还是夹带恶意代码的现成通道所以由维护者统一生成提交你不该碰它。⚠️ 构建必须进你改动的包里执行从仓库根目录跑是无效的——Admin、Shop、Installer 各自维护独立的package.json与 vite.config.js。以 Admin 为例前端源码就分css/、js/、locales/等子目录构建完是这样一套完整主题这一步只在前端有变更时才需要跑cd packages/Webkul/Admin npm install npm run build # 换成 Shop 或 Installer 同理从本地到 CI提 PR 前的三级检查流第一级本地三条命令拦住 90% 的红灯第一条防风格检查打脸第二条防你机器上好的第三条防翻译漏项。动了任何trans()的 key 就必须跑第三条它以 en 为基准逐语言比对文件夹、文件、key 和结构vendor/bin/pint --test # 风格CI 同款命令 vendor/bin/pest # 单元与功能测试Pest 是主测试栈 php artisan bagisto:translations:check # 23 个语言包一致性最后一条的实现在 packages/Webkul/Core/src/Console/Commands/TranslationsChecker.php支持--locale、--package收窄范围--details给出带行号的 key 差异退出码非零即代表没同步好。第二级包内跑 Playwright拦住 UI 流程问题单元测不到的东西——页面跳转、表单提交——靠端到端测试兜底。它按包运行进包目录执行cd packages/Webkul/Admin npx playwright test --configtests/e2e-pw/playwright.config.tsplaywright.config.ts 里是串行执行workers: 1、60 秒用例超时失败时自动留存整页截图、视频和 tracebaseURL取自.env的APP_URL——也就是说你得先有一个能访问的本地 Bagisto 实例。第三级CI 标签触发按需跑浏览器测试CI 里 Playwright 不默认全量跑太贵。PR 打上Need Playwright Testing标签后才会触发标签在之后每次 push 都会再跑一遍。本地能跑包内 E2E 就先跑跑不动也别裸奔至少在 PR 描述里把跑了哪些检查、跳过了哪些、为什么如实写清——评审者靠这段话决定从哪看起。最容易翻车的五个细节❌ 把public/themes/*/build/里的编译产物一起提交 ✅ 只提交src/Resources/assets/下的源码产物留给维护者生成❌ 新文案只写进了 en 语言包觉得英文是母版就行 ✅ key 同步进全部 23 个语言目录本地先跑bagisto:translations:check验证❌ 在仓库根目录直接npm run build✅cd packages/Webkul/包名再构建各包各自维护构建配置❌ 只跑了vendor/bin/pest就提 PR风格问题留给 CI 发现 ✅ 先vendor/bin/pint修文件再vendor/bin/pint --test确认和 CI 对齐❌ PHPDoc 随手写param string $loader✅ 类型两侧各留两空格param string $loader类型优先写进函数签名把整条动线压成一屏一句话版本认领 issue 等指派 → 按改动类型从对应发布线切分支 → 前端改动在包内构建、不提交产物 → 提交前过 Pint、Pest 和翻译检查 → 必要时跑包内 Playwright 并贴好 CI 标签 → PR 描述如实交代检查范围。 直接复制收藏# 0. issue 下留言认领等 assign新功能先对齐方案 # 1. 从目标分支切工作分支bug 修复/小改进 → 2.4新特性 → master git checkout 2.4 git checkout -b issue-1234 # 2. 前端有改动时进包构建跳过产物提交 cd packages/Webkul/Admin npm install npm run build # 3. 本地三项验证 vendor/bin/pint --test vendor/bin/pest php artisan bagisto:translations:check # 改过 trans() key 才需要 # 4. 涉及 UI 流程包内跑端到端 cd packages/Webkul/Admin npx playwright test --configtests/e2e-pw/playwright.config.ts # 5. 给 PR 打 Need Playwright Testing 标签描述里写清跑过/跳过的检查【免费下载链接】bagistoOpen Source eCommerce Multi-Vendor Marketplace Platform Built with Laravel for Enterprise-Scale Commerce, Supporting 10M SKUs项目地址: https://gitcode.com/gh_mirrors/ba/bagisto创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
