Weave Code
Sdk Kernel Laravel Package
wxm/sdk-kernel
wxm/sdk-kernel is a lightweight foundation for building Laravel and PHP SDKs, offering shared contracts, configuration, service-provider bootstrapping, and a thin HTTP layer so client packages stay consistent, testable, and easy to integrate.
SDK kernel for php
Frequently asked questions about Sdk Kernel
- What is wxm/sdk-kernel used for?
- wxm/sdk-kernel is a lightweight foundation for building PHP and Laravel SDKs. Instead of reimplementing the same base client, configuration resolution, service-provider bootstrapping, and HTTP plumbing in every client package, you extend a shared kernel so each SDK stays consistent. It is infrastructure for producing SDKs, not an SDK for a specific vendor API, so it pays off when you maintain several first-party or generated clients. If you only ship one integration, a kernel mostly adds indirection.
- How do I install wxm/sdk-kernel with Composer?
- Run composer require wxm/sdk-kernel and let Composer resolve it against your existing dependency tree. The package is MIT licensed and the surface area is expected to be small, so installation itself is mechanically simple. Because the project has no dependents yet, check the resolved version and commit the lockfile so your SDK builds stay reproducible. If you use Laravel, verify whether a service provider is auto-discovered or must be registered manually.
- Does wxm/sdk-kernel require Laravel or work with plain PHP?
- The package is described as a foundation for both Laravel and PHP SDKs, and it includes service-provider bootstrapping, which is Laravel-specific wiring. Whether the core client is framework-agnostic depends on the actual public API surface, so audit the source for Illuminate imports versus PSR-7 or PSR-18 interfaces before you commit. If you need an SDK that external developers can consume outside Laravel, confirm the transport and contracts are PSR-based. That audit is one to two days of reading, and it determines how portable your SDK can be.
- How does wxm/sdk-kernel help when building a Laravel SDK package?
- It centralizes the recurring parts of an SDK: configuration precedence, base-URL and auth-header handling, request and response plumbing, error normalization, and service-provider registration. Downstream SDKs then extend or compose the kernel instead of duplicating retry logic and error taxonomies, which are common sources of defects in hand-rolled clients. The tradeoff is control: a kernel is framework-shaped, so it dictates how every dependent SDK is structured. Adopt it when you have a portfolio of clients, not a single integration.
- Which Laravel and PHP versions does wxm/sdk-kernel support?
- The package documentation does not publish a supported-version matrix, so read composer.json for its php and illuminate constraints before adopting. Confirm it runs on the PHP versions you deploy, typically 8.1 through 8.4 for current Laravel releases, and that its Laravel constraint matches your framework version. With no dependents and no release history, there is no de facto compatibility testing, so add your own CI job that installs the lowest and highest supported versions. Treat any minor-version bump as a potential break until the maintainer establishes a semver track record.
- How do I configure credentials and base URLs in an SDK built on wxm/sdk-kernel?
- The kernel handles configuration resolution and shared contracts, so your SDK typically publishes a config file and resolves values through the kernel's precedence rules rather than reading env() directly. In Laravel that usually means a publishable config file plus a service provider that merges defaults and binds the client. Keep secrets in environment variables or a secrets manager, not in the published config, and never log the resolved auth headers. Because the contract is undocumented, read the source to confirm how precedence works before shipping.
- How do I test an SDK built on wxm/sdk-kernel?
- Test at two levels: unit tests for configuration resolution and error mapping, and integration tests that exercise the HTTP layer against fake responses. In Laravel, Http::fake() covers an Illuminate-based transport; for a PSR-18 or Guzzle-based transport, use a mock handler or a PSR-18 test client. The kernel's shared contracts make it easier to swap a fake transport into downstream SDKs, which is a real testing benefit. Run the suite in CI against the lowest and highest PHP and Laravel versions you claim to support.
- Is wxm/sdk-kernel production-ready?
- Treat it as unproven: it has zero stars, zero dependents, and a single maintainer, so there is no external security review and no community-tested edge cases. A kernel sits underneath every SDK you build, which makes abandonment and semver drift unusually costly. For an internal accelerator where you are prepared to co-maintain the code, that can be acceptable. For a customer-facing artifact, audit the source, pin the version, and have a fork-and-own plan before shipping.
- Should I use wxm/sdk-kernel or just use Guzzle or Saloon directly?
- If you are building one integration, use Guzzle or Saloon directly; both are mature, widely adopted, and lower risk with equal capability. A kernel only earns its indirection when you maintain five or more SDKs and want shared retry, auth, configuration, and error taxonomy across all of them. Even then, compare it against owning a small internal base client, which gives you the same amortization without depending on an unadopted third-party package. The decision is architectural, not a library pick.
- What happens if wxm/sdk-kernel is abandoned, and how do I mitigate it?
- With bus factor one and no organizational backing, abandonment is the dominant risk. Mitigate it up front: vendor or fork the repository, pin an exact version in composer.json, and keep an internal mirror so a Packagist removal cannot break your builds. Because the package is MIT licensed and thin, taking ownership is feasible, but budget for it as co-maintenance rather than assuming upstream fixes. Do a source audit before adoption so you know exactly what you would be inheriting.
Weaver
How can I help you explore Laravel packages today?