Laravel Shopify Laravel Package

Product Decisions This Supports

• Build vs. buy for the Shopify app shell. v0.5.0 makes the "build on Laravel" option materially cheaper to evaluate: composer create-project plus php artisan shopify:install and shopify:dev gets a working development-store app in two commands, so a spike can be scoped in hours rather than days. That shifts the default from "start from the Node/Remix template because it is the path of least resistance" to "start from Laravel if the team already knows PHP."
• Time-to-first-demo and time-to-first-merchant. The install-to-running flow and the shopify:dev tunnel/config automation directly affect how quickly you can put a reviewable app in front of a stakeholder or design partner. This is a roadmap-sequencing input: it makes a "thin vertical slice in a dev store" milestone realistic in week one.
• Environment and configuration strategy. The new dev/production split (shopify.app.dev.toml git-ignored, SHOPIFY_APP_CONFIG=dev, production left in shopify.app.toml, named configs like staging respected) is the package taking a position on how Shopify app configs should be managed. Adopting it means adopting that convention; the decision to make is whether your team standardizes on it or keeps its own config layering.
• Release and deployment safety. shopify:deploy with --production, --config=staging, --env=production, and explicit refusals (unlinked config, production URL still a tunnel/localhost/*.test/example.com) is a guardrail, not just a convenience. This supports a decision to let the package own the "deploy the Shopify app config" step rather than scripting it in CI yourself.
• App Store readiness and compliance posture. Automatic re-subscription to app/uninstalled, app/scopes_update, and the three compliance topics, plus webhook API-version backfill, turns a recurring source of App Store review failures into a default. This supports roadmap decisions about when to invest in submission work versus feature work.
• CI/CD and multi-environment operating model. --no-interaction implying --allow-updates, --skip-checks, --message, --app-version, --no-release, --allow-updates, --allow-deletes are the knobs that decide whether Shopify deploys live in the same pipeline as the Laravel app or in a separate, gated job.
• Billing integration sequencing. shopify:doctor now surfaces missing billing settings with links without failing, while still enforcing billing when a route uses the subscribed middleware. That lets you defer billing setup in dev without silently shipping an app that bypasses plan checks.

When to Consider This Package

Consider it when:

• You are building a Shopify app on Laravel/PHP, especially an embedded admin app, and want the scaffolding, OAuth, webhook, and CLI-config plumbing handled rather than hand-rolled.
• Your team's core competency is PHP/Laravel, and retraining on the Node/Remix Shopify template is a real cost.
• You need more than one Shopify app configuration (local dev, staging, production) and want a convention for keeping development config out of git and away from production.
• You want deployment guardrails: refusing to deploy an unlinked config or a production config pointing at a tunnel or placeholder domain is exactly the class of mistake that causes merchant-facing outages.
• App Store compliance is on the roadmap and you want the uninstall, scopes-update, and GDPR/compliance webhooks subscribed by default and restored if the CLI drops them.
• You want a CI-friendly deploy step with non-interactive behavior and explicit flags rather than a bespoke shell script.

Look elsewhere when:

• Your stack is not Laravel/PHP — the package is a thin, opinionated layer over the Shopify CLI and Laravel conventions, and there is no version of this value proposition outside that pairing.
• You need framework-agnostic or polyglot Shopify tooling, or you are standardizing on Shopify's official Node templates and want to stay on the officially supported path.
• Your app has complex deployment orchestration (multi-region, custom release trains, existing config-management systems) that would fight the package's shopify.app.toml / shopify.app.dev.toml convention.
• You only need a single environment with no staging or CI, in which case the new configuration-splitting and deploy-guard machinery is overhead relative to its benefit.
• You are already running a mature Shopify app with its own config and hook pipeline — migrating to this package's conventions is a net-new project, not an upgrade.

Note the upgrade implication for existing local setups: dev commands now target shopify.app.dev.toml unless SHOPIFY_APP_CONFIG names another config. Teams that have been developing against shopify.app.toml must copy it to shopify.app.dev.toml or re-run shopify:install. That is a one-time local migration, not a production breaking change, but it should be scheduled.

How to Pitch It (Stakeholders)

For executives: This release turns a Laravel-based Shopify app from a multi-day setup into a two-command start, and it makes releasing that app materially safer. Development configuration is now separated from production by default, and the new shopify:deploy command refuses to push a production config that still points at a tunnel, localhost, or a placeholder domain — the most common way a Shopify app breaks for live merchants. Webhook subscriptions required for App Store compliance are re-applied automatically if the Shopify CLI drops them. Net effect: lower time-to-first-demo, fewer production incidents from configuration drift, and less custom glue code to own.

For engineering: The package now owns three things previously left to scripts and discipline: (1) local setup and tunnel wiring via shopify:dev, which also repoints application_url, redirect_urls, and APP_URL at the tunnel and preserves redirect paths; (2) config hygiene via the shopify.app.dev.toml / shopify.app.toml split with SHOPIFY_APP_CONFIG and named configs; (3) release via shopify:deploy, which runs shopify:doctor, always names the configuration so the CLI cannot deploy the wrong one, enforces the environment guardrails, and passes through --message, --app-version, --no-release, --allow-updates, --allow-deletes. For CI, --no-interaction adds --allow-updates, and --skip-checks bypasses the doctor. shopify:doctor now reports missing billing settings as guidance rather than a failure, while billing enforcement via the subscribed middleware is unchanged. One caveat to communicate: locally, the dev commands now operate on shopify.app.dev.toml by default, so anyone who has been developing against shopify.app.toml should copy it across or run php artisan shopify:install once.