Forked Package Management

Git submodules let you version-control forked packages in a packages/ directory while Composer manages dependencies via VCS path repositories. Initialize submodules with `git submodule update --init --recursive`, then use local path-based Composer repositories to symlink forked packages into vendor, keeping forks and dependencies synchronized across your project.

Yes. Path-based Composer repositories create symlinks from vendor to your local forked packages, enabling instant code changes without reinstalling. This workflow supports both development iteration and testing before committing changes to your fork.

Configure your CI/CD pipeline to run `git submodule update --init --recursive` during build initialization, ensuring forked packages are cloned and checked out at the correct commit. This guarantees consistent dependency resolution and vendor symlinks across all environments.

Use Git submodules to centralize fork versions in your packages/ directory. Update the submodule pointer, commit the change, and pull across projects. Composer's path repositories automatically reflect updates without reinstalling, streamlining multi-project fork management.

Symlinks preserve the single source of truth in packages/, reducing duplication and sync errors. Code changes propagate instantly across your project without manual copying, and Composer respects the symlink structure during reinstalls and CI builds.

Verify symlinks exist and resolve correctly with `ls -la vendor/`, ensure Composer's path repository configuration points to your packages/ directory, and confirm submodule commits match your project's expectations. Broken symlinks typically stem from incomplete submodule initialization or misconfigured path repositories.