- How do I install dnsimmons/openweather in a Laravel application?
- Run composer require dnsimmons/openweather and let Laravel package auto-discovery register the service provider. Then publish the config file with php artisan vendor:publish and add your OpenWeatherMap API key to the environment file referenced by that config. Because the last release dates to December 2021, run a composer require dry-run first to confirm the PHP, illuminate/support and Guzzle constraints resolve against your current stack before committing.
- Does dnsimmons/openweather support Laravel 10, 11 or 12?
- Almost certainly not out of the box. The package's final release was in December 2021, so its illuminate/support constraint will typically cap out somewhere around Laravel 8, with PHP pinned to the 7.4 or 8.0-8.1 range. Installing on Laravel 10, 11 or 12 will usually fail dependency resolution, and forcing it with platform-req overrides leaves you with an untested combination. Fork the package and widen the constraints yourself, or reimplement the calls directly.
- How do I configure the OpenWeather API key and config file?
- Publish the package config with php artisan vendor:publish, which places an openweather.php style config file in your config directory. Put the key in your .env file (commonly OPENWEATHER_API_KEY) and have the config read it through env() rather than hardcoding it. Keep separate keys per environment, never commit them, and remember to re-run php artisan config:cache after changing the value in production.
- Which OpenWeather endpoints does this package actually wrap?
- It is a thin convenience layer over the free-tier OpenWeatherMap endpoints, covering current conditions and forecast data. It does not abstract One Call 3.0, historical weather, or multi-provider failover, and it does not normalize responses into domain objects. Read the source before adopting it to confirm which API version each method targets, since OpenWeatherMap has revised its free tier and endpoint set since 2021.
- Does the package handle caching, timeouts, retries and HTTP 429 rate limits?
- Assume it does not. Thin API wrappers of this vintage typically issue a synchronous request and let exceptions escape, which means no cache layer, no explicit timeout, and no retry or backoff on 429 or 5xx responses. Wrap any call in Cache::remember with a sensible TTL, set explicit connect and total timeouts on the underlying client, and map provider failures into your own exception type so weather problems never take down a user-facing page.
- Is dnsimmons/openweather still maintained and safe to use in production?
- It is archived, single-author, low-star, and its last release was December 2021, so there are no security patches, no compatibility updates, and no upstream response if OpenWeatherMap changes its response schema. The abandoned transitive dependencies are also a supply-chain concern, since they stop receiving advisories too. For a Laravel 10+ codebase or anything with SLOs attached to weather-driven behavior, treat it as unsuitable as a live Packagist dependency.
- What are good alternatives to dnsimmons/openweather for Laravel?
- The most reliable alternative is Laravel's own Illuminate\Support\Facades\Http client calling OpenWeatherMap directly, which is roughly 50 to 100 lines including parameter mapping. Put it behind a WeatherProvider contract you own so you can swap providers later without touching call sites. A more actively maintained third-party package is also an option, but apply the same checks on release date, Laravel version support, and test coverage before adopting it.
- How do I test code that uses the OpenWeather facade?
- Never hit the live API in tests. If the package routes through Laravel's HTTP client you can use Http::fake to assert the requested URL and query parameters and to return a canned JSON payload. Otherwise mock the facade itself, or better, depend on your own WeatherProvider interface and bind a fake implementation in the container so tests do not touch the package at all. Add a test for the failure path too, since exception handling is where thin wrappers usually break.
- Can I use dnsimmons/openweather outside Laravel, for example in Lumen or plain PHP?
- It depends on illuminate/support and ships a Laravel service provider and facade, so it is effectively Laravel-only. Lumen may work if you manually register the provider and alias, but that configuration is untested and unsupported. In plain PHP or another framework you are better off calling the HTTP API directly rather than pulling in an entire Laravel support stack for a couple of GET requests.
- How do I migrate off dnsimmons/openweather or fork it safely?
- Treat the package as a reference implementation: read the source, copy the endpoint URLs and parameter shapes, and reimplement them behind an interface you own using Laravel's HTTP client with Cache::remember, explicit timeouts, and a mapped exception type. That costs a day or two more than installing it and removes the abandonment risk entirely. If a specific behavior is hard to reproduce, fork it into a packages/ directory or a private VCS repo, pin your fork, and take ownership of the composer.json constraints instead of consuming it from Packagist.