- What is perform/base-bundle and what does it do?
- Perform Base Bundle is a Composer package that provides a lightweight foundation for PHP applications and packages. It bundles shared base classes, configuration defaults, and service wiring so teams can standardize project structure and avoid repeating the same boilerplate across projects. Because the public documentation is thin, review the source or clone the repository to see exactly which providers, contracts, helpers, and config files it ships before adopting it.
- How do I install perform/base-bundle in a Laravel application?
- Install it with Composer using composer require perform/base-bundle, ideally into a throwaway Laravel app that matches your production version before touching a shared codebase. If the package ships publishable assets, run php artisan vendor:publish to copy config or migration files into your app. Confirm the service provider is registered through Laravel package auto-discovery, or register it manually in your providers configuration if it is not declared.
- Does perform/base-bundle support Laravel package auto-discovery?
- Auto-discovery depends on whether the package declares an extra.laravel section with providers and aliases in its composer.json. That detail is not evidenced in the public listing, so inspect composer.json before assuming it works. If discovery is not declared, you must register the service provider manually, which adds upgrade and maintenance friction over time.
- Which Laravel and PHP versions does perform/base-bundle support?
- The supported Laravel and PHP versions are declared in the package's composer.json illuminate and php constraints, so read that file first. Pay particular attention to whether illuminate/support is pinned narrowly to a single minor version, since that becomes an upgrade blocker for your next Laravel release. Validate everything against your own supported matrix: Laravel major version, PHP 8.x minor, Composer 2, and PSR-4 autoloading.
- Is perform/base-bundle a Symfony bundle or a Laravel package?
- The name uses Symfony lexicon, but that does not prove it is Symfony code, a port, or simply Laravel code with Symfony-style naming. This matters because Symfony-derived code may assume a container, event dispatcher, or config-cache model that maps imperfectly onto Laravel and can produce subtle boot-order issues instead of clean failures. A short source review resolves the question quickly and should happen before any integration work.
- How do I configure perform/base-bundle after installing it?
- Configuration is typically handled through published config files merged with package defaults, so check for a config directory and a mergeConfigFrom call in the service provider. Run php artisan config:cache after publishing to confirm the package behaves correctly with cached configuration, which is where many base packages break. Document any global defaults the package injects so your team knows what it is inheriting.
- Is perform/base-bundle safe to use in production?
- Treat it cautiously until you have evidence: the package has minimal public adoption, a single apparent maintainer, and no visible downstream projects proving that it resolves, boots, and survives Laravel upgrades cleanly. Low-visibility packages with few maintainers are also a supply chain concern, so confirm ownership, release history, semver tagging, CI status, and license before adopting. An isolated spike in a throwaway app is the right first step, not a direct install into a shared production application.
- Does perform/base-bundle register global helpers, facades, or middleware that could collide with my app?
- Base and umbrella packages commonly register helper functions, aliases, middleware, observers, or boot logic globally, which is exactly the kind of surface that is hard to debug in production and hard to remove later. Search the source for function declarations, class_alias calls, facade accessors, global middleware, and Blade directives. If you find global registrations, assess collision risk against your existing helpers and application middleware before rolling it out.
- Is perform/base-bundle actively maintained, and what happens if it is abandoned?
- There is no strong public signal of active maintenance: low star count, zero dependents, and no visible release cadence are consistent with an early scaffold or a publicly mirrored internal package. Confirm whether the repository is a public mirror of an internal project and whether there is a team you can hold accountable. If the release history is empty or the maintainer is unresponsive, vendor the source or plan to fork it rather than depending on upstream fixes.
- What is the safest way to evaluate and then remove perform/base-bundle?
- Start with a vendor-and-read approach: clone or pull the source into a branch and spend an hour reviewing providers, helpers, config, migrations, and middleware without installing it anywhere shared. Then install it into a throwaway Laravel app matching your exact version and verify it boots, publishes, and works with config:cache and route:cache. To remove it later, unregister any manual provider, delete published config or migration files, and drop the Composer requirement, which is far simpler if you have catalogued every global surface the package adds.