Weave Code
Platform Bundle Laravel Package
softspring/platform-bundle
Softspring Platform Bundle provides the shared core layer for Softspring CMS applications: common services, configuration, and integration points that let modules and extensions build on a consistent, maintainable PHP foundation.
This bundle provides external platform integration features.
Frequently asked questions about Platform Bundle
- Is softspring/platform-bundle a Laravel package?
- No. Despite being distributed on Packagist and installed via Composer, softspring/platform-bundle is a Symfony bundle, not a Laravel package. It targets the Softspring platform, which is built on Symfony, and it does not ship a Laravel service provider, facade, or config publishing workflow. If you are evaluating it for a Laravel application, treat the framework mismatch as a hard gate rather than an installation detail.
- How do I install softspring/platform-bundle with Composer?
- Installation is the standard Composer flow: add the package with composer require softspring/platform-bundle and register the bundle in your Symfony kernel or bundles.php. On a Softspring-based application it will typically already be pulled in transitively by the application skeleton. Be aware that the repository currently exposes little public documentation, so confirm the exact bundle class name and any required adjacent Softspring packages from the source before wiring it in.
- Which PHP and Symfony versions does softspring/platform-bundle support?
- The package does not publish a clearly stated compatibility matrix in its public metadata, so you should inspect the composer.json constraints directly before planning any work. Symfony bundles of this type usually track maintained Symfony releases, but that is an assumption, not a documented guarantee here. Pin the version in your composer.json and verify the resolved dependency tree in a throwaway project first.
- Can I use softspring/platform-bundle inside a Laravel application?
- Not as a library. Laravel does not boot Symfony bundles, so the bundle's services, configuration, and integration hooks will not be registered by the Laravel container. The only honest integration pattern is running a Symfony application as a sidecar behind an internal API, which turns a package decision into a new service with its own deployment, ownership, and on-call cost. That is a much larger commitment than this bundle's current adoption profile justifies.
- Does softspring/platform-bundle work standalone, or does it need other Softspring packages?
- It is described as the shared foundation layer for Softspring applications, which strongly suggests it is designed to be used alongside softspring core bundles and the Softspring application skeleton rather than in isolation. The public description does not confirm whether it boots cleanly on a bare Symfony kernel. The fastest way to find out is a timeboxed spike in an empty Symfony project: install it, boot the kernel, and see which dependencies it demands.
- What does softspring/platform-bundle actually provide?
- According to its overview it centralizes configuration and service wiring for platform modules, supplies reusable base components for common application concerns, and exposes integration hooks so third-party bundles can plug in consistently. In practice that means it is infrastructure glue for the Softspring ecosystem rather than a feature package you would adopt for a specific capability. The description names capability categories, not a specified interface, so scope any evaluation around what it wires up rather than what it does.
- Is softspring/platform-bundle production-ready, and what are the maintenance risks?
- Softspring is a real, commercially backed project, so the code is not abandoned hobbyware, but this bundle shows effectively no public adoption footprint: no stars, no dependents, and no independent maintainer pool. That means zero third-party validation and no community knowledge base when something breaks, and upstream direction follows the vendor's roadmap rather than yours. Register the single-vendor bus factor and the coupling to the parent platform's domain model as explicit risks before committing engineering time.
- How should I evaluate softspring/platform-bundle before adopting it?
- Run a timeboxed spike in a throwaway Symfony skeleton on the version you actually intend to use. Confirm the bundle installs, resolves its dependency tree without conflicts, boots the kernel, and reaches one real end-to-end path against a sandbox account if it connects to external platforms. Only after that should you assess fit against your production application, because the most likely failure mode is discovering deep coupling to Softspring's entities, repositories, or message bus after you have already scheduled the work.
- What are the alternatives to softspring/platform-bundle?
- If you are on Laravel, the native equivalents are package discovery via service providers, config publishing, and modular monolith patterns using Composer path repositories or nwidart/laravel-modules, none of which require a Symfony bundle. If you are on Symfony, the comparable approach is a small internal base bundle that you own, built on FrameworkBundle and DependencyInjection rather than on a vendor's platform conventions. Building that thin shared layer yourself is often cheaper than adopting an opaque foundation package with no public dependents.
- What license, release cadence, and commercial support terms apply to softspring/platform-bundle?
- These details are not stated in the package overview, and they matter before you build on it. Check the LICENSE file in the repository, the tagged release history on Packagist, and whether any part of the platform requires a paid Softspring tier or hosted component. If you need a stated backward-compatibility policy or purchasable support for this specific bundle, get that confirmed in writing from the vendor rather than inferring it from the surrounding product.
Weaver
How can I help you explore Laravel packages today?