Neptune Bundle Laravel Package

Getting Started

First, the reality check: this is a Symfony bundle, not a Laravel package. scylabs/neptune-bundle targets symfony/framework-bundle and ships Symfony DI extensions, Twig templates, and Doctrine-oriented config. There is no service provider, no facade, no publishable Laravel config, and no Illuminate dependency anywhere. In a Laravel app you cannot "just composer require it" and get anything usable — the container, routing, and templating models don't line up.

Where to look first if you're evaluating it anyway:

1. composer.json — check the require block for the Symfony version ceiling and PHP constraint. A bundle last released 2022-01-10 will almost certainly cap below what Laravel 11/12 pulls in transitively.
2. DependencyInjection/ — the *Extension class and Configuration.php tell you exactly what services and config keys the bundle registers. This is the fastest way to understand its actual surface area, since the README is likely thin.
3. Resources/config/ — service definitions and routing imports; this is what you'd have to reimplement by hand in Laravel.
4. LICENSE — the repo reports NOASSERTION, meaning GitHub could not detect a recognized license. Do not ship this commercially until you've read the actual license file and confirmed terms in writing.

First realistic use case: if you're on a Symfony app and need a config-driven admin/CRUD back office, this bundle is in that family (ScyLabs' Neptune line is an admin-panel-style bundle). If you're on Laravel and want that capability, skip this entirely and go to Filament — it's the closest thing to the config-driven "define resources, get a back office" experience, and it's actively maintained.

Implementation Patterns

Pattern 1 — Don't cross the streams. Never try to boot a Symfony bundle inside Laravel's container. Symfony bundles assume KernelInterface, compiler passes, Bundle::getContainerExtension(), and event-dispatcher wiring that Laravel does not provide. Even with a shim like symfony/http-kernel installed, the bundle's services won't resolve.

Pattern 2 — Sidecar service. If you genuinely need this bundle's behavior alongside a Laravel app, run it as a separate Symfony application and communicate over HTTP or a shared database. This is the only sane integration path, and it costs you a second deploy target.

Pattern 3 — Port the config, not the code. The bundle's valuable artifact is its configuration schema (Configuration.php), not its PHP. Translate that tree into config/neptune.php, map each entity/resource to an Eloquent model plus a Filament Resource class, and reimplement the CRUD screens with Blade/Livewire. You keep the domain model, drop the dead dependency.

Pattern 4 — Fork and vendor. If you must use the original code, fork it, pin to a specific commit SHA, and reference the fork via a VCS repositories entry in composer.json. Never rely on Packagist availability for a 2-star, 0-dependent, two-year-stale repo.

Typical Symfony-side workflow for reference (what you'd be porting): register the bundle in config/bundles.php, import its routing YAML under a prefix, define admin sections/entities in the bundle's config file, and override Twig templates under templates/bundles/... for customization. Every one of those extension points is Twig/DI-specific and has no Blade equivalent.

Gotchas and Tips

• No artisan integration. vendor:publish, config/app.php provider registration, and package discovery all do nothing here. Any tutorial claiming otherwise is wrong.
• Dependency conflicts are likely. Laravel 11/12 pulls modern symfony/* components (HttpFoundation, Console, Finder, etc.). A 2022 bundle with ^4.4|^5.0 style constraints will produce composer resolution failures — and --ignore-platform-reqs makes it worse, not better.
• NOASSERTION is a legal landmine. It is not "public domain" and not "MIT". Read the file; if there isn't one, assume all rights reserved and ask the maintainer.
• Abandonment signals: 2 stars, 0 dependents, no release since 2022-01-10. Treat it as unmaintained — no security patches, no Symfony 7 support, no PHP 8.3+ fixes.
• Debugging strategy: reproduce in a minimal symfony/skeleton app first. If it breaks there, it's not a Laravel integration problem — it's the bundle. This saves hours of misattributed blame.
• Extension points to inventory before forking: compiler passes, tagged services, Twig namespace overrides, and event subscribers. Count them; that count is your porting estimate. In Laravel these become service providers, Blade::component registrations, and event listeners.
• Recommendation: with a score of 0.04 and zero ecosystem, adopting this is a maintenance liability, not a shortcut. Budget for Filament or Laravel Nova (or EasyAdmin/Orchid if you're actually on Symfony) instead, and cite this bundle only as design inspiration for your config schema.