Statamic Weather Addon Laravel Package

Product Decisions This Supports

• Icon-system standardization: v2.0.2 adds Phosphoricons as a supported mapping for weather symbols. This is a presentation-layer feature, not a functional one — it expands the set of design systems we can target without writing our own condition-to-glyph translation tables.
• Design-system migration / consolidation: If we are standardizing on Phosphor across our front-end (or planning to), this release removes a blocker for adopting the package in weather, forecast, or dashboard surfaces. If we are on Heroicons/FontAwesome, it is a "nice to have," not a decision driver.
• Build vs. buy: The package's value is the maintenance of weather-condition taxonomies and their mapping to icon families. Each release like this is evidence the maintainer is keeping pace with ecosystem icon sets — a signal on maintenance health, and a reason to prefer this over a hand-rolled enum + Blade component.
• Roadmap input: Treat icon-family coverage as a checklist item for any weather UI epic (current conditions, hourly/daily forecast, alerts, air quality). Phosphor coverage closes one gap; verify the coverage is complete for the condition set we actually render (day/night variants, severe-weather codes, precipitation types) before committing to it in design specs.
• Low-risk upgrade: Patch-level release with an additive mapping. No migration, config, or API surface implied by the notes — safe to slot into a routine dependency bump.

When to Consider This Package

Consider adoption when:

• We need to render weather conditions as icons in a Laravel app and want a maintained mapping rather than a bespoke switch statement or enum method.
• Our design system is Phosphor (now supported), or one of the previously supported families, and we want to avoid a translation layer between weather codes and our icon set.
• We want the provider-agnostic condition vocabulary — the package absorbs upstream weather API naming differences so our views don't.

Look elsewhere or hold when:

• We have already invested in an internal icon mapping, or our design system is not among the supported families — the mapping's value collapses to a thin wrapper we could own in an afternoon.
• Icon rendering is trivial in our context (e.g., a single "sunny/rainy" toggle) — the dependency cost exceeds the benefit.
• We require guaranteed, documented coverage of severe-weather or regional condition codes; the release note describes only that a mapping was added, not its completeness. Validate against our real condition inventory before relying on it.
• We need a stable, long-term API contract — v2.x implies there was a breaking v2.0.0; confirm our version constraint strategy and check the v2.0.0 changelog if upgrading from v1.

How to Pitch It (Stakeholders)

For executives: A routine patch release (v2.0.2) to a Laravel weather package we are evaluating. It adds support for the Phosphoricons icon set when rendering weather symbols. No breaking changes, no operational impact. It mildly increases the package's fit if our design system is Phosphor, and is otherwise neutral — useful mainly as a maintenance-health signal that the maintainer is actively tracking the icon ecosystem.

For engineering: Additive mapping for Phosphoricons; expect a new icon-family mapping entry alongside the existing ones. No changes to public APIs, config, or data structures are implied by the release note. Confirm the mapping is registered in the package's config/service provider and that the condition coverage includes any custom or severe-weather codes we surface. Upgrade is a standard patch bump; pin as usual and smoke-test the weather views.