## Split core out of framework-specific dependencies (Laravel, phpcbf), then grow postprocessors as a satellite Started as "where do future postprocessors live" — turns out core already pulls in dependencies it shouldn't, so the split needs to start there, not just with new code. ### Current state (verified against `composer.json` + actual usage) `require` today: `nette/php-generator`, `illuminate/support`, `nikic/php-parser`, `squizlabs/php_codesniffer`. Grepping who actually needs the last two: * **`illuminate/support`** is used in 4 files: * `CreateClassService\Attributes\DefinerAttribute` (core!) — `Str::replace(...)` in `parseFromLiteralClass()`, doing nothing native `str_replace()` doesn't already do. * `LaravelConventForTableUseClassNameContextPutDefaultValue`, `LaravelConventForIdsUseClassNameContextPutDefaultValue` — genuinely Laravel-flavored (table/id naming convention), belongs with Laravel. * `GenerateGetterMethods` — `Str::studly()` for method-name casing. Not Laravel-specific in spirit, just borrowed the helper. * **`squizlabs/php_codesniffer`** is used only by `PhpCbfOnStringCode`, which is core's one existing `PostprocessorInterface` implementation — meaning it already drags a whole formatter into core for everyone, exactly what the postprocessors satellite package (below) is meant to avoid for anything new. ### Proposed split 1. **`birb/fancy-stubs-codegen`** (core, deps: `nette/php-generator`, `nikic/php-parser`, `php` only) — `CreateClassService`, `ClassLikeWrapper`, `ValueObjects`, `Wrappers`, `WithContextClassAbstract`, `DefinerAttribute` (after removing its `Str::replace` call), `PostprocessorInterface` + `PostprocessorPipeline` + `DeclareStrictTypesPostprocessor` (zero-dep), `GenerateBuilderClass` + `GenerateGetterMethods` (after replacing `Str::studly` with a small local helper — property names are already camelCase/snake_case identifiers, don't need a whole framework for that). 2. **`birb/fancy-stubs-codegen-laravel`** — the two `LaravelConvent*` definers. Depends on core + `illuminate/support`. 3. **`birb/fancy-stubs-codegen-postprocessors`** — `PhpCbfOnStringCode` moves here (breaking change for anyone currently doing `use Birb\FancyStubsCodegen\Postprocessing\PhpCbfOnStringCode`), plus whatever gets picked from the candidate list below. Depends on core + `squizlabs/php_codesniffer`. ### Prerequisite refactors (small, do first, non-breaking on their own) * `DefinerAttribute::parseFromLiteralClass()`: swap `Str::replace(...)` for native `str_replace(...)`. * `GenerateGetterMethods::addGetter()`: swap `Str::studly($property->getName())` for a small local snake_case/kebab-case → StudlyCase helper. Once both land, core no longer needs `illuminate/support` at all, and the physical package split becomes mechanical. ### Candidate postprocessor implementations (for the `postprocessors` satellite, once it exists) 1. **php-cs-fixer adapter** — same shape as `PhpCbfOnStringCode`, backed by `friendsofphp/php-cs-fixer` instead of `squizlabs/php_codesniffer`, for people already standardized on it. 2. **License/file header injector** — prepend a fixed comment block if it's not already there (no dependency — could actually live in core instead, see open questions). 3. **`use`-statement sorter/deduplicator** — normalize import ordering, drop duplicates (no dependency, or a thin wrapper over an existing sorter — same "could be core" question as above). 4. **PSR-12 full-format preset** — this repo's own `PSR2.xml` is a curated subset (see `PSR2.xml` in this repo), not a full reformat. A stricter "make it look fully PSR-12" option could live here as its own ruleset + `PhpCbfOnStringCode`-alike wrapper. ### Open questions * **Breaking change window** — we're pre-1.0 (latest tag `0.2.0`), so semver allows this freely, but `PhpCbfOnStringCode` moving out of core breaks the current README + anyone who already installed it. Land as `0.3.0` with a note, or hold for `1.0.0`? * **Repo topology** — separate GitLab repos + separate Packagist entries per satellite, or one monorepo with per-package `composer.json` under e.g. `packages/laravel`, `packages/postprocessors`, and a CI job that subtree-splits each into its own read-only mirror repo for Packagist to track? Monorepo is more CI plumbing up front but a lot less overhead for a single-maintainer project than juggling N repos. * **Dependency-free postprocessors (header injector, import sorter)** — ship in core (no reason not to, they need nothing extra) or in the satellite for consistency/discoverability alongside the ones that do need extra deps? Leaning core, but flagging since it cuts against "postprocessors satellite" as a single clean concept. * **Per-implementation packages vs. one bundle** — split the satellite further (`...-postprocessors-php-cs-fixer`, `...-postprocessors-header`, ...) so installing one doesn't drag in another's dependencies? Leaning toward giving the php-cs-fixer adapter its own package from day one since `friendsofphp/php-cs-fixer` is a heavy, opinionated dependency nobody should get by accident, and bundling the rest. Not blocking anything today — flagging so the dependency creep doesn't get worse before we decide, and so the postprocessors work has a clear target to land in once it exists.