- How do I install chiiya/laravel-passes in a Laravel application?
- Install it with Composer and publish the package config using Laravel's vendor:publish command. It assumes a full Laravel runtime, including the container, config, facades, and storage, so it is not a standalone library. After publishing, plan your Apple and Google credential configuration before generating passes.
- What Apple and Google credentials are required to generate Wallet passes?
- Apple requires a Pass Type ID certificate (.p12 plus its password) and the Apple WWDR intermediate certificate. Google requires a service-account JSON with the Wallet API enabled and an issuer ID. Treat these as secrets, separate them per environment, and have a rotation runbook.
- Does chiiya/laravel-passes support Laravel 13?
- Version 1.2.0 adds Laravel 13 support, but you should verify composer.json actually permits laravel/framework ^13.0 and check whether PHP or illuminate/* constraints shifted. The assessment flags as an open question whether support is additive or drops older majors. If you are on Laravel 11 or 12, this is forward-looking de-risking rather than an immediate reason to adopt.
- Can I use chiiya/laravel-passes without Laravel?
- No. The package depends on a full Laravel runtime such as the container, config, facades, and storage, so it is not usable standalone. That rules it out for any non-Laravel consumer you might add later. Keep it behind a Laravel service boundary if portability matters.
- How should I structure Wallet pass generation in my app architecture?
- Treat it as a leaf dependency in an outbound artifact service, with a WalletPassService in your domain layer owning template data, signing material references, and delivery links. Do not let pass generation leak into controllers or models. Wrap the produced Apple pass JSON and Google JWT/save URL behind your own interface so you can swap implementations.
- Does the package create both Apple and Google Wallet passes from one template?
- The package wraps both Apple .pkpass and Google Wallet construction and distribution behind a fluent builder API. The assessment lists as a key question whether you can define both from the same template model or need parallel definitions. Verify that during your spike before designing shared templates.
- What changed in chiiya/laravel-passes 1.2.0 and is it a breaking upgrade?
- 1.2.0 is effectively two functional items, Laravel 13 support and a Google-domain typing fix, plus Dependabot bumps to GitHub Actions only. No breaking changes are announced and the version bump is minor. Inspect the Google generic class/object change for public property or return type changes before upgrading, especially if you subclass the Google domain model.
- How do I test Wallet pass generation in Laravel?
- The assessment does not describe package-specific test helpers, so plan to test your WalletPassService boundary rather than asserting on raw pass serialization. Fake or inject signing material references and delivery-link generation, then verify the Apple pass payload and Google save URL through your own interface. Keep a small integration test that exercises real credential loading in a non-production environment.
- How do I handle Apple certificate rotation and secret management in production?
- Plan per-environment Apple certificates, secrets management, and a rotation runbook from day one. The assessment specifically asks whether the package documents an upgrade path for Apple certificate rotation and WWDR intermediate expiry, so do not assume it handles that for you. Google service-account credentials need the same rotation discipline.
- What are the maintenance and long-term risks of adopting chiiya/laravel-passes?
- It is a single-maintainer project, with a contributor's first PR in 1.2.0 and Dependabot maintaining CI, which is a positive signal but still a concentration risk. The bigger long-term exposure is credential and spec drift as Apple and Google change pass formats and signing requirements. Confirm the maintainer's Laravel support policy and security contact before building deeply on the package.