package-management_skill

This skill streamlines managing forked Laravel/Nova packages with submodules and VCS path repos, boosting CI compatibility and predictable updates.

TypeScript

1

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill hackur/web-standards-playground-showcase --skill package-management

SKILL.md8.2 KB

Overview

This skill describes a workflow for managing forked pcrcard/* packages using git submodules plus Composer path repositories. It documents setup, update, CI/CD integration, and common pitfalls so teams can modify forked Laravel/Nova packages reliably. The focus is on reproducible development, vendor symlinks, and CI-friendly package handling.

How this skill works

Packages live as git submodules under packages/ and Composer is configured with path repositories that symlink vendor/pcrcard/* to packages/*. CI pipelines initialize submodules before builds, allowing Composer to install from local paths. Developers edit code in packages/, commit submodule updates in the main repo, and use helper scripts to list, clone, and update forked packages.

When to use it

Working with forked pcrcard/nova-* packages
Adding or updating custom package forks in a monorepo
Making local modifications that must persist across installs
Preparing CI/CD pipelines that need package source present
Troubleshooting missing vendor packages or broken symlinks

Best practices

Always run git submodule update --init --recursive after pulling main branch
Edit source in packages/, not vendor/, because vendor is a symlink
Use @dev constraint for Composer path repositories to avoid version conflicts
Stage and commit submodule changes from the main repo after pulling or updating the submodule
Include git submodule initialization in CI before composer install

Example use cases

Add a new forked package: git submodule add, update composer.json repositories, require pcrcard/<package> @dev, composer update
Update an existing fork: cd packages/<pkg>; git pull origin main; cd ../..; git add packages/<pkg>; git commit -m "Update <pkg>"
CI build: before_script runs git submodule update --init --recursive so composer installs local path packages
Debug missing package: pull main, run git submodule update --init --recursive, then ./vendor/bin/sail composer install
Create feature changes in a fork: implement and test in packages/<pkg>, commit in that package repo, then update the tracked commit in the main repo

FAQ

Path repositories usually reference working copies. Using @dev prevents Composer from requiring a release-tagged constraint and ensures Composer accepts the local path version.

What if a submodule is on detached HEAD?

Enter packages/<pkg>, git checkout main (or desired branch), git pull origin main, then from the main repo git add packages/<pkg> and commit the submodule update.