Eloquent Zf2 Laravel Package

Getting Started

This release is a maintenance-rescue publication, not a feature release. The headline is provenance: the original upstream repository was deleted, and the package is now published under new stewardship (heysolucoes.com) at version 1.0.0. Nothing in the notes indicates an API change, so treat your first task as verifying what you're about to install rather than learning new behaviour.

Start here, in order:

1. Confirm the Composer identity. Check composer.json for the name, license, authors, and homepage fields on the new release. If the vendor prefix changed (e.g. oldvendor/pkg → heysolucoes/pkg), this is a different package to Composer even if the source is identical — you cannot upgrade in place, you must composer remove then composer require.
2. Diff the code against your installed version. You likely still have the old version in vendor/ or in composer.lock. Clone the new repo and diff, or compare against a tagged archive from Packagist's dist cache. You want a near-empty diff for the first release; anything else needs justification.
3. Read the README in the repo, not the release note. The release note is a press statement. Setup instructions, supported Laravel/PHP versions, and config-publishing commands live in the README.
4. First use case: install it, run your existing test suite, and confirm nothing regressed. Because this is a 1.0.0 tag on a pre-existing codebase, the number tells you nothing about stability — your own tests are the only meaningful signal.

If you are starting fresh rather than migrating, run a short spike: install, publish any config (php artisan vendor:publish --provider="..."), wire up the single most common operation the package offers, and only then commit to it.

Implementation Patterns

Pin and verify before rolling out. Adopt the new source in one project first:

composer require heysolucoes/<package>:^1.0 --with-all-dependencies

Then commit composer.lock and diff it. The lockfile is your audit trail — it records the exact dist reference (commit SHA) you're now shipping. Review that SHA against the repo before merging.

Use a Composer repository entry during transition. If the package name stayed the same but the canonical source moved, point Composer at the new VCS location explicitly rather than relying on Packagist metadata that may still reference the dead repo:

{
  "repositories": [
    { "type": "vcs", "url": "https://github.com/heysolucoes/<package>" }
  ]
}

This also lets you composer require heysolucoes/<package>:dev-main to smoke-test fixes upstream before they're tagged.

Fork-and-vendor as the contingency. Given the original repo was taken down once, plan for it happening again. Two viable patterns:

• Internal mirror: keep a read-only fork in your own org, add it as a vcs repository, and require from there. You get reproducibility independent of the maintainer.
• replace directive: if the package is small and you've vendored the source into your app, declare "replace": { "heysolucoes/<package>": "*" } so transitive dependents resolve to your copy.

CI matrix pinning. Because the package has changed hands, don't assume the previously supported Laravel versions still apply. Add the new constraint to your CI matrix explicitly — test on the Laravel versions you actually deploy, plus the minimum the README claims.

Watch the dependency graph. Run composer why <package> across your projects. A package that "hurt some developers" when it vanished is probably a transitive dependency in more places than you think — the ones you didn't require directly are the ones that will surprise you.

Gotchas and Tips

• 1.0.0 here is a re-release, not a milestone. Semver is a promise about compatibility relative to the previous tag, and this tag has no meaningful predecessor in the new lineage. Don't read stability into the number, and don't let a ^1.0 constraint auto-adopt future 1.x tags until the maintainer has a track record.
• Package takeover is a supply-chain event. Reclaimed namespaces are a known attack vector: an abandoned or deleted package name can be re-registered by anyone. Verify the new maintainer is who the release note claims (heysolucoes.com resolving to a real entity, a public repo with history, a named author in composer.json) before the first composer update in production. Compare the code to your old vendor/ copy — byte-for-byte on the PHP files, minus formatting.
• Lost institutional knowledge. Issues, PRs, and wiki content from the original repo are gone with it. Any workaround you previously found in a GitHub issue thread is now unrecoverable — capture the ones you rely on into your own project notes or a comment in the integration code.
• License re-verification. Confirm the license field survived the move and is compatible with your usage. A fork that silently drops or changes the license is a legal problem, not a technical one.
• Debugging regressions: if behaviour differs post-migration, first check whether a config file was published by the old version and is shadowing the new defaults (config/<package>.php in your app). Stale published config is the most common cause of "the upgrade broke it" in Laravel packages and it looks exactly like a code regression.
• Extension points to prefer: if the package exposes events, macros, or a bindable contract, hook there rather than editing vendor/. A fork you've patched locally is a fork you must re-patch on every release — and this maintainer has already demonstrated that the upstream can disappear.
• Set an evaluation checkpoint. Give the new stewardship one or two release cycles. If there's no changelog, no test suite in the repo, or no response to issues by then, treat the package as effectively unmaintained and execute the mirror/vendor contingency above.

Bottom line: the release itself changes nothing about how you use the package day-to-day; it changes how much you should trust it. Verify the code matches what you had, pin the exact reference, mirror it internally, and defer any broad rollout until the new maintainer has shipped something with a real changelog.