Electron Laravel Package

Technical Evaluation

Assessment basis: Initial evaluation. No prior assessment exists, and the only supplied evidence is the 1.3.0 changelog. Findings below are inferences from release scope and should be validated against the package docs and source before commitment.

Architecture fit

• NativePHP/electron is the desktop runtime layer for Laravel: it bundles a PHP binary, serves the Laravel app from a local HTTP listener, and wraps it in an Electron shell. The package therefore sits on the critical path between our application code and the shipped binary — version drift here is a distribution risk, not just a dependency bump.
• 1.3.0 is overwhelmingly a hardening and desktop-parity release rather than an architectural change. No new runtime model, no new build pipeline. That makes it a favorable upgrade window for a first adoption.
• The two most architecturally meaningful items are the Windows port-conflict fix (PR #244) and the navigation guard (PR #250). The former implies the local server binding strategy changed to tolerate concurrent instances; the latter introduces a policy surface that can intercept in-app routing. Both need to be understood before we rely on them.
• The addition of locale endpoints (PR #247) and Windows zoom factor (PR #246) is incremental API surface expansion. It signals the package is maturing toward desktop-app parity, but also that the Electron-side API is diverging from the plain Laravel developer's mental model.

Integration feasibility

• Low-to-moderate effort. Standard path is a composer dependency plus native:install / native:serve / native:build, with a Node toolchain required on the build machine or CI runner.
• The publisher-config change (PR #243) is explicitly a defect fix — config is only consumed when the updater is enabled. Apps that do not ship an auto-updater should see fewer build-time failures, which improves first-integration success.
• Sub-window suppression (PR #249) and navigation prevention (PR #250) are opt-in controls that map directly onto two recurring desktop-app requirements: constraining pop-up behaviour and preventing the shell from navigating to external content. Useful for compliance and security review.
• Risk: we cannot confirm from the changelog whether these are default-on, default-off, or breaking for existing window.open and OAuth redirect flows. Each requires a spike.

Technical risk

• electron-builder downgrade (PR #251) is the single highest-signal item. Downgrading a packaging tool can affect installer formats, code signing, macOS notarization, and auto-update metadata generation. The changelog gives no rationale. This deserves a direct question to maintainers and a full build-matrix regression test before we adopt.
• Navigation guard (PR #250) is a double-edged control. It improves security posture against remote-content hijacking, but if enabled by default it can silently break third-party OAuth callbacks, payment redirects, and any legitimate external link-out.
• Port binding change (PR #244) may alter how the local server picks a port. Any of our code that hardcodes or assumes a fixed localhost port (webhooks, deep links, local API callbacks) must be re-verified.
• Dependency and CI bumps (actions/checkout 4→5, git-auto-commit-action 5→6) are low risk internally but indicate the release is partly mechanical; the substantive fixes are concentrated in a handful of PRs from a small contributor set, including one first-time contributor. Bus factor and review depth are worth noting.
• Security patching cadence: Electron major-version currency is not visible in these notes. An Electron shell that lags upstream Chromium patches is a standing vulnerability exposure for every shipped desktop binary.

Key questions

1. Why was electron-builder downgraded, to which version, and does it affect macOS notarization or Windows installer signing?
2. Which Electron major version ships with 1.3.0, and what is the project's stated policy for tracking Chromium security releases?
3. Are the navigation guard and sub-window suppression opt-in or default-on? What is the exact configuration key and default value?
4. Does the port-conflict fix change port allocation semantics (fixed → dynamic), and is the chosen port discoverable programmatically?
5. Is the locale endpoint exposed through the PHP-facing NativePHP facade, or only on the Electron/JS side?
6. Is the zoom factor setting persistent per window/session, or a one-shot call?
7. Does PR #243 require a config republish, and will native:install overwrite existing config files?
8. What is the maintainer bus factor and release cadence for this package?

Integration Approach

Stack fit

• Fits cleanly where the product requirement is "ship the existing Laravel app as a desktop binary" rather than "rewrite the frontend." No changes to our PHP framework version, database layer, or Blade/Livewire/Inertia stack are implied by 1.3.0.
• Introduces a genuine second toolchain: Node/npm and Electron build artifacts must exist on every packaging runner. This is the main new operational dependency, not a code dependency.
• The locale and zoom APIs reduce the need for custom Electron-side glue, which is a net simplification of our fork/maintenance surface if we currently carry patches.

Migration path

• Treat as a minor upgrade from 1.2.x: bump the composer constraint, run composer update nativephp/electron, rebuild, and diff the emitted config.
• Do not republish config blindly. Capture the current published config, upgrade, then compare — PR #243 changes how publisher settings are consumed and PR #244 may touch server configuration keys.
• If we are not yet on the package, this is a reasonable baseline to start from: it contains the multi-instance and config-hygiene fixes that would otherwise be immediate pain points.

Compatibility

• Verify our Laravel and PHP versions against the package's declared constraints before committing; the changelog is silent on support matrix changes, which is not the same as no change.
• Audit for hardcoded localhost ports, expected fixed windows, and any code relying on external navigation occurring inside the shell.
• Confirm that any auto-updater integration still resolves publisher config correctly after PR #243; if we do ship an updater, this is the change most likely to affect us.

Sequencing

1. Spike (1–2 days): pin 1.3.0 in a branch, build on all three target OSes, and explicitly test macOS notarization/signing given the electron-builder downgrade.
2. Behavioural validation: exercise multi-instance launch on Windows, OAuth/external-redirect flows under the navigation guard, and window.open behaviour with sub-window suppression.
3. Security review: confirm Electron version and patch level; document the navigation policy we intend to enforce.
4. Adopt new APIs opportunistically: locale and zoom factor are additive and low risk — schedule them as follow-on work, not upgrade blockers.
5. Rollout: internal dogfood build → staged release → general availability, with the 1.2.x build retained as a rollback artifact.

Operational Impact

Maintenance

• Modest but real. Expect to pin the exact patch version and review each release, because this package bundles a browser engine — upgrades are security-relevant, not cosmetic.
• The electron-builder downgrade creates a maintenance obligation: we must track when it is re-upgraded and ensure our build scripts are not relying on behaviour introduced in the newer builder.
• Carrying any local patches to the Electron layer becomes more expensive as the upstream API surface grows (locale, zoom, navigation, sub-windows). Prefer upstreaming over forking.

Support

• The Windows port-conflict and stray-scheduler-process fixes should measurably reduce end-user support tickets around "app won't start" and "processes left running after quit" — both classic desktop-app complaints and both previously hard to diagnose remotely.
• The navigation guard introduces a new class of support issue: users reporting that a link "does nothing." Support runbooks must cover the navigation policy and how to whitelist domains.

Scaling

• Multi-instance operation on a single Windows machine is now viable, which matters for shared workstations, terminal-server style deployments, and power users running side-by-side environments.
• Per-instance state must still be isolated: local SQLite files, cache directories, and log paths need instance-aware naming, or multi-instance support becomes a data-corruption vector rather than a feature.
• Build capacity scales linearly with the OS matrix and adds wall-clock time; three-OS signing pipelines are the bottleneck, not the app runtime.

Failure modes

• Packaging regressions from the electron-builder downgrade — installer generation or signing failures surfacing only at release time.
• Silent navigation blocking breaking authentication and payment flows in production if the guard is enabled without a domain allowlist.
• Suppressed sub-windows breaking any feature that legitimately relies on pop-ups (print dialogs, third-party auth).
• Port assumption breakage in any local callback or webhook integration.
• Orphaned scheduler processes — improved in 1.3.0, but still worth monitoring on forced quit and crash paths.
• Electron security lag — a stale Chromium base is a latent, non-obvious exposure with no runtime symptom until exploited.

Ramp-up

• For Laravel developers, the PHP-side surface is familiar; the learning curve is in packaging, code signing, and Electron debugging (DevTools, main/renderer separation, IPC).
• Budget roughly a sprint for a developer to become productive on build/release, and add a named owner for the desktop release pipeline — this is not a responsibility that can float.
• Document the navigation and sub-window policies as first-class product configuration, not incidental settings, so future feature work does not accidentally violate them.