Jolinotif Laravel Package

Product Decisions This Supports

• Build vs. buy for cross-platform desktop notifications. The problem (notify on macOS, Linux/GNOME, KDE, Windows, WSL) is mostly OS-quirk engineering with near-zero product differentiation. JoliNotif collapses it to one DefaultNotifier + Notification API, so the decision becomes "adopt an 8-year-old MIT library" instead of "own four shell integrations forever."
• Developer-experience investment in CLI and internal tooling. The realistic use cases are all engineering-facing: ping when a long artisan command finishes, when a queue worker exhausts retries, when a nightly cron/backup/import completes or fails, or when a local CI agent goes green. This is a cheap DX win with visible, tactile payoff for the team.
• Scope control on a "notifications" roadmap item. This package forces an explicit decision: desktop notifications for operators/developers are not the same product surface as customer-facing email/SMS/push. Adopting it here keeps the customer notification workstream (and its vendor spend, deliverability, and compliance burden) cleanly separated.
• Feasibility gating on a feature request. Because it is CLI-only (explicitly unusable under FPM/web contexts), it can only back features triggered by cron, workers, or local commands. That constraint should kill or reshape any "notify the user in the browser" ticket early, before design time is spent.
• Maintenance-risk triage for a dependency review. v3.4.1 shipped fixes for argument injection in the notify-send driver, cross-user tampering with extracted PHAR resources, and script injection via Unicode quotes in the PowerShell driver. That's healthy security response, but it also tells you the package shells out with user-influenced strings — relevant if any notification title/body could originate from untrusted input.

When to Consider This Package

Adopt when all of the following hold:

• You are on PHP 8.3+ and can keep up — this project drops EOL PHP minors aggressively (8.0, 8.1, 8.2 already removed), so it will gate your runtime upgrade cadence.
• The caller is a CLI SAPI, cron job, or worker — never a web request.
• The audience is developers or operators on their own machines (macOS, Linux, WSL, Windows) and you want zero-config, per-OS driver selection rather than picking a notifier yourself.
• You accept that delivery is best-effort and unobservable: no read receipts, no delivery guarantee, no central audit trail. If presence of the underlying binary is missing, notifications silently do nothing — plan a log line as the real record.
• You are comfortable with the supply-chain surface: the Windows drivers rely on bundled/third-party binaries, and drivers execute shell commands. Isolate it to internal tooling, not anything touching tenant data or production credentials.

Look elsewhere when:

• You need user-facing or guaranteed delivery → web push, transactional email, or a chat/webhook channel (Slack, Teams, ntfy) instead; those give you retries and an audit trail this never will.
• You are running headless containers, CI runners, or servers → there is no desktop session to notify; you want webhooks or log/alerting integration.
• You need interactive or rich notifications (actions, replies, deep links beyond macOS url) → the option surface is thin and per-driver, and most advanced options only work on one OS.
• You need a stable, minimal dependency footprint → this pulls symfony/process, a PHP OS-helper package, and (for the PHAR path) extracted binaries. For a single internal script, invoking notify-send/osascript yourself may be a better trade.
• You're on Symfony already and only need a subset → evaluate symfony/notifier first for consolidation, accepting you'll still do OS-level plumbing for desktop.
• Low dependents count (~0) and a mid-tier opportunity score are not disqualifying on their own (this is a leaf utility, not a framework building block), but they do mean you should not assume a large community will absorb your bugs.

How to Pitch It (Stakeholders)

One-liner: A small, MIT-licensed, actively maintained PHP library that sends native desktop notifications from CLI scripts and cron jobs on macOS, Linux, Windows, and WSL — so our long-running commands tell people when they're done instead of people watching terminals.

To executives: This is a low-cost developer-productivity purchase, not a product feature. It's free, MIT, one Composer dependency, and has been maintained for ~8 years with current PHP/Symfony support and prompt security patches. Expected effort is a spike plus a thin internal wrapper — days, not a sprint. It does not touch customer-facing notification channels, so no vendor contracts, deliverability, or compliance exposure. Success is measured informally: fewer "is the import done yet?" pings and faster feedback loops on background jobs.

To engineering: New public API is DefaultNotifier::send(Notification) — drivers are internal, so OS branching lives behind one call. It requires PHP 8.3+ and only works on CLI SAPI, so wrap it in our own Notifier service with a config flag and a no-op fallback for CI/containers. Log every notification through PSR-3 so we retain a record when the desktop path is unavailable. Treat title/body as potentially untrusted and sanitize at the call site — recent releases fixed injection issues in the shell-based drivers, so we should not pass raw user input. Pin the major version and watch for PHP-minor drops in release notes.

Known risks to state up front: CLI-only scope; no delivery guarantee or reporting; best-effort driver selection that degrades silently when the OS binary is absent; a runtime floor that moves with the project's support policy; and a security surface inherited from shelling out to native notifiers — acceptable for internal tooling, not for anything privileged.