Common Laravel Package

Product Decisions This Supports

• Build vs. buy/share: Treat eclipsephp/common as an internal platform library rather than a market dependency. The relevant decision is not “should we adopt this public package?” but “should our Eclipse PHP/Filament plugin suite standardize on a shared foundation layer?”
• Roadmap sequencing: If multiple Eclipse plugins need the same Foundation classes, base implementations, or Filament conventions, investing in this common package early can prevent duplicated effort across plugin roadmaps.
• Feature reuse: Supports decisions to extract repeated plugin functionality into shared primitives instead of reimplementing common behavior in each Eclipse package.
• Ecosystem coherence: Enables a consistent technical baseline across Eclipse PHP packages, which helps with onboarding, support, and long-term maintainability.
• Use cases: Internal admin/plugin suites built on Filament, shared domain or foundation classes, common implementation patterns, and packages that explicitly depend on the Eclipse PHP plugin family.
• Dependency strategy: Because every Eclipse PHP package depends on this package, changes here are effectively platform changes. PM should treat versioning, backward compatibility, and release coordination as product risks, not just engineering details.

When to Consider This Package

Consider it when:

• You are building or maintaining an internal suite of Eclipse PHP/Filament plugins.
• Multiple packages need the same Foundation or common implementation classes.
• Your team already owns the Eclipse PHP package ecosystem or plans to.
• You value internal consistency and reduced duplication more than public ecosystem adoption, community support, or external documentation.
• You can accept the maintenance burden of an internal shared dependency, including version pinning, backward compatibility, and cross-package release coordination.

Look elsewhere when:

• You are building a general-purpose Laravel application or a standalone product outside the Eclipse PHP/Filament ecosystem.
• You need a mature public package with strong community adoption, documentation, issue support, and broad real-world validation.
• You cannot commit to maintaining an internal foundation package or coordinating changes across dependent plugins.
• The package’s “non-opinionated” positioning conflicts with your need for clear, stable, documented platform contracts.
• The cost of hidden coupling across all Eclipse packages outweighs the benefit of shared code.

How to Pitch It (Stakeholders)

For executives: This is not a strategic bet on a popular open-source package. It is internal infrastructure for the Eclipse PHP/Filament plugin family. Its value comes from reuse and consistency across our plugin suite, not from market adoption. Approve it only if we are already investing in that ecosystem and can support the shared dependency.

For engineering: eclipsephp/common provides shared Foundation and common implementation classes used by Eclipse plugins. Adopting it reduces duplicate code and standardizes patterns across packages, but it also creates a central dependency that every Eclipse plugin relies on. Changes require careful versioning, testing, and cross-package coordination. Treat it as platform code: small, stable contracts; strong backward compatibility; clear ownership.