Php Scoper Laravel Package

Product Decisions This Supports

• PHAR-based distribution: Enables building self-contained PHP applications (CLI tools, libraries, or microservices) as PHARs with isolated dependencies, reducing version conflicts and improving portability.
• Vendor isolation: Critical for projects requiring strict dependency control (e.g., legacy systems, security-sensitive tools, or environments with conflicting package versions).
• Build vs. buy: Justifies in-house PHAR development over third-party SaaS/APIs when offline execution, customization, or air-gapped deployment is required.
• Use cases:
  • CLI tools (e.g., Laravel Artisan, custom scripts) distributed as single files.
  • Legacy PHP applications needing modernization without refactoring.
  • Security-hardened deployments (e.g., restricted environments where composer install is prohibited).
  • Microservices or serverless functions with minimal dependencies.

When to Consider This Package

Adopt if:

• Your project requires PHAR distribution (e.g., for portability, offline use, or reduced attack surface).
• You face namespace collisions between bundled vendors and host environments (e.g., WordPress plugins, Laravel packages).
• You need to isolate dependencies without modifying original code (e.g., for security patches or version pinning).
• Your team lacks resources to manually refactor namespaces or debug dependency conflicts.

Look elsewhere if:

• Your project doesn’t use PHARs (e.g., traditional web apps or Dockerized services).
• You rely on dynamic code generation (e.g., eval, create_function) or unsupported PHP features (see Limitations).
• Your dependencies include composer plugins or PSR-0 autoloading (partial support only).
• You prioritize development speed over isolation (e.g., rapid prototyping with shared dependencies).

How to Pitch It (Stakeholders)

For Executives: "PHP-Scoper lets us package our PHP tools as single, self-contained files (PHARs) with locked-in dependencies—eliminating version conflicts and reducing support costs. For example, we could distribute our CLI tool as a single executable (no vendor/ folder needed), improving security and deployment simplicity. This aligns with our goals of [X: cost savings/offline support/global reach] while maintaining compatibility with existing PHP ecosystems."

For Engineering: *"This tool automates namespace isolation for PHARs, solving the ‘vendor hell’ problem when bundling dependencies. Key benefits:

• No manual refactoring: Automatically prefixes all namespaces in src/ and vendor/.
• Composer integration: Works with composer dump-autoload to ensure autoloading works post-scoping.
• Debugging support: Inspect individual files or test scoped code before PHAR creation.
• Laravel/Symfony/WordPress: Pre-configured patchers handle framework-specific edge cases (e.g., service containers).

Trade-offs:

• Adds a build step (~5–10 mins for large projects).
• Requires end-to-end testing for scoped PHARs (recommended by the tool’s authors).
• Limited support for dynamic symbols (e.g., call_user_func() with strings).

Proposal:

1. Pilot: Scope a non-critical CLI tool or library as a PHAR.
2. Automate: Integrate php-scoper into CI/CD (e.g., GitHub Actions) for builds.
3. Monitor: Track PHAR size and performance impact (scoped code is ~10–20% larger)."*