Weave Code
Easy Core Laravel Package
eonx-com/easy-core
EonX Easy Core provides shared foundational utilities and abstractions for Laravel packages, helping developers build consistent, reusable components with less boilerplate. It underpins the Easy package family and simplifies common setup tasks.
[READ-ONLY] Provides core features for Lumen applications
Frequently asked questions about Easy Core
- What is eonx-com/easy-core used for?
- It is a foundational utility package for Laravel and Lumen applications that supplies reusable building blocks instead of application-specific logic. It covers base service providers and package bootstrapping helpers, value objects and DTOs, collection utilities, consistent exception handling and validation support, framework-agnostic array, string and date helpers, and practical testing utilities. In practice it is the shared base layer under the EonX Easy package family rather than a feature package you would use on its own.
- How do I install eonx-com/easy-core in a Laravel project?
- Install it with Composer, register the package service providers in your application, and publish its configuration if you need to override defaults. Integration is mechanically low cost: there is no infrastructure dependency, no new build step, and no polyglot tax. The real constraint is not installation effort but deciding whether your service is genuinely Lumen-shaped before you build on top of it.
- Does eonx-com/easy-core support Laravel, or is it Lumen only?
- The package is positioned as a foundational layer for Lumen-based services, and it provides bootstrapping and provider abstractions aimed at that shape of application. Lumen itself is in maintenance-only mode upstream, so adopting this package compounds a package bet with a framework lifecycle bet. Confirm the Lumen version support matrix and the maintainer's plan for parity releases before you commit, and treat this as the top item on your risk register.
- Can I open an issue or pull request on the eonx-com/easy-core GitHub repository?
- No. This repository is a read-only split from EonX's internal monorepo, so issues and pull requests do not land here. Any defect must route through EonX's internal release cycle, on their priorities and their schedule. That makes you a downstream consumer with no influence over the vendor backlog and no formal escalation path, which should be recorded as a supplier dependency in your risk register.
- Is eonx-com/easy-core safe to use in production?
- It has no external validation surface: roughly three stars and zero dependents, so there is no corpus of production failure reports or third-party operational experience to lean on. Because a core package owns exception handling, request lifecycle, serialization and bootstrapping by definition, the failure mode is not a loud break but silent behavior changes after an upgrade. Pin the version you adopt, wrap it in integration tests, and get an explicit written answer from the maintainer about whether it is a supported product with an external-consumer commitment.
- What components does eonx-com/easy-core actually provide?
- The package provides base service providers and package bootstrapping helpers, reusable value objects, DTOs and collection utilities, consistent exception handling and validation support, and framework-agnostic helpers for arrays, strings and dates. It also includes practical utilities aimed at testing and package development. Ask the maintainer to enumerate exactly which concerns easy-core owns versus which it leaves to the consuming application, particularly exception rendering, validation, pagination and auth glue, so you are not inferring behavior.
- How does easy-core relate to the other eonx easy-* packages?
- It is the shared base that the rest of the Easy family builds on, including packages for webhooks, activity logging, error handling and pagination. That means the real architectural unit of adoption is the family, not this artifact in isolation. Deciding on easy-core while leaving its siblings undecided is a half-decision you will need to revisit, so evaluate the set together.
- Is there a tagged, semver'd release and changelog I can pin against?
- The public repository is described as a read-only split from an internal monorepo, and no external changelog or guaranteed release cadence is documented in the package metadata. Before adopting, ask the maintainer in writing whether the read-only split is the release artifact or whether there is a tagged, semver'd upstream you can pin against. Without that answer you cannot plan upgrade windows or assess blast radius reliably.
- How should I test an application that depends on eonx-com/easy-core?
- The package ships utilities intended for testing and package development, so use those where they fit rather than reimplementing helpers. Because easy-core owns bootstrapping, exception handling and serialization, write integration tests that assert observable application behavior, not just unit-level calls into the package. Pin the exact Composer version and re-run the suite on every bump, since an upgrade can change customer-facing responses without any code change on your side.
- What are the alternatives to eonx-com/easy-core?
- For greenfield Laravel work, the framework's own primitives cover most of what this package offers: Illuminate collections, the Arr and Str helpers, Carbon for dates, and standard exception handling through the handler. Package authors commonly reach for dedicated package tooling rather than a Lumen-oriented core layer. If your service is not genuinely Lumen-shaped, stateless and JSON-only, the honest alternative is the framework itself rather than adopting a core layer whose lifecycle is trending the wrong way.
Weaver
How can I help you explore Laravel packages today?