grafite/support
A utility support package for Laravel applications, offering reusable helpers, traits, and convenience functions that streamline common development tasks. It centralizes shared code so projects stay cleaner, more consistent, and easier to maintain across your codebase.
grafite/support is a small grab-bag of Laravel utility helpers from Grafite Inc, the team behind GrafiteBuilder/CMS. It is not a framework layer — treat it as a set of functions and small classes you'd otherwise copy-paste into app/Support. With zero dependents and no stars driving adoption, the first job is figuring out what is actually in the box before wiring it in.
Minimal steps:
Install and pin.
composer require grafite/support
Because the package is low-activity, commit the exact version to composer.json ("grafite/support": "x.y.z" rather than ^x.y) so a surprise release can't move under you.
Read composer.json first, not the README. The autoload block tells you the real surface area:
"autoload": { "files": ["src/helpers.php"], "psr-4": { "Grafite\\Support\\": "src/" } }
If there's a files entry, you're getting globally-defined functions loaded on every request. That changes how you reason about collisions and static analysis. If it's PSR-4 only, it's classes you opt into.
Inventory src/. List the tree and skim the helper file and any SupportServiceProvider. Group what you find into buckets (string/array utilities, response/redirect helpers, formatting, config access) and write that list down — that's your day-to-day cheat sheet. The package's value is proportional to how much of it you can actually name from memory.
Confirm auto-discovery. Laravel should register the provider via extra.laravel.providers. Verify with:
php artisan about
If the provider isn't listed, add it manually to config/app.php.
First use case: collapse repeated inline code. The realistic entry point is a controller or Blade view where you're doing the same awkward transformation three or four times — a response shape, a formatted string, a redirect with flash data. Replace one occurrence with the package helper, run the route, and confirm behavior matches. Do this in php artisan tinker first if the helper is pure:
>>> grafite_helper_name('sample');
Verify the license before it ships. The repo reports NOASSERTION, meaning GitHub could not parse the license file. Open LICENSE in the vendor directory and read it yourself. If it's ambiguous or missing, that's a blocker for anything client-facing or redistributed — flag it to whoever owns legal/compliance rather than assuming MIT because it's a Grafite package.
Helper-first in controllers and Blade. The natural fit for a package like this is erasing small, repetitive boilerplate at the edges of your app — response construction, string cleanup, path/URL formatting. Keep usage shallow: one helper call replacing two or three lines of inline logic. If you find yourself nesting three helpers, write a named method in your own code instead.
Wrap it, don't sprinkle it. This is the single most important pattern for a low-maintenance dependency. Create app/Support/Support.php (or a facade) with your own method names that delegate to the package:
namespace App\Support;
class Support
{
public static function slug(string $value): string
{
return grafite_helper_name($value); // single point of contact
}
}
Now the package appears in exactly one file. If it goes stale, or a helper changes signature, you swap the internals and nothing else in the codebase moves. Given zero dependents and no visible release cadence, this insulation is worth the extra ten minutes.
Adopt by category, not wholesale. You will almost certainly not need everything in the package. Pick the two or three helpers that genuinely save you time and ignore the rest — dead imports and unused globals cost you in static analysis and in onboarding. Document the chosen subset in README or a short docs/support-helpers.md so the next developer knows what's sanctioned.
Blade integration. For anything presentation-adjacent, expose it through a Blade directive or a view composer rather than calling raw globals in templates:
Blade::directive('money', fn ($expr) => "<?php echo grafite_helper_name($expr); ?>");
This keeps templates readable and gives you a single rename point later.
Compose with other Grafite packages deliberately. If you're already running GrafiteBuilder or another Grafite package, grafite/support is likely a shared foundation they were built against — expect overlapping helpers and consistent naming. Check whether your other Grafite dependencies already pull it in transitively (composer why grafite/support) before adding it as a direct requirement; you may be able to rely on the transitive version and avoid a version constraint conflict.
Test the boundary, not the package. Don't write tests that assert grafite/support behavior — those are the maintainer's tests to own. Write tests against your wrapper:
it('formats a slug', function () {
expect(Support::slug('Hello World'))->toBe('hello-world');
});
If the package is ever swapped out, your test suite tells you immediately whether the replacement is faithful.
Use it in form requests and validation paths sparingly. Helpers are convenient for normalizing input (trimming, casing, slugifying) inside prepareForValidation(). That's a legitimate integration point — just make sure the helper is pure and doesn't touch the container or session, otherwise you'll get surprising behavior in tests and queue workers.
Global function collisions are the top risk. If the package autoloads src/helpers.php, its functions live in the global namespace. Laravel itself, symfony/*, and other helper packages (laravel/helpers, various *_helpers.php files) define short, obvious names. A redeclaration is a fatal error, not a warning. Before installing, grep your own app/ and any helper files for the names the package defines:
grep -R "function grafite_helper_name" app/ vendor/ --include=*.php
Watch for the classic case: a helper the package defines that you already wrote yourself. Rename yours or skip the package.
NOASSERTION is not "no license." It means GitHub's detector failed. The file may be MIT, may be a custom Grafite license, may be missing entirely. Read it. If it's a custom or restrictive license, note the obligations (attribution, redistribution terms) somewhere your team will see them — this is exactly the kind of thing that surfaces during an acquisition or a client audit, not during development.
Pin the version and vendor-audit. With no dependents and no visible activity, treat upgrades as events, not routine. After composer update, run git diff vendor/grafite/support in a scratch checkout to see what actually changed. If the package goes unmaintained, the escape hatch is straightforward: copy the handful of helpers you use into app/Support/helpers.php, delete the dependency, and your wrapper keeps everything compiling.
Static analysis will complain. Global functions defined in vendor/ are often invisible to PHPStan/Larastan and to your IDE. Fix it once:
scanFiles (or bootstrapFiles).barryvdh/laravel-ide-helper and regenerate, or add a _ide_helper.php stub listing the function signatures you use.ignoreErrors for "Function not found" on the specific helper names, or better, put the stub file in stubFiles.Debugging a "helper not found" error. Nine times out of ten it's the autoloader, not the package:
composer dump-autoload
php artisan config:clear
php artisan clear-compiled
If the functions still aren't there, confirm the provider is registered (php artisan about) and that the package's composer.json actually has a files autoload entry. Some micro-packages ship helpers that are only loaded conditionally or only when a config flag is set — read the provider's register()/boot() to check.
Config publishing is likely all-or-nothing. If the package ships a config file, php artisan vendor:publish --provider="Grafite\Support\SupportServiceProvider" will drop the whole thing into config/. Don't edit the published file's structure — keep your overrides in .env or in a thin wrapper config so future package updates don't produce a merge conflict you can't reason about.
Container and facade assumptions. Small support packages sometimes reach into app(), config(), or Auth inside helper functions. That's fine in HTTP requests and silently wrong in queue workers, console commands, and unit tests without a booted app. If a helper misbehaves in a job, that's your first suspicion — and a reason to prefer pure helpers and wrap impure ones at the edge.
Extension points are thin, and that's the point. Don't expect events, macros, or a driver system. The realistic extension strategy is the wrapper class above plus Blade directives. If you need behavior the package doesn't offer, add it to your wrapper rather than forking — a fork of a zero-dependent package means you own it forever.
Onboarding cost is the hidden tax. A grab-bag helper package means new developers can't tell "is this ours or the vendor's?" Keep the sanctioned subset documented, keep the wrapper, and don't let raw package globals leak past app/Support/.
How can I help you explore Laravel packages today?