Electron Laravel Package

Product Decisions This Supports

• Desktop delivery strategy for existing Laravel products: NativePHP/electron lets a PM evaluate shipping a desktop client without a separate native rewrite, reusing Laravel/PHP domain logic, auth, queues, and UI patterns where applicable.
• Build vs. buy vs. extend: Supports “extend current Laravel app to desktop” as a credible option against building a separate Electron/React or native desktop app, or buying a third-party desktop wrapper.
• Roadmap sequencing for desktop features: 1.3.0 adds product-facing controls that map directly to roadmap items: per-window zoom factor, app locale exposure to Electron APIs, optional suppression of sub-window opening, and navigation restriction to the current domain/page.
• Operational reliability for multi-app and long-running desktop use: Fixes for Windows port conflicts when running multiple NativePHP apps and cleanup of stray scheduler processes reduce support burden and make desktop deployments more viable for users running several internal apps or long-lived sessions.
• Security and compliance decisions: Navigation blocking and controlled sub-window behavior support decisions around locking users to trusted domains, preventing accidental external navigation, and reducing phishing/escape-hatch risk in desktop shells.
• Updater and release-management scope: “Only use publisher config when updater enabled” clarifies packaging/updater behavior, which affects decisions about whether to enable auto-update in v1, how to configure publisher metadata, and how much release engineering to staff.
• Platform-specific UX decisions: Windows zoom factor support and locale endpoints enable accessibility/localization choices that were previously harder to deliver consistently across desktop platforms.

When to Consider This Package

Consider NativePHP/electron when:

• You have an existing Laravel/PHP application and want to test or ship a desktop distribution with minimal stack divergence.
• Your desktop requirements are mostly web-UI-in-a-shell: local windows, navigation control, locale awareness, zoom/accessibility, and packaging for Windows/macOS/Linux.
• Your team is PHP-heavy and would rather invest in Laravel skills than stand up a separate native desktop team.
• You need a pragmatic desktop MVP or internal-tool distribution, not a fully native, low-memory, platform-specific application.
• You can tolerate Electron’s footprint and a community-driven 1.x package with active fixes but evolving edge cases.
• You need features reflected in 1.3.0, such as multi-instance Windows support, navigation restrictions, sub-window suppression, and locale/zoom controls.

Look elsewhere or defer when:

• You need highly native performance, deep OS integration, small binary size, or strict memory constraints.
• You require a mature, vendor-supported desktop framework with guaranteed SLAs and long-term commercial support.
• Your roadmap depends on advanced auto-update, code signing, notarization, and enterprise deployment workflows that need dedicated release engineering beyond the package’s current out-of-the-box story.
• You are mobile-first; this is a desktop packaging path, not a mobile strategy.
• You cannot absorb dependency churn or packaging regressions. The 1.3.0 note “downgrade electron-builder” is a signal to validate your build pipeline and CI artifacts before committing to a release train.

How to Pitch It (Stakeholders)

To executives: NativePHP/electron gives us a lower-risk way to test a desktop channel by reusing our Laravel investment instead of funding a separate native app. Release 1.3.0 improves operational stability—especially on Windows with multiple apps—and adds practical controls for localization, accessibility, navigation security, and sub-window behavior. It is best positioned as a fast desktop MVP or internal-tool path, with a clear gate before betting the roadmap on it.

To engineering: This is an Electron shell for Laravel apps. 1.3.0 is mostly stabilization plus useful hooks: Windows port-conflict fixes, scheduler-process cleanup, updater config gating, zoom factor, locale APIs, sub-window suppression, and navigation blocking. It reduces common desktop edge cases, but we should validate packaging/updater behavior—particularly the electron-builder downgrade—in CI before relying on it for customer-facing releases. Treat it as a strong fit for Laravel-centric desktop delivery, not a replacement for native performance or a fully managed enterprise desktop platform.