refactor(deps): scope wedevs/wp-kit via Mozart - #96
Conversation
|
Warning Review limit reached
Next review available in: 46 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (13)
📝 WalkthroughWalkthroughcomposer.json adds a PHP version constraint, moves appsero/client and wedevs/wp-kit from require to require-dev, and expands the Mozart vendoring package list to include wedevs/wp-kit. Across the plugin, multiple PHP files update their ChangesVendored dependency namespace migration
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Vendor wedevs/wp-kit under the Texty\Dependencies\ namespace through Mozart, matching how Appsero is already scoped, so Texty no longer collides with another plugin that ships its own unscoped copy of wp-kit. - Add wedevs/wp-kit to extra.mozart.packages - Rewrite every `use WeDevs\WPKit\...` import to `use Texty\Dependencies\WeDevs\WPKit\...` across includes/ and texty.php - Move appsero/client and wedevs/wp-kit from require to require-dev so a production `composer install --no-dev` no longer pulls unscoped copies into vendor/; runtime resolves them from the generated dependencies/ directory
3cde152 to
3f657d2
Compare
What
Vendor wedevs/wp-kit under the
Texty\Dependencies\namespace via Mozart, matching how Appsero is already scoped.Why
Previously
wedevs/wp-kitloaded under its ownWeDevs\WPKit\namespace fromvendor/. If another active plugin ships its own (possibly different-version) copy of wp-kit under the same namespace, the two collide — whichever autoloads first wins, and the loser silently runs against the wrong class definitions. Scoping isolates Texty's copy.Changes
wedevs/wp-kittoextra.mozart.packages.use WeDevs\WPKit\...→use Texty\Dependencies\WeDevs\WPKit\...(19 imports acrossincludes/+texty.php).appsero/clientandwedevs/wp-kitfromrequire→require-dev. In a productioncomposer install --no-devmozart doesn't run, so keeping them inrequirepulled unscoped copies intovendor/alongside the scopeddependencies/output. As dev deps,--no-devno longer installs them; runtime resolves both from the generateddependencies/dir (same model Appsero already relies on).Verification
mozart composegeneratesdependencies/WeDevs/WPKit/**with the rewritten namespace;vendor/wedevs+vendor/appserodeleted.Texty\Dependencies\→dependencies/; no live unscopedWeDevs\WPKit\/Appsero\mappings.WeDevs\WPKit\...no longer resolves.composer install --no-devdry-run: neither package lands invendor/.No data/state impact
Scoping renamed only wp-kit internals. Everything Texty persists as identity stays in the untouched
Texty\namespace:texty_db_version), and registered migration classes (V_2_0_0::class, etc.) areTexty\...— unaffected.Texty\Models\SmsStatunscoped; table uses thetextyprefix, not a FQCN.BackgroundProcess(keys offmd5(static::class)) is not used by Texty.WeDevs\WPKitFQCN.Note for reviewers
dependencies/is gitignored (generated by mozart on a devcomposer install).bin/build.shcopies it into the zip, then runs--no-dev. A devcomposer installmust run before building so the scoped output exists — already the assumption for Appsero.Summary by CodeRabbit
Chores
Bug Fixes