Weave Code
Laravel Weather Laravel Package
vemcogroup/laravel-weather
Laravel Weather offers a simple, fluent interface for retrieving current weather and forecasts from multiple providers in Laravel. Configure providers, units, and caching, then add reliable weather data to controllers, views, or scheduled tasks with minimal setup.
Weather package for Laravel to use different providers to get weather info
Frequently asked questions about Laravel Weather
- Which Laravel and PHP versions does vemcogroup/laravel-weather support?
- The package installs via Composer with standard Laravel package auto-discovery and ships a publishable config file. Check the composer.json constraint range in the tagged release you plan to use and confirm it matches your runtime before committing, since an unmaintained PHP or Laravel constraint ceiling is the most common reason packages like this get removed later. Pin the version in your lockfile and re-verify constraints at each framework upgrade.
- How do I install and configure laravel-weather in a Laravel app?
- Require the package with Composer, publish the config file, and set your chosen provider plus its API credentials. No database migrations, queue workers, or persistent state are involved, but the runtime does need outbound HTTPS to reach the provider. A sandbox smoke test is realistically a half-day; hardening the integration with caching, fallback, and observability takes longer.
- Which weather providers does laravel-weather support?
- The package exposes multiple provider drivers behind a single uniform call surface, typically current conditions, forecasts, and geocoding helpers where the driver supports them. Capability coverage is not perfectly uniform across providers, so historical data, air quality, and geocoding may not be available everywhere. Check the README and driver source for the exact provider list in your version.
- How do I switch weather providers without changing application code?
- Provider selection lives in the package config, and the Weather facade plus the driver contract stay the same, so switching vendors is normally a config change rather than a refactor. That only holds if you constrain yourself to the common subset of capabilities shared by the drivers you use. Anything provider-specific will leak into your code and needs to stay behind your own wrapper.
- Does the package cache weather API responses?
- Assume caching is your responsibility: this is a thin orchestration layer that does not ship its own HTTP client or retry policy beyond what Laravel's HTTP client offers. Wrap calls in Laravel's cache or your own WeatherService layer and pick a TTL that matches how often the upstream data actually changes. Caching also protects you from provider rate limits on high-traffic pages.
- How do I get a multi-day forecast with the Weather facade?
- Call forecast on the Weather facade using a resolved driver, and it returns DTO-style result objects rather than raw arrays, which keeps output consistent across providers. Forecast horizon and available fields vary by driver, so validate what your chosen provider actually returns. For anything beyond the common subset, normalize inside your own service layer.
- Can I add a custom weather driver for an internal gateway or unsupported provider?
- The architecture follows Laravel's Manager family pattern, the same shape as the Cache, Filesystem, and Mail managers, so a custom driver is the natural extension point. Confirm the driver contract in the source for your installed version before betting on it, because it is not guaranteed to be a documented public API. This matters if you plan to route calls through an internal caching proxy or a vendor not yet supported.
- How does laravel-weather handle API errors and provider failures?
- Verify the error surface in the source: you want typed exceptions you can catch rather than generic HTTP errors leaking out of the driver. The package does not add retry policy beyond Laravel's HTTP client, so resilience, backoff, fallback providers, and alerting are yours to implement. Plan for upstream deprecations too, since providers change endpoints and response schemas with little notice.
- Can I test code that uses the Weather facade without live API calls in CI?
- Yes, as long as you fake the driver or the underlying HTTP client so no outbound requests are made. Check whether the package's own tests mock provider responses, since that indicates how trustworthy its CI story is. In your app, keep weather calls behind an injected interface so tests can swap in a stub implementation.
- Is vemcogroup/laravel-weather actively maintained, and what are the alternatives?
- It is a small package with roughly 55 stars and a single organizational maintainer, so treat it as adopt-with-an-owner rather than adopt-and-forget. The MIT license means you can fork it if upstream goes quiet, but budget for that possibility and pin your lockfile. The main alternatives are calling provider SDKs directly or building a thin internal WeatherService that wraps this package, which also lets non-Laravel runtimes consume weather over HTTP.
Weaver
How can I help you explore Laravel packages today?