- What is dragon-code/laravel-support used for?
- It is a lightweight toolkit of helper functions, macros, and service-provider traits for Laravel applications and, more commonly, for Laravel package development. Its main job is to cut boilerplate around registering package resources such as configuration files, migrations, routes, translations, and Artisan commands. It also provides helpers for resolving package namespaces, paths, and resource discovery. It is a utility package, not a feature package, so it does not add user-facing functionality to your app.
- How do I install dragon-code/laravel-support with Composer?
- Install it with composer require dragon-code/laravel-support and pin to a verified version line with a caret constraint rather than leaving it unconstrained. The package is MIT licensed, has no native extensions, no external services, and no credentials, so installation is low friction. Commit your composer.lock so resolution stays reproducible. Because the provider is auto-discovered, helpers and providers become available without extra bootstrapping.
- Which Laravel and PHP versions does laravel-support support?
- Version 3.9.0 explicitly adds Laravel 13 compatibility, alongside support for earlier Laravel versions in the 3.x line. Confirm the exact PHP and Laravel constraints in the package's composer.json before upgrading, since the maintainer-asserted Laravel 13 support should also be exercised in CI rather than only reflected in the constraint. Also verify which major line you are on: the previous recommendation pointed at a ^4.x line while the current release is 3.9.0, and it is unclear whether a parallel 4.x track exists. Resolve that before pinning anything.
- Do I need to register the service provider manually in Laravel?
- No. The package is designed to work with Laravel's package auto-discovery, so its service provider is registered automatically and no config publishing or bootstrapping ceremony is required for most helpers. If you disable auto-discovery or use a non-standard setup, you can register the provider manually in your application's provider list. Be aware that auto-discovered providers do register behavior you did not explicitly ask for, which is worth auditing if you keep a strict provider allowlist.
- How do the service-provider traits help with package migrations, routes, and translations?
- The traits wrap the repetitive registration calls a package provider normally makes, so you can load migrations, routes, translations, config, and Artisan commands with far less code. Instead of repeating paths and container calls in every package, you compose the relevant trait into your provider and point it at your resource directories. This keeps package bootstrapping organized and predictable, and it makes resource locations consistent across a family of packages. It is most valuable if you maintain several packages with the same structure.
- Does dragon-code/laravel-support support Laravel 13?
- Yes, version 3.9.0 adds explicit Laravel 13 compatibility, which is the first clear evidence of forward-compatibility work on this package. That release is a minor with no breaking changes, no deprecations, and no behavior changes beyond repository hygiene such as license year and README updates. The compatibility claim is maintainer-asserted, so confirm it is covered by CI rather than only present in composer.json before relying on it for a framework upgrade. If you are planning a Laravel 13 migration, this is the release to evaluate against.
- Will the global helper functions collide with other Laravel packages?
- That is a real risk. The package ships unnamespaced global functions, which can collide with helpers from illuminate/support, Symfony polyfills, or other helper packages if any of them define the same names. Check the function list against your dependency tree and run your test suite after installing. If you only need a handful of helpers, inlining them in your own namespaced code avoids the global namespace entirely.
- Is dragon-code/laravel-support still maintained?
- The prior assessment flagged the repository as archived, but the maintainer-authored Laravel 13 compatibility pull request and the 3.9.0 tagged release are inconsistent with an archived repo, so the archive status is in question. Verify the repository state directly on GitHub before acting on either assessment. Even if unarchived, a single re-engagement release is not a stated support policy, SLA, or succession plan, and the bus factor remains one. Treat it as a maintained-but-single-maintainer dependency and plan accordingly.
- Is laravel-support safe to use in production Laravel applications?
- Technically it is low-risk to install: MIT licensed, no native dependencies, no external services, and a semver-appropriate 3.9.0 minor release. The production concerns are longer term: the package statically couples to framework internals such as the service container, config repository, and Illuminate\Support, so helpers can break across minor Laravel releases even without a major bump. It also has no reported dependents, meaning little independent ecosystem validation. Pin a caret constraint on the verified line, keep the lockfile committed, and wrap or isolate the helpers you depend on.
- Should I use laravel-support or just write the helpers myself?
- For application code, writing the helpers yourself is often the better call. The deciding question is which specific helpers you actually consume; if it is a small set, they can usually be inlined in under a couple hundred lines of namespaced code, removing the global function collisions and framework-internal coupling entirely. The package makes more sense if you maintain many Dragon Code style packages and want consistent resource registration across them. Check whether the package ships test coverage you can inherit, because a fork or reimplementation would otherwise start from zero.