- What is juststeveking/sdk-tools and what problem does it solve?
- It is a small, framework-agnostic set of PHP primitives for authoring API client SDKs: an abstract Sdk class, Resource classes, a connector/transporter abstraction, and response caching. It removes the repetitive plumbing of defining endpoints, mapping responses, and wiring an HTTP client so you can ship consistent SDK packages faster. It is not an HTTP client itself, so you still bring your own PSR-18 implementation such as Guzzle or symfony/http-client.
- Is juststeveking/sdk-tools a Laravel package?
- No. It ships no service provider, no package auto-discovery, no facade, and no publishable config, so Laravel never bootstraps anything on its own. Its intended home is a dedicated SDK repository or an internal service-client layer, and you register the resulting SDK wrapper in your own service provider if you happen to use Laravel. Dropping it directly into controllers, jobs, or business-domain code is an anti-pattern.
- Which PHP and Laravel versions does it support?
- Its dependency constraints date from a July 2023 release, so the safest assumption is that it targets PHP 8.x-era tooling rather than the newest Laravel majors. Verify with composer why-not or a dry-run install against your current baseline before committing, because a stale constraint could block an unrelated PHP or Laravel upgrade. If it conflicts, a fork with loosened constraints is usually cheaper than waiting for an upstream bump.
- How do I install juststeveking/sdk-tools?
- Install it with Composer using composer require juststeveking/sdk-tools. Installation itself is trivial; the real work is choosing a transport, building the SDK wrapper, and registering it in your application. Run a dry-run install first so you can see exactly which transitive dependencies it pulls in.
- Do I need to install Guzzle or another HTTP client separately?
- Yes. The package deliberately ships no transport, so you must select and bind a PSR-18 client yourself, with Guzzle and symfony/http-client being the common choices. That is a feature rather than an oversight, because it keeps the SDK free of a hard HTTP dependency. Confirm early whether the shipped transporter implements PSR-18 or a bespoke interface, since that single answer determines your swap path and exit cost.
- How do I test an SDK built with these tools?
- Laravel's Http::fake() will not intercept these calls out of the box, because the package works at the PSR-18 level rather than through the Laravel HTTP client. Inject a mock PSR-18 client into your transporter and assert on the outgoing requests and canned responses instead. Treat it as a skill the team learns once and then reuses across every SDK you build.
- How does response caching work in juststeveking/sdk-tools?
- Response caching is one of the built-in primitives, so you can cache API responses at the SDK layer instead of hand-rolling it inside each client. Because the package is framework-agnostic, you supply the cache implementation and TTL strategy yourself. Review it against your data-sensitivity rules before enabling caching on authenticated endpoints.
- What are the alternatives to juststeveking/sdk-tools?
- Saloon is the best-known Laravel-oriented option and offers a richer connector/request model with first-class testing helpers. The Laravel HTTP client directly, or a roughly 200-line internal layer, are the other realistic baselines. The question to answer is whether the delta over those is genuinely worth a dependency your team must maintain indefinitely.
- Is it production-ready, and who maintains it?
- The codebase is small and MIT-licensed, so exit risk is low: a fork is an afternoon rather than a project. The real risk is ownership, since it has a single maintainer and effectively zero dependents, which means no production validation of the patterns at scale. Write a fork-and-own plan with a named internal owner before it lands in a composer.json.
- How should I handle 4xx and 5xx errors with this package?
- The error semantics, meaning whether failures throw or return, are not clearly pinned down, which matters if they leak into a public SDK contract you later cannot change. Normalize errors at an adapter boundary, such as an SdkClient/Transporter wrapper, so the upstream behaviour stays internal. If the adapter cannot absorb it without a fork, that fork cost belongs in the adoption decision.