Weave Code
Laravel Package Core Laravel Package
jobmetric/laravel-package-core
A core foundation for building Laravel packages with JobMetric: shared service providers, configuration handling, migrations, and helper utilities that standardize structure and speed up development.
It is a standard package of different components of Laravel that helps you write different packages better and more fluently
Frequently asked questions about Laravel Package Core
- What is jobmetric/laravel-package-core used for?
- It is a foundation package for developers who build other Laravel packages, bundling the common components those packages usually rewrite: shared service providers, configuration handling, migration loading, and helper utilities. It standardizes package structure so you can scaffold a new package quickly and keep behavior consistent across a suite of packages. Recent releases also ship dto() and dtoMany() helpers for building typed payloads with an optional context value.
- How do I install jobmetric/laravel-package-core with Composer?
- Install it with composer require jobmetric/laravel-package-core. The package is expected to register through Laravel package auto-discovery or an explicit service provider, so no manual wiring should be needed in most applications. After installing, run a quick smoke test that resolves the provider and calls one helper before relying on it broadly.
- Which Laravel and PHP versions does this package support?
- Check the composer.json constraints in the repository before installing, because the supported PHP and Laravel ranges determine whether it fits your stack. Verify the constraints against your current PHP version, Laravel major version, and any pinned dependencies that could conflict. Running composer why-not on a branch is a fast way to confirm compatibility before merging.
- What do the dto() and dtoMany() helpers actually do?
- They reduce boilerplate when turning request data or arrays into DTO instances, with dto() handling a single record and dtoMany() mapping a collection. Release 1.26.0 added a context parameter to these helpers so request-scoped metadata can travel with the DTO instead of being passed around separately. Confirm in the changelog how context is stored and whether it is optional before adopting it.
- Is the new context parameter backward compatible?
- It should be safe if the context argument is optional with a default, but that needs verification rather than assumption. If the parameter was inserted into an existing positional signature, or if callers rely on reflection or serialization of helper arguments, previously working calls could break. Pin the minor version, read the release notes, and run your static analysis and test suite against 1.26.0 on a branch first.
- Will the global dto() and dtoMany() helpers collide with my application's functions?
- These helpers may be declared as global functions, which means a name clash with your own helpers or another package's helpers is possible. Search your codebase and Composer dependencies for existing definitions before enabling the package. If collisions exist, wrap the helpers behind your own service or adapter so the dependency stays isolated.
- Do I need to publish configuration files or run migrations?
- Configuration publishing is typically optional and only needed if you want to override the package defaults. No database migration is implied by the core package or by the DTO helpers, though the package does provide tooling for packages that ship their own migrations. Publish only what you actually customize so upgrades stay simple.
- How should I test this package in my Laravel application?
- Do a short spike on a non-production branch: install the package, add dto() and dtoMany() to one controller or service, and pass a context value to confirm the semantics. Write a couple of small tests covering single DTO creation, collection mapping, and context propagation, then run your normal CI, static analysis, and serialization checks. Compare the result against your existing array or API resource pattern before expanding.
- Does dtoMany() add performance overhead on large collections?
- DTO hydration is generally an in-process, low-cost operation, but dtoMany() over a large collection adds transformation work per item and can become noticeable on high-volume list endpoints. Benchmark one representative endpoint before rolling it out widely. If the cost is real, keep arrays in the hot path and reserve DTOs for boundaries where typed payloads genuinely help.
- Is this package safe to adopt in production, and how should I roll it out?
- Adopt it incrementally rather than as a broad refactor. Confirm the changelog and semver impact, install on a branch, pilot the helpers in one bounded module, review the results, and then expand. Pin minor versions, watch maintainer activity and test coverage, document your own conventions for DTOs and context, and monitor error rates and latency after each step.
Weaver
How can I help you explore Laravel packages today?