Tinkerwell Helper Laravel Package

Product Decisions This Supports

• Developer experience (DX) investment: Deciding whether to fund small, quality-of-life tooling that shortens the inner dev loop — the kind of thing that never appears on a roadmap but shows up in onboarding time and day-to-day debugging friction.
• Standardizing the local debugging workflow: Choosing a canonical "poke at the running app" path for the team — Artisan tinker/PsySH vs. a GUI REPL like Tinkerwell vs. in-browser inspection like Telescope or Clockwork, or in-editor debugging with Ray + PhpStorm/Xdebug. This package only matters to the Tinkerwell branch of that decision tree; it is the glue that determines whether that branch is actually taken.
• Build vs. buy for internal tooling: It is a thin, MIT-licensed convenience wrapper around a paid desktop product. The real buy decision is the Tinkerwell license line item; this package makes that purchase get used instead of forgotten.
• Tooling spend justification: A concrete data point when arguing for (or against) a small per-seat tooling budget — low cost, dev-only, trivially reversible, and it makes an existing license stickier.
• Onboarding and context-switching cost: Collapses "open a terminal, cd into the project, remember the tinker invocation, boot the app" into a single command from the project root. Relevant to onboarding checklists, local-setup docs, and ramp time for new engineers.
• Environment and platform policy: Implies decisions about sanctioned desktop tooling on developer machines (macOS/Windows GUI apps) versus headless, container-only, or locked-down environments — and forces an explicit answer for WSL2, Devcontainers, Codespaces, and remote-SSH engineers.
• Explicitly not a product feature: This should never appear in a customer-facing release note and never be a runtime dependency. It informs internal engineering-enablement decisions only.

When to Consider This Package

Adopt when:

• Your team is already paying for Tinkerwell (or is about to) and developers keep forgetting to launch it against the right project.
• The codebase is Laravel/PHP and developers work on machines where a desktop GUI app is permitted.
• You want the smallest possible footprint: a --dev Composer dependency, one Artisan command, zero production surface, no migrations, no config, no secrets.
• You value consistency — codifying "this is how we open a REPL here" in composer.json beats a wiki page nobody reads.
• You want a documented, one-line onboarding step for new engineers ramping onto Laravel work.

Look elsewhere when:

• Nobody owns a Tinkerwell license. This package is a companion, not a REPL; installed alone it does nothing.
• You want in-browser or in-editor inspection. Telescope, Clockwork, Ray, Xdebug/PhpStorm, or plain php artisan tinker cover different needs without a paid desktop dependency.
• Your environments are headless, containerized, or remote-only (Codespaces, Devcontainers, WSL2, SSH bastions). The entire feature is an OS-level tinkerwell:// deep-link handoff, and inside a container or remote host that scheme resolves where no handler exists — the command silently no-ops rather than failing instructively.
• Supply-chain or procurement policy is strict. Note the signals: ~59 stars, 0 dependents, single maintainer, single-vendor ecosystem, last release May 2024, MIT. Technical risk is near-zero given the thin wrapper, but maintenance risk (will it track future Laravel majors?) and vendor coupling risk (Beyond Code controls both the package and the closed-source app) are real.
• You are evaluating this as a strategic dependency. It isn't one. Treat it as a disposable convenience; assume you may have to fork or replace it with a five-line Artisan command.
• The team is standardized on an alternative (Herd, Sail, Valet, or an IDE-integrated REPL) — adding a second path fragments the workflow for no gain.

Evaluation gate — questions worth answering before committing:

• Does it declare support for our PHP/Laravel matrix, explicitly including Laravel 11+ and PHP 8.3, given the May 2024 release?
• What is the exact command signature, and does it accept a path argument (i.e., is there an injection surface)?
• Does it make network calls, telemetry, or license-validation requests at command time?
• What percentage of our developers work in containerized, WSL, or remote-only environments where it structurally cannot work?
• What is current Tinkerwell per-seat pricing, and are team licensing terms available?
• Does procurement permit a dev-machine dependency on a paid closed-source GUI app from a single vendor?

How to Pitch It (Stakeholders)

For executives (30 seconds): This is a tiny, free, open-source convenience package that lets developers open our Laravel projects in Tinkerwell — the desktop REPL we may already license — with one command. It ships only to developer machines, is never loaded in production, costs nothing beyond any licenses we already hold, and can be removed with a single line from composer.json. The upside is modest but real: less friction in day-to-day debugging and a faster ramp for new engineers. The downside is bounded by the fact that it is a ~1-file wrapper — if the maintainer walks away, replacing it is an afternoon, not a project.

For engineering leads:

• Scope: a require-dev Composer package that adds an Artisan command handing the current project path to the Tinkerwell desktop app. No production service-provider magic, no migrations, no config, no runtime cost. It sits alongside PHPUnit, Pint, and Larastan in the tooling layer and should be governed as such.
• Why it's low risk: MIT licensed, single maintainer, 0 dependents, last release May 2024. The blast radius if it breaks is "the shortcut stops working," not "the app stops working." Removal is composer remove --dev with no residue; verify the deploy pipeline builds with --no-dev so it never lands in a production artifact.
• What we're actually committing to: a soft dependency on a paid, closed-source desktop app from the same vendor. That is the real decision, and it should be made deliberately against the alternatives (artisan tinker, Telescope, Ray, PhpStorm + Xdebug), not smuggled in as a Composer one-liner.
• Known limitation to call out up front: the deep-link handoff degrades exactly where modern teams live — Docker, Devcontainers, WSL2, and remote/SSH workspaces — where no URL handler exists and the command silently no-ops. Document the fallback (the app's own "open project" flow against a mounted path) rather than treating it as a bug.
• Recommended posture: adopt as an opt-in developer convenience, document it in the local-setup guide, pin the version in composer.lock, and do not let it become load-bearing. Explicitly exclude it from CI, pipeline scripts, scheduled tasks, and any agent or automation path.
• Sequencing: one developer validates install and handoff in week one; procurement confirms per-seat pricing and reimbursement policy in week two; a two-to-three person pilot spanning mixed OSes and mixed local/container setups in week three; publish onboarding docs plus a two-line troubleshooting note and decide opt-in vs. new-project template in week four.
• Success signal: developers invoke it without being reminded and onboarding docs get shorter. If it sits unused after a quarter, remove it — the license line item is the thing to re-evaluate, not the package.