Laralink Laravel Package

Technical Evaluation

Architecture fit. amjadiqbal/laralink is a developer-tooling package, not a runtime dependency. It ships three Artisan commands (laralink:dev, laralink:list, laralink:publish) that automate the manual loop of "clone package → add Composer path repository → require it → later restore the released constraint." That loop is otherwise done by hand and inconsistently across a team, so the package occupies a legitimate gap in the Laravel local-development workflow. Its blast radius is confined to the root composer.json/composer.lock, vendor/, and a ./packages/ working directory — never application request paths. It should therefore be treated as a require-dev, per-developer tool, not a shared application dependency.

Integration feasibility. Straightforward in principle: composer require --dev, publish nothing (the laralink-config tag is gone and no config file exists), run one command. Feasibility is constrained by two hard gates: PHP 8.3+ and Laravel 12 or 13. Any app on Laravel 10/11 or PHP 8.1/8.2 cannot use this at all. The claimed Laravel 13 support is worth verifying against release timing — supporting an unreleased major usually means a widened constraint rather than tested compatibility.

Technical risk. Moderate, and concentrated in three places:

1. composer.json mutation precedence. The release adds the path repository first so it wins over other repositories. That is the correct behavior for the tool's purpose, but it silently changes resolution order for a root manifest that may also carry private VCS/Composer registries. A broadened repository order is a global change to how every package resolves while the link is active.
2. Failure rollback is new, not proven. The 1.x line had no rollback on Composer failure and its documented flags did not exist — the README described an API the code never shipped. That is a documentation-integrity failure, and it is the strongest available signal about the project's test maturity. The PSR-4 case mismatch (Amjadiqbal vs AmjadIqbal) is a second such signal: it is a class-loading defect that would fail immediately on any case-sensitive filesystem, which implies CI either did not exist or did not load the commands. v2.0.0's rollback, --backup, and delete-safety work is exactly the right fix set — but it should be presumed unverified until we see the pipeline.
3. Executing cloned code. laralink:dev --source= accepts arbitrary https://, git@, ssh://, and file:// URLs, and the tool then runs Composer against the result. That is a supply-chain surface: Composer scripts and plugins from the cloned package execute on install. The interactive mode additionally auto-discovers candidates by scanning ../*, ../*/*, and ~/projects, which is convenient but can offer folders a developer did not intend to link.

Key questions.

• Is there a CI matrix across PHP 8.3/8.4 and Laravel 12/13, on both Linux and macOS, and does it actually load the Artisan commands?
• Is the package on Packagist under a stable name, and does the 2.0.0 tag match the released notes?
• What is the maintenance model — single maintainer or team? Any tagged release cadence or security policy?
• Does it work on Windows (symlink creation typically needs Developer Mode or elevation), and is --copy the documented fallback?
• Minimum Composer version required for composer reinstall and path-repository behavior?
• Should ./packages/.laralink.json be committed or gitignored, and what is the recovery path if it is lost — does constraint restoration degrade to "latest release"?
• Is laralink:list --json a stable contract we can script against, or an implementation detail?
• Can --source be constrained to an allowlist or resolved relative to the app to reduce clone-from-anywhere risk?

Integration Approach

Stack fit. Only viable for greenfield or actively-upgraded Laravel estates already on PHP 8.3+ and Laravel 12/13. For anything older, this package is out of scope until the framework upgrade lands — do not attempt to backport or pin 1.x, since 1.x was never on Packagist and its documented interface did not work.

Migration path. There is no migration from 1.x worth planning: 1.x was never distributable and its flags were fictional. Treat v2.0.0 as a first adoption, not an upgrade. The only 1.x carryover is behavioral expectations in old READMEs and internal notes — audit and delete any team documentation referencing --symlink or the laralink-config publish tag, both removed.

Compatibility. Adopt --copy as the documented fallback wherever symlinks are unreliable (Windows, some container bind-mount setups, CI scratch dirs). Note that composer.json no longer carries a hard-coded version or minimum-stability: dev — good hygiene, but it also means we must resolve through the path repository and the app's own stability flags, which is the intended behavior and worth confirming in a scratch app.

Sequencing.

1. Validate in a throwaway app on the target PHP/Laravel versions: link a folder source, a Git URL, and a tag via --branch=; verify rollback by inducing a Composer failure and confirming composer.json is restored and the link/clone removed.
2. Verify the destructive paths explicitly — laralink:publish --delete on a symlink (must remove only the link), and on a clone with uncommitted changes (must refuse without --backup or --force). These are the highest-consequence operations in the tool.
3. Establish a commit policy before rollout. Decide whether a locally-linked composer.json may ever be committed. Recommended: no. Require ./packages/ and .laralink.json in .gitignore, and add a CI check that fails if a path repository pointing at ./packages appears in a committed manifest.
4. Pilot with one team and one package, using laralink:list --json to confirm status reporting matches reality (linked, local files not linked, linked but not required, remote).
5. Document and roll out with the constraint-restoration behavior called out, since laralink:publish now returns the package to its prior constraint rather than a bare composer require.

Operational Impact

Maintenance. Minimal carrying cost — a dev-only dependency with a small command surface and no runtime presence. The real maintenance burden is the ./packages/ working directory and .laralink.json, which are per-machine state that can drift, go stale, or be lost. Budget a small amount of hygiene: periodic laralink:list review and a documented "unlink before you ship" step.

Support. Support risk is the main concern, and it is about the project rather than the code. A release that documents flags it never implemented, ships a PSR-4 case mismatch, and has a hard-coded version field suggests a small or solo maintenance effort. Pin to an exact version, vendor-review the diff before bumping, and be prepared to fall back to the manual path-repository workflow — which is trivial and requires no package at all. That fallback is our real insurance and should be written down.

Scaling. Scales fine across a team because state is local and commands are per-developer. It does not belong in CI or shared build images: cloning arbitrary Git sources and mutating composer.json/vendor/ inside a build is both slow and non-deterministic. The composer reinstall step on forced re-link is I/O-heavy; expect a noticeable pause on large vendor trees. Monorepos with many local packages are the stress case — interactive discovery across ../*, ../*/*, and ~/projects is helpful there, but also the point at which a large number of path repositories can be injected into one manifest.

Failure modes. Materially improved in 2.0.0, and this is the release's core value:

• Composer failure during laralink:dev → composer.json restored, link/clone removed. Was previously unrecoverable without manual cleanup.
• Composer failure during laralink:publish → composer.json restored, package left linked (deliberately non-destructive).
• --delete on a symlink → removes the link only; source folder untouched.
• --delete on a clone with uncommitted changes → refused without --backup or --force.
• Forced re-link to a different folder → vendor/ re-pointed via composer reinstall, fixing a stale-symlink class of bug.

Residual failure modes to watch: lost or stale .laralink.json (constraint restoration degrades to "latest release"), repository-order side effects on unrelated packages, Windows symlink permissions, and network/auth failures mid-clone with SSH remotes.

Ramp-up. Low — under an hour for a developer who already understands Composer path repositories, which is the prerequisite. The commands are self-describing, --json supports scripting, and php artisan about now surfaces the installed version and a support link, which helps triage. The cost is conceptual rather than technical: the team must internalize that linking is a local, reversible state and that publish is the deliberate exit from it.