Laravel Shared Utils Laravel Package

Getting Started

This is a very small, low-adoption package (1 star, 0 dependents). Treat it as a shared internal utility library rather than a community-standard dependency: the main value is likely a handful of base classes, traits, helpers, or service-provider glue used across Nuimarkets projects. Before adopting it, verify what is actually inside.

First steps

1. Read the package before installing.

   • composer show -a nuimarkets/laravel-shared-utils
   • Inspect the GitHub repo: composer.json, README.md, src/, config/, tests/.
   • Confirm the license, PHP constraint, and illuminate/* version range.

2. Install it in a branch, not directly on main.

   composer require nuimarkets/laravel-shared-utils
   

   For private/internal use, add a VCS or path repository instead of relying on Packagist:

   {
     "repositories": [
       { "type": "vcs", "url": "[email protected]:nuimarkets/nui-laravel-shared-utils.git" }
     ]
   }
   

3. Check auto-discovery and namespaces.

   • Look at extra.laravel.providers and extra.laravel.aliases in the package's composer.json.
   • Run php artisan package:discover and php artisan about to confirm what was registered.
   • Run composer dump-autoload -o and verify the PSR-4 namespace resolves.

4. First concrete use case: borrow one trait or base class. Pick the smallest useful piece — a formatting helper, a UUID trait, a base model/controller — and use it in a throwaway branch against your test suite. Do not start by wiring the package into every model or controller.

5. Pin the version exactly in composer.json until you have confidence in the package's release discipline:

   "nuimarkets/laravel-shared-utils": "1.2.3"
   

If the package publishes assets, confirm the provider namespace from src/ before running:

php artisan vendor:publish --provider="NuiMarkets\\SharedUtils\\SharedUtilsServiceProvider"

Implementation Patterns

Consume selectively, not wholesale. This package's name suggests a grab-bag. Import individual classes (use NuiMarkets\SharedUtils\...) rather than depending on global helper functions or facades spread throughout the app.

Wrap borrowed behavior behind app-level adapters. If the package provides a base model, trait, or helper you rely on, create a thin App\Support\... wrapper or subclass. This gives you one place to patch or replace if the package is abandoned:

namespace App\Support;

use NuiMarkets\SharedUtils\SomeTrait;

abstract class SharedModel extends \Illuminate\Database\Eloquent\Model
{
    use SomeTrait;
}

Then extend App\Support\SharedModel everywhere, not the vendor class directly.

Use base classes for cross-cutting behavior. If the package offers base models/controllers/requests, use them for shared concerns such as UUID keys, common casts, audit fields, or response formatting. Test them against your existing models first — base classes tend to make assumptions about primary keys, timestamps, and table naming.

Treat traits as behavior contracts. Before adopting a trait, check for property or method collisions with your classes:

grep -R "function \|public \$" vendor/nuimarkets/laravel-shared-utils/src

Prefer traits that are self-contained and have no hidden dependencies on the host app.

Register bindings in your own provider. If the package binds singletons or interfaces, either let its provider do it or bind explicitly in AppServiceProvider. Avoid both, or you will get confusing double registration.

Publish and commit config. If there is a config file:

php artisan vendor:publish --tag=shared-utils-config

Commit the published file and override only the keys you need. Do not edit files under vendor/.

Add contract tests around every borrowed class. Because the package has no meaningful adoption or documented API stability, write a small test suite that exercises the behavior you depend on. Run it on every dependency update:

it('formats X as expected', function () {
    expect(shared_util_helper('foo'))->toBe('FOO');
});

Use static analysis to compensate for missing docs. Run Larastan/PHPStan against your app and, if needed, generate stubs for the package. The source is the documentation.

Fork or vendor if it becomes load-bearing. With one star and zero dependents, the bus factor is effectively one. If you use it in production, keep a fork (or copy the needed classes into app/Support with license attribution) so you can patch without waiting for upstream.

CI pattern. Pin the package in composer.lock, but add a scheduled job that tests the latest allowed version in a separate branch. This surfaces upstream breaks early without destabilizing main.

Gotchas and Tips

• Low adoption means no safety net. One star, zero dependents, and a single maintainer mean no community bug reports, no Stack Overflow answers, and limited semver discipline. Verify every release diff before upgrading.
• Check the release metadata. The listed last release date (2026-10-19) is unusual; confirm the tag actually exists, matches the constraint, and is not a mistyped or pre-announced release. Avoid dev-main in production.
• Double provider registration. Laravel auto-discovers providers. If you also add the provider manually in bootstrap/providers.php or config/app.php, bindings, listeners, and commands may register twice. Check app()->getLoadedProviders():

  php artisan tinker
  >>> array_key_exists('NuiMarkets\\SharedUtils\\...ServiceProvider', app()->getLoadedProviders());
  

• Global helper collisions. "Common classes" packages often ship global functions. Check for function_exists() guards and name collisions with Laravel helpers or other packages. Prefer class-based calls where possible.
• Facade alias shadowing. If the package registers aliases, they can override or be overridden by your app aliases. Compare config/app.php aliases against the package's extra.laravel.aliases.
• Config publish overwrites. vendor:publish can clobber an existing config file. Use --tag to publish selectively and diff before using --force.
• PSR-4 / autoload mismatches. If classes are not found, check the package's autoload.psr-4 mapping, then run composer dump-autoload -o. Namespace typos in tiny packages are common.
• Version constraints can block framework upgrades. Check composer why-not laravel/framework and inspect the package's illuminate/support range before planning a Laravel or PHP upgrade. A stale constraint here can hold the whole app back.
• No tests means you own the coverage. Do not assume package behavior is verified. Write tests for the specific methods or traits you use.
• Debugging tools. composer show nuimarkets/laravel-shared-utils, php artisan about, php artisan package:discover, and php artisan tinker for instantiating classes directly are faster than guessing from the package name.
• Extension points to prefer. Published config, subclassing base classes, composing traits, and rebinding interfaces in your own provider. Avoid monkey-patching vendor files, which will be lost on composer update.
• Have an exit plan. Keep usage behind App\Support wrappers and document each borrowed class in a short internal note. If the package is abandoned, you can copy those classes into your app with license attribution and remove the dependency in one commit.