- What is winter/storm used for?
- Winter Storm is the core support library behind Winter CMS, packaging battle-tested Laravel extensions into a reusable toolkit. It provides the plugin and module system with manifest-driven registration and dependency resolution, extended Eloquent behaviors such as sortable, sluggable, nestable and revisionable models, and an asset pipeline for LESS/SCSS compilation. It is a framework layer on top of Laravel, not a single-purpose utility package.
- Can I use winter/storm standalone in a plain Laravel application?
- It is described as working standalone in any Laravel app, but Storm assumes a Winter or October-style container, provider registration and facade conventions, and booting it inside plain Laravel is not a documented path. The static helpers such as PathResolver and Filesystem should work once autoloaded, while Halcyon, Argon and the database model extensions are where the container assumptions live. Prove it in a spike before committing to it.
- Which PHP and Laravel versions does winter/storm support?
- Storm's constraints track the Winter CMS roadmap, with Laravel 10 and 11 plus PHP 8.1 or newer as the expected range, but verify this against the actual composer.json before you commit. Because the constraints follow the CMS release cadence, a Laravel major bump can force a Storm bump that changes helper behavior you rely on. Pin the version you validate and re-check it on every upgrade.
- How do I install winter/storm with Composer?
- Run composer require winter/storm and let Composer resolve its Laravel and Symfony dependencies, which include console, finder, process, yaml, string, http, mailer and mime. Check whether its composer.json autoloads global helper function files, because a function name collision with your own code is a fatal boot error in every environment. Register the appropriate service provider only after confirming it does not add facades or aliases that clash with yours.
- Is winter/storm a good fit for a typical Laravel SaaS application?
- Usually not. Adopting Storm means inheriting CMS domain abstractions such as themes, plugins, behaviors, Halcyon file-backed models and Argon asset compilation, none of which a standard SaaS needs, and it couples your release cadence to a CMS. The pragmatic middle ground is to vendor only the security-hardened path and filesystem core if that is all you actually need. Treat adopting Storm and vendoring the path helpers as two separate roadmap items with very different costs.
- What are Halcyon and Argon in winter/storm?
- Halcyon is Storm's file-backed model layer, which lets you define models against flat files rather than database tables. Argon is the asset compilation and caching pipeline used for LESS and SCSS compilation, combining and minifying assets. Both are substantial subsystems with container coupling, so evaluate them as frameworks rather than as drop-in utilities.
- How does the winter/storm plugin and module system handle dependencies?
- Storm provides manifest-driven registration for plugins and modules with dependency-aware loading, so each extension declares what it needs and Storm resolves the load order. It also exposes event-driven hooks for extending behavior at runtime. This is the machinery Winter CMS's modular architecture is built on.
- Is winter/storm secure, and what about the PathResolver path traversal advisory?
- A path-containment defect in PathResolver::within() involving separator boundaries and prefix collisions, tracked as GHSA-58fp, was fixed by the project, and the maintainers publish advisories. That is a positive signal and a good reason to prefer the canonical implementation over a homegrown path helper. An outdated pin, however, leaves a live path-traversal risk, so pin the fixed version and monitor Winter's advisory stream.
- Does winter/storm have a large user base outside Winter CMS?
- The standalone consumer base is effectively nil. Packagist reporting zero dependents is most likely an artefact of Winter's own manifest depending on Storm, not evidence of health, and roughly 51 GitHub stars means there is no external bug-finder pool beyond Winter's own maintainers. Factor that concentration risk into your support and semver expectations.
- What should I check before adding winter/storm as a dependency?
- Decide whether you need only PathResolver and Filesystem or the full Halcyon, Argon and database model extensions, because that changes the effort from roughly one engineer-day to a multi-week framework marriage. Confirm Storm boots cleanly on your Laravel version without Winter's application class, and whether it registers facades or aliases that collide with yours. Ask Winter about semver guarantees, security backports to older lines and patch timelines for standalone consumers, and verify whether any non-Winter project runs it in production.