- What is lunarphp/licensing and what does it do?
- lunarphp/licensing is the Licensing component of LunarPHP, the Laravel ecommerce stack. It adds license key management to a store: creating license keys and product licenses, issuing and validating them, and wiring licensing workflows into Lunar's models. The package published on Packagist is a read-only subtree split of the Licensing component from the main lunarphp/lunar monorepo, so the canonical source lives there rather than in this repository.
- How do I install lunarphp/licensing in a Laravel project?
- Install it with Composer using composer require lunarphp/licensing. As a Laravel package it is expected to follow the conventional shape, with a service provider registered through extra.laravel.providers, but confirm that in the manifest before assuming auto-discovery. Watch the Composer output for constraint conflicts with your existing lockfile, then run your migrations and test suite to validate the install.
- Which Laravel and PHP versions does lunarphp/licensing support?
- The published release is 0.1, and no Composer manifest details were supplied alongside it, so its php and illuminate/* constraints could not be verified during evaluation. Resolve it against your actual production versions by running composer require and reading the resulting dependency resolution rather than trusting a README. Treat any claimed Laravel version support as unconfirmed until you have seen the require block.
- Is lunarphp/licensing a standalone package or part of LunarPHP?
- It is a component of LunarPHP published as its own Composer package, so it is meant to be used alongside lunarphp/lunar rather than as a framework-agnostic licensing library. Its main advantage is that licensing data sits next to the commerce data Lunar already manages. If your application is not running Lunar, a standalone Laravel license key package is likely a simpler fit.
- Is version 0.1 of lunarphp/licensing production ready?
- Release 0.1 was published with empty release notes, so you cannot tell from the release what is included, deliberately excluded, or known to be broken. Under semver, 0.x allows breaking changes in minor bumps, so pin it exactly or with a narrow tilde constraint and budget for upgrade work on each release. Most teams should pilot it in a non-critical flow before relying on it for revenue-bearing licenses.
- Does lunarphp/licensing require database migrations or config publishing?
- Expect the usual Laravel package workflow: publish configuration and migrations with vendor:publish, then run php artisan migrate. Before touching production data, check whether the migrations are additive, creating new licensing tables, or whether they alter existing Lunar tables, and confirm they are reversible. No published documentation confirms the exact publish tags, so inspect the service provider in the source first.
- How does lunarphp/licensing integrate with Lunar models like products and orders?
- The package is described as integrating licensing workflows with Lunar models, which in practice means associating a license with the products, orders, and order lines Lunar already stores. That coupling is the main reason to choose it over a generic key generator. Because the release notes do not describe the schema, confirm the exact model relationships and any table changes during your evaluation.
- Can I customize how license keys are generated and validated?
- Customization would typically follow Laravel conventions: publish the config file and override or extend the classes that issue and validate licenses instead of editing vendor code. Since 0.1 ships without documentation, treat key format, expiry, and activation rules as things to verify in the source before designing around them. If you need bespoke rules such as seat counts or hardware binding, check whether they are supported or plan to build them on top.
- Where do I report bugs or contribute to lunarphp/licensing?
- The GitHub repository is a read-only subtree split, so issues and pull requests belong in lunarphp/lunar, the monorepo it is split from. Maintainer count, license terms, and any stated support window for 0.x should be confirmed during intake rather than assumed. For a pre-1.0 package, make the bus-factor decision explicitly before adoption.
- What should I check before adopting lunarphp/licensing in an existing store?
- First confirm you actually need licensing and that no existing subscription or entitlement feature already covers it, since duplicated capability is the most common reason Laravel packages get removed again. Then verify the Composer constraints against your PHP and Laravel versions, review the transitive dependency footprint, and check for a test suite and CI matrix covering framework version edges. If you are not on Lunar, or the package turns out to patch framework internals, prefer a lighter standalone alternative.