Laracon Schedule Laravel Package

Getting Started

This is a terminal utility, not an application dependency. Install it globally, run it on demand, and keep it out of your product's composer.json. It is a Laravel Zero / Symfony Console command that fetches the Laracon agenda and renders it with Termwind — that's the whole surface area.

1. Install globally so the binary lands on your PATH:

composer global require nunomaduro/laracon-schedule

Confirm your global Composer bin directory is actually on PATH, otherwise the command "won't exist" even though the install succeeded:

composer global config bin-dir --absolute

2. Run it:

laracon-schedule

You should get talks, speakers, and time slots as a rendered terminal table. There is no config file, no publish step, no service provider to register.

3. Where to look first. The package is small enough that the source is the documentation:

• README.md — the exact binary name and any flags (--day, --now, --no-ansi, etc.). Read this fully; it's short.
• composer.json — the bin entry (real binary name), the PHP require constraint, and the license.
• src/ — the command class that performs the HTTP call, and the Termwind view that renders the table. Two files typically tell you everything: where the data comes from and how it's shaped.

First use case: it's conference week (or you're following the livestream remotely) and you want "what's on now / what's next" without surrendering a browser tab or fighting a mobile site on conference Wi-Fi. Run the command, read the table, close the terminal. That's the entire value proposition — don't overthink it.

Implementation Patterns

Because this is a single-purpose reader tool, "patterns" are about wiring it into your workflow rather than into your codebase.

Global install + shell alias. The dominant pattern. Shorten the invocation and bake in your preferred flags:

alias lc='laracon-schedule'
# or, with a default day:
alias lc='laracon-schedule --day=today'

Conference-day watch loop. Keep a live running order in a side pane while you code — genuinely useful when talks overrun:

watch -n 60 laracon-schedule

Since every invocation typically re-fetches, watch gives you a cheap refresh without a caching layer of your own.

Scripted / captured invocation. The command is non-interactive, so you can capture stdout. If you're logging it or diffing "has the schedule changed?", strip ANSI first:

laracon-schedule --no-ansi | ansi2txt > schedule-$(date +%F).txt

Prefer an explicit --no-ansi (or NO_COLOR=1) over post-processing escapes if the command honors it — check the README first.

The real day-to-day value: reference implementation. For a working Laravel developer, the most transferable use of this repo is as a template. It demonstrates the Laravel Zero / Console + HTTP client + Termwind stack for wrapping a remote JSON endpoint in a terminal UI. Fork the structure, not the code, when you need to build:

• a deploy-status board for your team,
• an on-call rota viewer,
• an internal release-calendar command,
• a "what's on now" pane for your own conference or meetup.

These are the same three moving parts: a command, an HTTP client call with a timeout, and a Termwind view. Copy that shape and point it at a data source you own.

Project-local install (edge case). If a team tooling repo genuinely needs it pinned and reproducible across a team:

composer require --dev nunomaduro/laracon-schedule
vendor/bin/laracon-schedule

This is rarely worth it. The global install is the honest placement; a --dev entry only makes sense if you're pinning a version for a group of developers and documenting it in a runbook.

Gotchas and Tips

Event-scoped and ephemeral by design. With ~100 stars, 0 dependents, and a single-event focus, expect the fetched schedule to be pinned to one Laracon edition. After the event, output may be stale, empty, or a 404. Treat that as expected lifecycle, not a bug — before filing an issue, inspect the endpoint URL in the command source and check whether it still resolves.

Network dependency on the worst possible network. The command almost certainly hits a remote URL per invocation with no guaranteed cache or offline fallback. That's precisely the scenario of conference Wi-Fi. Two mitigations, both cheap: run it once before you need it and snapshot the output to a file, and keep the official schedule page as your documented fallback. Never let a DevRel workflow depend on this command succeeding.

Don't parse the table as a data feed. The rendered output is a presentation layer over a remote payload that can change shape without warning. If you need machine-readable schedule data, fetch the underlying source yourself — the terminal table is for human eyes only. Any script that regexes the columns will break on the next formatting change.

Terminal rendering assumptions. Termwind output assumes UTF-8 and a reasonably wide pane. Expect mangled speaker names or wrapped columns in a narrow split pane or a non-UTF-8 locale. Widen the terminal before concluding anything is broken; LANG=en_US.UTF-8 fixes most of it. Redirected output may carry ANSI escapes into your logs — use --no-ansi or NO_COLOR=1 where supported.

PATH and binary-name confusion. The most common "it's broken" report is actually "the binary isn't on PATH." Verify composer global config bin-dir --absolute is in your $PATH, and trust the bin key in composer.json for the real executable name rather than guessing.

PHP constraint vs. your global runtime. Global installs resolve against your default PHP, which may differ from the version your projects use (especially with multiple PHP versions via Homebrew/asdf). If the install fails on constraints, that's a global-runtime mismatch, not a package defect.

Never promote it into production. No service class, no contracts, no programmatic API — it's an executable. Adding it to a product composer.json, or putting it behind shared automation, mistakes a novelty for infrastructure and exposes you to upstream abandonment with no vendor support behind it.

Extension points are forks. There is no config to publish, no driver to swap, no events to hook. If you need a different data source, caching, or a different layout, the correct move is to fork and repoint the command at data you own — assign an owner, document the endpoint and the fallback, and pin the version. Otherwise, leave it as optional developer tooling with the official schedule as the sanctioned source of truth.