th3mouk/yahoo-weather-api
A lightweight Laravel/PHP wrapper for the Yahoo Weather API that helps you fetch current conditions and forecasts by location, with simple configuration and facade-style access for quick integration into your application.
Read this first: the repository is archived (last release 2016-09-27) and has zero dependents. More importantly, the Yahoo Weather API it wraps (YQL weather.forecast / weather tables) was retired in 2019. There is no live upstream to call, so "day-to-day" usage means either (a) treating the package as a reference implementation you fork/point at another endpoint, or (b) not using it at all. Confirm that decision before you spend time on integration.
If you still want to evaluate it locally:
Install and inspect the constraints.
composer require th3mouk/yahoo-weather-api
There is no ^1.0-style maintained line; you'll likely land on the 2016 tag or dev-master. Immediately open vendor/th3mouk/yahoo-weather-api/composer.json and check the php and guzzlehttp/guzzle constraints — these are the two things most likely to block installation in a modern Laravel app (PHP 8.x and Guzzle 7).
Look here first, in order:
README.md — the only real usage documentation; shows the WOEID-based lookup flow and the shape of the returned objects.src/YahooWeatherAPI.php (or similarly named client class) — the entry point. This is where the base URL/YQL query lives, and therefore where you'd have to intervene to repoint it.src/Model / src/Entity — the value objects (Weather, Location, Forecast, etc.) that responses are hydrated into.tests/ — if present, they double as executable documentation of expected response shapes.Know what it is not. This is a framework-agnostic PHP library. There is no Laravel service provider, no facade, no config file, and no auto-discovery. You will wire it up yourself.
First use case to aim for: current conditions plus an N-day forecast for a single, hard-coded WOEID (e.g. London 44418), cached for 15–30 minutes, rendered in a controller or a Blade view. Don't start with multi-city or geocoding — WOEID resolution is a separate problem (see Gotchas).
A minimal manual wiring looks like:
// app/Providers/WeatherServiceProvider.php
public function register(): void
{
$this->app->singleton(WeatherClient::class, function () {
return new \Th3mouk\YahooWeatherAPI\YahooWeatherAPI(); // adjust to actual constructor
});
}
…then resolve it in a controller and map the returned objects into your own DTOs.
Wrap it behind your own contract. The single most valuable thing you can do with an archived dependency is ensure nothing in your application references its classes directly. Define App\Contracts\WeatherProvider with methods like current(string $woeid): CurrentWeather and forecast(string $woeid, int $days): Collection, implement it with an adapter around this package, and bind the interface in a service provider. Swapping to OpenWeatherMap, WeatherAPI.com, or a direct Http::get() later becomes a one-line binding change instead of a codebase-wide refactor.
Cache every response. Yahoo historically enforced strict per-IP/app rate limits and returned 429/empty results under load. Even in a hypothetical working setup, weather data doesn't change fast enough to justify a network call per request. Cache at the provider-adapter level:
return Cache::remember("weather:{$woeid}:{$days}", now()->addMinutes(20), function () use ($woeid, $days) {
return $this->client->getForecast($woeid, $days);
});
Prefetch out-of-band with a scheduled command. For anything user-facing, don't call the API in the request cycle at all. Create an artisan command (weather:refresh) that iterates your tracked locations, fetches, and writes normalized rows into a weather_snapshots table or cache keys. Schedule it every 30–60 minutes in routes/console.php / Kernel::schedule(). This gives you latency isolation, a natural place for retry/backoff, and something to debug that isn't a live HTTP call.
Normalize on ingest, not on read. The package hydrates into its own model objects. Convert immediately at the adapter boundary into your own DTOs/Eloquent models — including unit conversion — so your views and API resources never touch Th3mouk\... types. This also means the archived package's quirks (nulls, string-typed numerics) stay contained.
Bind a fake in tests. Because everything goes through your interface, feature tests can bind a FakeWeatherProvider returning fixtures. Never let the test suite depend on an archived client hitting a dead endpoint — otherwise CI is either red for the wrong reason or silently testing nothing.
Treat it as a reference for response-shape mapping. If you're reimplementing against a live provider, the model classes are still a reasonable catalogue of what a weather payload contains (condition code, temp, humidity, wind, forecast day list, atmosphere/astronomy sub-objects). Steal the structure, not the transport.
Guzzle RequestException or, worse, a null/partially-hydrated object if error handling swallows it.guzzlehttp/guzzle:^7.0 requirement and either fail resolution or force downgrades elsewhere. Check composer why-not guzzlehttp/guzzle 7.* if install blows up.config/yahoo-weather.php — it doesn't exist, and there's nothing to publish.200 OK body (results: null, diagnostics), and library versions of this era often just returned an empty forecast collection rather than throwing. Add explicit "did I get a non-empty forecast?" checks in your adapter and log the raw payload on miss.cacert bundles are a classic source of cURL error 60. If you're resurrecting this for a spike, that's the first thing you'll hit after the dead endpoint.Http facade against a live provider (OpenWeatherMap, WeatherAPI.com, Meteoblue, or a self-hosted Open-Meteo) with the interface-adapter + cached-command pattern above — it's roughly 100 lines and you keep PHP 8/Guzzle 7 compatibility, active maintenance, and an API that actually responds. This package's only durable value is as a field guide to the shape of weather data.How can I help you explore Laravel packages today?