Weave Code
Email Engine Laravel Package
sfcod/email-engine
Email Engine is a Laravel/PHP package for building reusable email templates and sending transactional or bulk mail through a clean, configurable API. It helps organize layouts, content, and delivery settings so email workflows stay consistent and easy to maintain.
Email Engine is a flexible email delivery layer for Laravel that centralizes how your application composes, queues, and dispatches messages. It wraps Laravel's native mailer with a cleaner engine-style API, making it easier to manage templates, transport drivers, and delivery logic from a single place.
- Pluggable transports for swapping SMTP, API, or log drivers without touching application code
- Template-driven composition for reusable, maintainable email content
- Queued delivery to keep request cycles fast and reliable
- Centralized configuration for consistent mail behavior across environments
Frequently asked questions about Email Engine
- What is sfcod/email-engine and how does it compare to Laravel's built-in Mailables?
- sfcod/email-engine is a Laravel/PHP package for centralizing transactional email logic, managing templates, and sending mail through a reusable API. It sits on top of Laravel's normal mail stack rather than replacing it, so you still use Laravel mailers and drivers. Compared with raw Mailables, it is aimed at teams that want one place to define and reuse transactional email behavior across controllers, jobs, and services.
- How do I install sfcod/email-engine with Composer?
- Install it with composer require sfcod/email-engine, then check the published composer.json constraints before committing the lockfile. The package ships Laravel integration, so a service provider and facade are expected to be auto-discovered. If the package provides config or template publishing, run the vendor:publish command documented in its README.
- Which Laravel and PHP versions does sfcod/email-engine support?
- Based on the 1.2.0 release evidence, target Laravel 8.83+ on PHP 8.0 or 8.1 with Symfony 5.4 components. That aligns the package with Laravel 8.x's Symfony ^5.4 constraint. Laravel 6/7 and PHP 7.x are likely excluded, so confirm the exact php and symfony requirements in composer.json before upgrading.
- Is sfcod/email-engine compatible with Laravel 9 or Symfony 6?
- Probably not with the current 1.2.0 line: it aligns to Symfony 5.4, while Laravel 9 moved to Symfony 6. Unless a newer release widens or raises the constraint, expect Composer to block installation on Laravel 9+. Treat Symfony 6 support as a separate migration milestone and verify against the package's composer.json and CI matrix.
- Why does installing sfcod/email-engine 1.2.0 break dependency resolution on older Laravel apps?
- Version 1.2.0 tightens the Symfony floor to 5.4, which can collide with packages still requiring Symfony 4.4, 5.2, or 5.3. Run composer why-not sfcod/email-engine 1.2.0 and composer update sfcod/email-engine --with-dependencies --dry-run in the target app to see the conflict before touching the lockfile. On Laravel 6/7 or early Laravel 8, pin ^1.1 explicitly because ^1.0 can pull 1.2.0 automatically.
- How should I configure sfcod/email-engine for transactional emails?
- Configuration should stay close to Laravel's normal mail setup: choose your mailer and driver via config/mail.php and environment variables, then register transactional templates with the engine. Publish any package config with vendor:publish if the package exposes one. Keep credentials out of code and use Laravel's env configuration so local, staging, and production can differ.
- Can I test transactional emails from sfcod/email-engine without actually sending them?
- Yes. Because the engine sends through Laravel's mail layer, you can use Mail::fake() and the standard assertSent and assertQueued assertions in feature tests. For local or CI runs, set MAIL_MAILER to log or array so nothing leaves the environment. Add at least one test per transactional template to catch missing variables and rendering errors.
- What production risks should I consider before adopting sfcod/email-engine 1.2.0?
- The main production risks are dependency resolution and an implicit BC break: 1.2.0 drops installability on older Symfony/Laravel stacks even though it is a minor version. Symfony 5.3 to 5.4 also carried deprecations and small behavior changes that may surface through proxied components. Before merging, diff 1.1.x to 1.2.0, dry-run the update, and run the application's full test suite. If you are not on Laravel 8.83+, stay on 1.1.x and pin it.
- How should I manage transactional email templates with sfcod/email-engine?
- The package is intended to centralize template management, so define transactional templates once and render them through the engine rather than scattering Blade strings across the codebase. Keep templates in version control, pass a documented data contract per template, and test rendering with representative payloads. Check the package README for the exact template path and naming conventions before standardizing on them.
- Is sfcod/email-engine actively maintained, and what alternatives exist for Laravel transactional email?
- Maintenance signals are thin: the only visible evidence is a one-line changelog for 1.2.0 noting the Symfony 5.4 update. That suggests the maintainer is tracking framework cadence, but the low-ceremony release note makes upgrade documentation a risk. Alternatives include Laravel's built-in Mailables, Notifications, Blade or Markdown mail templates, and provider-hosted templates from services such as Postmark, Mailgun, or SendGrid. Review the GitHub releases, CI matrix, and recent commit activity, and keep an explicit version pin so an unexpected minor release cannot change your dependency floor.
Weaver
How can I help you explore Laravel packages today?