User Bundle Laravel Package

Product Decisions This Supports

• Transactional email deliverability as a product surface. v1.1.7 adds proper HTML markup to the HTML part and a genuine text/plain alternative for activation and password-reset emails. This is a multipart/alternative hygiene fix that directly affects whether new-user activation and account-recovery messages land in the inbox versus spam/promotions. That makes it a funnel decision, not a cosmetic one: activation email placement gates onboarding completion, and reset email placement gates recovery and support load.
• Build vs. buy for the auth lifecycle. The package owns a narrow, well-understood slice — account activation and password reset messaging. Adopting it is a "buy" decision for templated, framework-native auth mail, letting the team avoid maintaining hand-rolled Mailable classes, Blade templates, and token plumbing that are easy to get subtly wrong (expiry, single-use tokens, URL signing).
• Roadmap input for onboarding and retention work. If activation-email spam placement is a suspected cause of drop-off, this release is the cheapest possible experiment: upgrade, measure activation completion rate and reset-request-to-completion rate, then decide whether to invest further (custom domain warm-up, SPF/DKIM/DMARC, dedicated sending infrastructure).
• Vendor/maintenance risk tracking. A patch release that only touches email templates is a signal of a maintained but low-velocity package — good for stability, worth noting if your roadmap depends on the maintainer shipping larger capabilities (MFA, passwordless, localization).
• Compliance and accessibility adjacencies. A real text part improves accessibility and gives a fallback for clients and gateways that strip HTML; it also reduces the "HTML-only marketing-style email" signals that some filters penalize.

When to Consider This Package

Consider it when:

• The product is a Laravel/PHP application already using framework-native auth, and you want activation and reset flows to stay inside your codebase rather than in a third-party identity provider.
• You need branded, self-hosted transactional auth email with control over copy, templates, and sending domain — for example when legal, localization, or white-labeling requirements rule out a hosted auth vendor's fixed templates.
• You have observed or suspect deliverability problems in onboarding or account recovery (low activation completion, high reset-request abandonment, spam-folder reports). The v1.1.7 multipart fix is a low-cost first lever.
• Your team is small and the alternative is maintaining bespoke auth mail templates that nobody owns and that drift from best practice.
• You want a patch-level, non-breaking upgrade — this release requires no migration, no API changes, and no template rewrites on your side.

Look elsewhere when:

• You are on a hosted identity platform (Auth0, Cognito, Firebase Auth, Clerk) that already owns activation and reset messaging; duplicating it in-app creates split ownership of the user lifecycle.
• You need advanced authentication — MFA/WebAuthn, passwordless/magic links, enterprise SSO/SAML, adaptive risk scoring. This package's scope is classic activation and reset email, not an identity platform.
• Deliverability is failing for infrastructure reasons (no SPF/DKIM/DMARC, cold sending domain, shared IP reputation). Template-level fixes will not compensate; you need sending-domain and reputation work, possibly a transactional ESP.
• You require deep localization, per-locale template management, or marketing-grade templating with a visual editor and approval workflow.
• The package's release cadence and maintainer responsiveness do not meet your support expectations for a security-adjacent surface (password reset). Weigh this explicitly before making it load-bearing.

How to Pitch It (Stakeholders)

For executives: This is a small, low-risk upgrade to how our activation and password-reset emails are constructed. The vendor shipped the standard fix that mailbox providers expect — a properly marked-up HTML body plus a plain-text version of the same message. The practical effect is a lower likelihood that these two emails get flagged as spam, which protects new-user activation and reduces "I never got the reset link" support contacts. There is no migration, no downtime, and no change to our own templates or integrations. Recommended action: upgrade in the next maintenance window and watch activation and reset completion rates for a few weeks as our success measure.

For engineering: v1.1.7 is a patch release confined to the activation and reset-password email templates: HTML tags were added to the HTML variant and a plain-text variant was introduced, producing a proper multipart/alternative message. No public API, config schema, database, or route changes; no deprecations. Integration is a dependency bump plus a template-cache clear. Worth pairing with a check that our configured sender domain still passes SPF/DKIM/DMARC and that our mail transport preserves both MIME parts, since the deliverability benefit depends on the text part surviving the send path. Test with a real mailbox across at least one major provider and one corporate gateway before shipping. Longer term, if this package remains our auth-mail layer, we should track maintainer activity given the security sensitivity of password reset.