Base 25 Laravel Package

Getting Started

This is not a feature package you bolt onto an app — it's a scaffold: a service provider, a config stub, and a helpers file that gabrielfpereira-style packages extend. Day-to-day leverage comes from using it as the base class for your own internal packages, not from composer require alone.

First steps, in order:

1. Read composer.json before anything else. Confirm the actual PSR-4 root and auto-discovery entry. The description names the repo base-25, so expect something like:

   "autoload": { "psr-4": { "GabrielfPereira\\Base25\\": "src/" } },
   "extra": { "laravel": { "providers": ["GabrielfPereira\\Base25\\Base25ServiceProvider"] } }
   

   Verify the real namespace — do not assume it from the repo name.

2. Install it.

   composer require gabrielfpereira/base-25:^1.0
   

   Discovery should register the provider automatically. If it doesn't appear in php artisan about under packages, add it manually to config/app.php.

3. Publish and read the config.

   php artisan vendor:publish --provider="GabrielfPereira\Base25\Base25ServiceProvider" --tag=config
   

   The published file is the fastest way to see what the package actually configures — the description is thin, so treat the config keys as the source of truth for its surface area.

4. First real use case: create a new internal package by copying src/ and extending the base provider rather than writing register()/boot()/mergeConfigFrom() boilerplate yourself:

   class MyFeatureServiceProvider extends Base25ServiceProvider
   {
       public function register(): void
       {
           parent::register();
           $this->mergeConfigFrom(__DIR__.'/../config/my-feature.php', 'my-feature');
       }
   }
   

Look at these files first, in this order: src/*ServiceProvider.php, config/*.php, the helpers autoload (likely src/helpers.php wired via autoload.files), then README.

Implementation Patterns

Extend, don't consume directly. The package is designed for inheritance. Subclass its provider, call parent::register() and parent::boot(), then layer your own bindings. This keeps its conventions while letting you override anything.

Keep your app code behind an adapter. Even for a scaffold, don't let GabrielfPereira\Base25\... namespaces leak into controllers. Wrap the helper functions and any public config reads in your own service:

namespace App\Support;

final class Platform
{
    public static function helper(string $key): mixed
    {
        return \GabrielfPereira\Base25\Helpers::get($key); // whatever the real surface is
    }
}

If the upstream package stalls (0 stars, single maintainer), the swap is a one-file change.

Use it as a Composer template, not a runtime dependency, for greenfield internal packages. composer create-project or copy-paste the skeleton into a new repo, rename the namespace, and delete the gabrielfpereira author metadata. You get the registration boilerplate without inheriting the dependency and its bus factor. Keep composer require for apps that need the shared behavior at runtime.

Config merge pattern. The base provider almost certainly calls mergeConfigFrom(__DIR__.'/../config/base-25.php', 'base-25') in register(). Your packages should follow the same pattern — publishable config with safe defaults, overridable per app. Remember mergeConfigFrom is shallow: nested arrays won't deep-merge, so document that app overrides replace whole sub-arrays.

Helper conventions. If helpers are autoloaded via autoload.files, they're global functions. Namespace them clearly (base25_* or a class-based facade) to avoid collisions with Laravel's own helpers.php and with other packages that do the same thing. Prefer calling through a class (Str::-style) in new code.

Integration tip — discovery in tests. In phpunit.xml, if you use orchestra/testbench for your own packages built on this base, register the provider explicitly in getPackageProviders() rather than relying on Laravel's discovery, so tests are reproducible.

Version pinning. Pin ^1.0 in composer.json and commit composer.lock. Given the release cadence and single-maintainer signal, treat every minor as a reviewable change: diff src/ between tags before bumping.

Gotchas and Tips

• The assessment-pm.md text is generic boilerplate about auth, billing, notifications, media, and search — none of which this package actually provides. Do not pitch it to stakeholders as a feature package. It is registration scaffolding. That mismatch is the single biggest misunderstanding risk on this repo.

• 0 stars / no visible tests. Run the package's own composer test (if a script exists) before adopting, and write your own smoke test over the exact surface you call — the provider registers, config merges, helpers resolve. You cannot lean on upstream coverage here.

• Namespace and provider class must be verified, not assumed. The repo name (base-25) and namespace (GabrielfPereira\Base25) are conventions, not guarantees. A wrong --provider= flag in vendor:publish fails silently with "no publishable resources."

• Auto-discovery conflicts. If two packages register the same config key or helper function name, the last one loaded wins — and load order is composer-dependent. Name your own keys under an app-specific prefix.

• mergeConfigFrom caching trap. After changing a published config file, run php artisan config:clear (or config:cache in deploy). In production, a stale config cache is the usual cause of "the package config isn't taking effect."

• Helper collision debugging. If you get Cannot redeclare function ..., one of your packages (or Laravel's helpers.php) uses the same function name. Fix by wrapping in if (! function_exists(...)) upstream or by dropping the base package's helpers file from autoload.files in your fork.

• Extending boot() incorrectly. If the base provider registers middleware, routes, or migrations in boot(), your subclass must call parent::boot(). Omitting that is the most common silent failure when extending any scaffold package.

• Publishing migrations/assets. The publish tag names aren't documented. List them first:

  php artisan vendor:publish --provider="GabrielfPereira\Base25\Base25ServiceProvider"
  

  (omit --tag) and pick from the prompt. Publish to version control before editing — never edit vendor/.

• Extension points worth a README line. Any protected methods on the base provider (registerConfig, registerBindings, bootHooks) are your real extension surface. Grep src/ for protected function and protected $ and document them yourself — the package won't.

• Forking is a legitimate strategy. Given single-maintainer risk and near-zero community signal, forking into your org namespace (e.g. Acme\Base) and owning it may be cheaper than tracking upstream. You lose upstream fixes, but with a scaffold that changes rarely, that's usually the right trade.

• Don't let the config schema become your schema. This package is scaffolding — if you find yourself storing domain defaults in its publishable config, you've created lock-in where none was needed. Keep business config in your app, base config in the package.