Fractor Extension Installer Laravel Package

Technical Evaluation

Architecture Fit

• Purpose Alignment: The package is a Composer plugin designed to automate the installation of Fractor extensions, mirroring the functionality of phpstan/extension-installer. If Fractor is a PHP-based tool (e.g., a static analyzer, code quality tool, or IDE plugin), this installer aligns well with the ecosystem of similar tools (PHPStan, Psalm, etc.).
• Plugin-Based Model: Leverages Composer’s post-install/post-update scripts, making it lightweight and non-intrusive. Fits seamlessly into existing PHP/Laravel workflows where Composer is the package manager.
• Extension Discovery: Relies on composer.json metadata (type: fractor-extension + extra.fractor), which is a clean, declarative approach for extension registration.

Integration Feasibility

• Laravel Compatibility: Laravel already uses Composer for dependencies, so integrating this plugin is low-effort—just require it as a dev dependency (composer require --dev a9f/fractor-extension-installer).
• Extension Developer Requirements: Developers must adhere to the composer.json schema (type + extra keys), which is a minor friction point but standard for such plugins.
• No Core Laravel Dependencies: The package is agnostic to Laravel’s internals, reducing risk of conflicts.

Technical Risk

• Limited Adoption: With 0 stars/dependents, the package’s stability and long-term viability are unproven. Risk of abandonment or breaking changes exists.
• Composer Script Dependencies: Hard dependency on Composer scripts (--no-scripts breaks it), which may conflict with CI/CD pipelines or custom Composer setups.
• Fractor Ecosystem Maturity: If Fractor itself is immature or niche, the installer’s utility may be limited. Assess Fractor’s adoption before commitment.
• No Tests/Documentation: Lack of tests or detailed docs increases integration uncertainty. May require reverse-engineering from phpstan/extension-installer.

Key Questions

1. Why Fractor?

   • What problem does Fractor solve? How does it compare to existing tools (e.g., PHPStan, Pest, Laravel Pint)?
   • Is Fractor strategically aligned with our PHP/Laravel roadmap?

2. Adoption & Support

   • Who maintains this package? Is there a maintainer commitment (e.g., linked to Fractor’s monorepo)?
   • Are there alternatives (e.g., custom Composer scripts, Laravel service providers) that achieve the same goal?

3. Integration Depth

   • Will extensions require runtime configuration (e.g., Laravel service providers, config publishing)? If so, how will this installer handle it?
   • Does Fractor need Laravel-specific hooks (e.g., booted events, config caching)?

4. Failure Modes

   • How will failed extension installs be handled (e.g., rollback, error visibility)?
   • What happens if a dependency conflict arises between Fractor extensions and Laravel core?

5. Performance

   • Will the installer add significant overhead to composer install/update?
   • Are there memory/CPU constraints for large projects?

Integration Approach

Stack Fit

• Primary Use Case: Automating the installation of Fractor extensions in PHP/Laravel projects, similar to how phpstan/extension-installer works for PHPStan.
• Composer-Centric: Works out-of-the-box with Laravel’s Composer-based dependency management.
• Dev Dependency: Should be installed as --dev (per README), aligning with tools like PHPStan or Pest.

Migration Path

1. Pilot Phase:
   • Install the package in a non-production environment (e.g., a feature branch).
   • Test with one Fractor extension to validate installation and functionality.
2. Extension Developer Onboarding:
   • Ensure all Fractor extensions follow the composer.json schema (type: fractor-extension + extra.fractor).
   • Document the requirement for extension developers in your internal guidelines.
3. Gradual Rollout:
   • Add to project templates (if using Laravel Sail, Breeze, or custom starter kits).
   • Integrate into CI/CD pipelines (e.g., GitHub Actions) to test extension compatibility.

Compatibility

• Laravel Versions: No Laravel-specific code → backward-compatible with all Laravel 8+ versions.
• Composer Versions: Requires Composer’s script event system (supported in Composer 1.0+).
• PHP Versions: Inherits Fractor’s PHP version support (assume PHP 8.0+ based on Laravel’s LTS).
• Conflict Risks:
  • Low risk of core Laravel conflicts (plugin is isolated to Composer).
  • High risk if Fractor extensions introduce global functions, PHAR files, or runtime overrides (e.g., modifying autoload or classmap).

Sequencing

1. Pre-Integration:
   • Audit existing composer.json for conflicts (e.g., duplicate scripts).
   • Define extension whitelisting (if not all Fractor extensions should be auto-installed).
2. Installation:

   composer require --dev a9f/fractor-extension-installer
   

3. Extension Registration:
   • Update extension composer.json files to include type: fractor-extension and extra.fractor.
4. Post-Integration:
   • Test with composer install --no-scripts to confirm no silent failures.
   • Monitor Composer logs for installation errors during CI runs.

Operational Impact

Maintenance

• Low Ongoing Effort:
  • No Laravel-specific maintenance (plugin is self-contained).
  • Updates may be needed if Fractor or Composer deprecate script events.
• Dependency Management:
  • Extensions will auto-update with Composer, but may introduce breaking changes.
  • Consider pinning extension versions in composer.json for stability.

Support

• Troubleshooting:
  • Debugging may require Composer script logs (composer diagnose).
  • Limited community support (0 stars → rely on Fractor maintainers).
• Error Handling:
  • Failures (e.g., missing extra.fractor) may silently skip extensions or throw cryptic errors.
  • Recommendation: Add a post-install script to log extension installation status.

Scaling

• Performance:
  • Minimal overhead for small projects; could slow down composer install in large monorepos if many extensions are installed.
  • Mitigation: Use --prefer-dist to reduce network calls during installation.
• Extension Growth:
  • If Fractor gains traction, the installer may become a bottleneck for dependency resolution.
  • Solution: Implement a local cache for extensions or use Laravel’s config:cache.

Failure Modes

Ramp-Up

• Developer Onboarding:
  • 5–10 minutes to install and test in a new project.
  • 30+ minutes for extension developers to update composer.json.
• Training Needs:
  • Document the extra.fractor schema for internal teams.
  • Train CI/CD admins on handling Composer script failures.
• Adoption Barriers:
  • Low perceived value if Fractor’s utility isn’t clear.
  • Friction for extension developers to adopt the schema.
• Success Metrics:
  • % of projects using the installer.
  • Reduction in manual extension setup steps.
  • Extension compatibility rate (e.g., 90% of Fractor extensions work without issues).