Laravel: Breeze as a Dev Dependency vs. Jetstream as a Production Dependency

When you start a project with Laravel Breeze you require it as a dev dependency like this:

composer require laravel/breeze --dev

But when you decide to use Laravel Jetstream for your project you have to require it as a general dependency:

composer require laravel/jetstream

The difference in dependency type between Laravel Breeze and Laravel Jetstream when using Composer is primarily due to the nature and intent behind each package.

1. Laravel Breeze:
   • Laravel Breeze is intended as a minimal, simple starting point for building a Laravel application. It's designed for developers to use as a baseline for their new projects.
   • Breeze provides a basic scaffold for authentication and is typically used during the initial stages of development. Once the scaffolding is in place, and you've run the necessary commands to publish assets and configuration, you don't rely on Breeze for much during production. Essentially, it's not actively used in your application's production environment.
   • Therefore, you can require it as a development dependency (--dev) since you're only using it during development for scaffolding. In production, you don't need Breeze itself, just the code and assets it generated during setup.
2. Laravel Jetstream:
   • Laravel Jetstream, on the other hand, is a more robust application scaffolding for Laravel, providing more complex features like two-factor authentication, session management, API support via Laravel Sanctum, team management, and more.
   • Jetstream integrates deeply with your application's logic and provides services that your application relies on while it's running in production (like the mentioned session management, security features, etc.).
   • Because these features are actively used in production, Jetstream must be included as a general (production) dependency. This ensures that its code is available in the production environment, not just during development.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com