- Is orkestra/common compatible with Laravel?
- It is not a natural fit for a standard Laravel application. Laravel is Eloquent-first while orkestra/common is positioned for Doctrine 2 projects, so it may only work in a Laravel app that already uses Doctrine through a bridge or in a legacy Doctrine migration. Expect a secondary persistence model and extra integration surface.
- What does orkestra/common actually do?
- It is described as common functionality and a shared foundation for Orkestra packages, with utilities, configuration helpers, and reusable base classes for Doctrine 2 projects. The technical evaluation cautions that the exact public API and replaceability are unclear without inspecting the source. It is not a general-purpose Laravel helper package.
- How do I install orkestra/common?
- The Composer package name is orkestra/common, so installation would typically be composer require orkestra/common. However, verify availability and constraints first because the last release was in 2014 and the package may not support your PHP or Laravel version. Run a compatibility spike before adding it to a production dependency set.
- Does orkestra/common support PHP 8 and modern Laravel versions?
- Almost certainly not out of the box. The last release was 2014, which predates modern PHP, Laravel, and Doctrine versions, so you should expect stale Composer constraints and PHP 8 incompatibilities. Run composer why-not and a time-boxed compatibility spike before assuming it can be installed.
- Can I use orkestra/common with Eloquent instead of Doctrine?
- No, the package is explicitly aimed at Doctrine 2 projects, so it is not designed to work with Eloquent. In an Eloquent-based Laravel app, adopting it would introduce an unnecessary second persistence and domain model. Prefer native Laravel utilities or a small internal helper instead.
- Is orkestra/common still maintained?
- There is no evidence of active maintenance. The last release was 2014-09-17, it has 1 star and 0 dependents, and the assessment found no active maintainer. Treat it as abandoned code and plan for forking, vendoring, patching, or replacement if you adopt it.
- What are the alternatives to orkestra/common for Laravel?
- For most Laravel applications, the best alternative is native Laravel utilities or a small internal helper package. If you need Doctrine, use modern Doctrine ORM and DBAL components directly rather than an old shared package. Only consider orkestra/common if it contains a small, extractable utility set that you cannot easily reimplement.
- How risky is using orkestra/common in production?
- The technical risk is high. The package predates modern PHP, Laravel, and Doctrine, and expected risks include stale Composer constraints, PHP 8+ incompatibilities, Doctrine 2.x API coupling, missing tests, and maintenance exposure. Run a proof of concept in an isolated branch before any production commitment.
- Does orkestra/common include Laravel service providers?
- The blurb mentions service providers, but the technical assessment found no evidence of Laravel service-provider integration. You should inspect the source to see whether those providers target Laravel, Symfony, or Doctrine. In a Laravel app, expect to write your own adapter or service provider.
- How should I test orkestra/common before adopting it?
- Start with a discovery spike: inspect the source, Composer constraints, tests, and public API surface. Validate against your target PHP, Laravel, and Doctrine versions using composer why-not, static analysis, and the package test suite, then add application-level integration tests. Keep the package behind an internal interface so you can replace it without touching domain code.