Core Laravel Package

Getting Started

ixudra/core is not a feature package — it is the shared base library that the Ixudra family of packages (ixudra/curl, ixudra/translation, ixudra/validation, ixudra/boilerplate, etc.) build on. You install it as a dependency (composer require ixudra/core) but there is nothing to publish or configure out of the box; its value is in the abstract classes it exposes for your package or service layer.

Where to look first:

1. composer.json — check the illuminate/support (or laravel/framework) version constraint. This is the single biggest blocker; a package this old often pins ~5.x, which conflicts with Laravel 10+/11+.
2. src/Ixudra/Core/ServiceProvider.php — the abstract provider carrying the config/views/translations/migrations/assets registration and vendor:publish helpers. This is the main reason to depend on the package.
3. src/Ixudra/Core/Services/BaseService.php — the abstract service-layer base class (constructor conventions, shared helpers).
4. Any Helpers/ or Contracts/ directory — usually small, but confirms the namespace root is Ixudra\Core.

First use case: you are writing a Laravel package and want a provider that already knows how to mergeConfigFrom, loadViewsFrom, loadTranslationsFrom, loadMigrationsFrom, and register publish tags without copy-pasting the same twenty lines. Extend Ixudra\Core\ServiceProvider, point the path helpers at your package's config/, resources/views, resources/lang, database/migrations, and public/ directories, and you are done. The second use case is a consistent BaseService for your application's service layer, mirroring the author's other packages.

Be aware of scale: 1 star, 0 dependents. Treat the source itself as the documentation.

Implementation Patterns

Package provider bootstrap. Your package provider extends the core provider and calls its registration helpers, typically from boot() and register(). Because the base class is doing the work, keep your own methods thin — one call per resource type — and let the base handle paths and publish tags.

Service layer inheritance. Extend BaseService and keep constructor injection standard Laravel (type-hinted dependencies resolved by the container). Do not put business logic in the base class's overrides; use it only to normalize how services are constructed and how common lookups/pagination are performed across your codebase.

Use it as a template, not a runtime dependency. Given the maintenance risk, the highest-value pattern is to read ServiceProvider.php, copy the ~100 lines you need into your own package, and drop the dependency. You get the same ergonomics without the version-constraint exposure. This is the recommended path for anything long-lived.

Ecosystem cohesion. If you are already using another ixudra/* package, adopting the core keeps your providers and services stylistically identical to the rest of that vendor's code. That is the only strong argument for a hard dependency.

Fork-and-path-repository. If you need the base classes but must patch constraints, fork on GitHub, bump composer.json, and pull it in via a path or VCS repository:

"repositories": [{ "type": "vcs", "url": "https://github.com/you/core" }],
"require": { "ixudra/core": "dev-master" }

Testing. The base classes are abstract, so test your subclasses with orchestra/testbench — spin up a package provider, assert that vendor:publish --provider=... exposes the expected tags, and assert view/translation namespaces resolve.

Gotchas and Tips

• Version constraints are the likely failure point. If composer require fails, read the error before working around it. Do not use --ignore-platform-reqs to force a Laravel 11/12 install against a Laravel 5 constraint — the base provider may call ServiceProvider APIs that no longer exist. Fork and update instead.
• parent::boot() is mandatory. If you override boot() or register() in your subclass, call the parent. The publish tags and namespace registrations live there; silently skipping them produces "view not found" and missing vendor:publish entries with no error.
• Conventional directory layout is assumed. The helpers expect config/, resources/views, resources/lang, database/migrations, and public/ at the package root. Unconventional layouts require overriding the path methods — verify the exact method names in src/ rather than guessing.
• Auto-discovery does not apply to the core. The package registers nothing on its own; your provider must be listed in your package's extra.laravel.providers block.
• Debugging publishes: run php artisan vendor:publish with no arguments to list all registered tags, then filter by your provider. If your tags are absent, the parent registration was not reached.
• No first-party docs, no tests to lean on. Grep the source for method names; do not trust blog posts or IDE autocompletion from a stale vendor cache (composer dump-autoload after edits).
• Abandonment risk. Zero dependents and minimal activity means no security patches and no Laravel upgrades. Pin an exact version in composer.lock, and if you ship this to production, vendor the two or three classes you actually use.
• MIT license is the escape hatch. Forking and maintaining your own trimmed copy is explicitly permitted and, for most teams, the right call.
• Extension points: prefer overriding the protected path/registration methods over re-implementing boot(); that keeps you compatible if you ever do take an upstream update.