- What is vanilo/support used for in a Laravel application?
- It is the shared utility layer for the Vanilo e-commerce suite, providing common contracts, helpers, traits, and base classes used by higher-level Vanilo packages. It is not a standalone feature or storefront capability; its value appears only when the packages that depend on it are installed. Treat it as internal plumbing for a Vanilo-based build.
- Can I install vanilo/support by itself?
- You can install it with Composer, but doing so in isolation gives you no product surface and usually signals a misunderstanding of its role. The intended path is to adopt the Vanilo metapackage or vanilo/framework and let vanilo/support arrive transitively. Only consider it directly if you are building Vanilo-integrated packages and have a specific need.
- Which Laravel and PHP versions does vanilo/support support?
- The supported matrix is defined by the package's Composer constraints and follows the Vanilo suite's release line. Verify PHP and Laravel constraints against your deployment target before committing, because the suite's shared constraint can be tighter than your application's. After Laravel major releases, availability depends on upstream Vanilo updates.
- How do I install vanilo/support in a Laravel project?
- Install Vanilo through its metapackage or vanilo/framework rather than requiring vanilo/support explicitly. Composer will pull vanilo/support transitively along with the rest of the aligned Vanilo packages. Pin all Vanilo packages to the same minor line to avoid mixed-version breakage.
- Do vanilo/support helpers collide with Laravel helpers or symfony/polyfill?
- Before adding it to an app that already uses global helper libraries, check whether the helpers are namespaced and function-guarded. Helper and trait packages can cause collisions when they define global functions without guards or when multiple packages provide similar utilities. Confirm compatibility with symfony/polyfill and any existing helper package during evaluation.
- Does vanilo/support follow semantic versioning with other Vanilo packages?
- Its release cadence is dictated by the Vanilo suite, so treat version alignment as a suite-level concern rather than a package-level one. Pin all Vanilo sub-packages to a single aligned minor line; mixed-version packages are the most likely source of runtime breakage. There is no broad public API guarantee, so avoid coupling custom code to internal helpers and traits.
- What are the production risks of depending on vanilo/support?
- Direct risk is low: the package is MIT-licensed, small in surface, and does no I/O. The real risks are second-order: roadmap dependence on Vanilo, potential API instability in helpers and traits, and a small community with limited external scrutiny. Pin versions, test upgrades, and treat helper internals as unstable.
- Is vanilo/support actively maintained and who supports it?
- It is maintained as part of the Vanilo project, so its roadmap and release cadence follow the suite rather than an independent maintainer schedule. Star counts and recorded dependents understate usage because its consumers are other Vanilo packages, but they still indicate a small ecosystem and bus-factor exposure. Confirm whether Vanilo's support model is community-based or commercial before relying on it.
- What are alternatives to vanilo/support?
- There is no meaningful drop-in alternative because its consumers are Vanilo packages expecting its contracts and traits. Alternatives mean choosing a different Laravel e-commerce stack or writing your own shared utility layer for a custom build. For a non-Vanilo application, Laravel's own support utilities plus your own base package are the sensible route.
- How should custom packages integrate with Vanilo without coupling to vanilo/support?
- Depend on Vanilo's contract or abstraction packages rather than the helper package, and avoid reaching into internals that are implicitly private. Keep custom integrations on documented public APIs and test them against the same aligned Vanilo minor line you deploy. This reduces the chance that trait or helper changes silently break your code.