Skosh Laravel Package

Getting Started

• Treat 0.3.0 as a maintenance release with one breaking change: the Twitter plugin is removed. If your app uses that plugin, plan a replacement before upgrading.
• Confirm compatibility first: this release requires PHP 7.2+. Check your app’s PHP version and CI matrix before running composer update.
• Look first at the package README, CHANGELOG, composer.json, service provider, and any plugin/driver registration docs. The release notes indicate plugin architecture is relevant, so identify how plugins are registered in your app.
• Minimal upgrade path:
  1. Search the codebase and config for Twitter, Twitter-related provider entries, credentials, and queued jobs.
  2. Remove or replace Twitter plugin usage.
  3. Update the package constraint to ^0.3.
  4. Clear caches: php artisan config:clear, php artisan cache:clear, and re-run php artisan vendor:publish only if config changed.
  5. Run the app’s feature tests around the package’s main workflow.
• First use case: wire the package into a small controller/job through Laravel’s container, configure the supported driver/plugin, and assert the result in a feature test. If the original use case was Twitter-based, build a thin adapter around a supported provider before rolling out.

Implementation Patterns

• Keep package configuration centralized: publish config once, keep credentials in .env, and avoid scattering plugin/driver names across controllers.
• Resolve the package through dependency injection or a small application service rather than calling facades directly in domain code. This makes the Twitter removal and future provider changes easier to isolate.
• If the package still supports custom plugins/drivers, register them in a dedicated service provider and wrap third-party integrations behind an application-level interface.
• For upgrade work, use a branch and a short-lived compatibility layer:
  • Keep existing call sites stable.
  • Replace Twitter-specific code with a supported implementation.
  • Remove the compatibility layer after deployment.
• Queue outbound calls where possible. External provider calls are the most likely source of latency and failure; queueing also makes retries and failure handling easier.
• In tests, fake HTTP calls with Laravel’s HTTP client fakes where applicable, and assert that removed Twitter code paths are no longer referenced.
• Add a CI job for the minimum supported PHP version, 7.2, especially if the rest of the team develops on newer PHP versions.

Gotchas and Tips

• Breaking change: the Twitter plugin is gone. Search for Twitter plugin classes, service provider registrations, config keys, env vars, database columns, and queued jobs that may still reference it.
• Drain or migrate queued jobs that serialized Twitter plugin objects before deploying. Otherwise workers may fail with class-not-found or serialization errors after the upgrade.
• Run composer why-not <vendor/package> 0.3.0 if the update is blocked; PHP 7.2+ and Laravel version constraints are the first things to check.
• “Coding standards” and “code cleanup” usually mean no intended behavior change, but review the diff for renamed internals, changed exception types, or altered config defaults.
• Clear cached config after upgrading or publishing config. A stale bootstrap/cache/config.php can make it look like the Twitter plugin is still registered.
• Avoid editing vendor files to restore Twitter support. Use the package’s supported extension point if one exists; otherwise keep the replacement in app code behind an adapter.
• Debug with php artisan about, composer show, package logs, and a minimal artisan tinker/feature test. Confirm the resolved package version before investigating application code.