- How do I install bnussbau/laravel-trmnl in a Laravel application?
- Install it with Composer using composer require bnussbau/laravel-trmnl, then publish the package's config and Blade views so you can customise them locally. The integration point is a single route that your TRMNL device polls on a schedule, so there are no migrations, queues, or service providers for you to write. Because the package is only a presentation-layer adapter, you can drop it in alongside any existing Laravel 10+ app that already uses Blade.
- Which Laravel and PHP versions does laravel-trmnl support?
- Version 2.3.0 added Laravel 13 support, which signals the package is being kept current with the framework. However, the release notes do not state whether Laravel 11 and 12 remain supported, so the change could be additive or a drop-and-add. Check the composer.json constraints in the tagged release before assuming a safe upgrade, and confirm the implied PHP floor that Laravel 13 brings with it.
- How do I build a custom TRMNL plugin screen in Laravel?
- You define a route in your Laravel app that returns a Blade view containing the markup you want rendered, then point your TRMNL plugin at that URL. The package supplies the routes, config, and Blade rendering primitives so the work stays in familiar territory rather than a bespoke templating layer. Keep any data fetching in your own services and let the view stay a thin presentation layer, because the package should not own business logic.
- Does laravel-trmnl require database migrations, a queue, or extra infrastructure?
- No. It is a thin presentation adapter that renders markup on request, so there are no migrations, no queue workers, and no persistence changes required. It sits at the edge of your architecture next to other output channels like mail, PDF, and webhooks. That low coupling is also why it is easy to remove or replace later with a hand-rolled controller.
- How do I secure a private TRMNL screen that exposes internal data?
- Apply your existing Laravel auth middleware to the screen route, since the package composes naturally with standard route middleware. A common approach is a signed URL or a bearer token that the device sends when it polls on its schedule, avoiding a full session-based login from an e-ink device. Confirm what headers your TRMNL plugin can send before settling on a scheme, and never leave internal dashboards on an unauthenticated public route.
- What changed in laravel-trmnl 2.3.0 and is it a breaking change?
- 2.3.0 is a compatibility-and-dependency release rather than a feature release: it adds Laravel 13 support and bumps two dependencies. The bigger risk is that both bumps are semver-major inside a minor version: bnussbau/laravel-trmnl-blade goes from ^2.3.4 to ^3.0.3 and voku/simple_html_dom from ^4.8 to ^5.0. The Blade package is the view and component layer that actually produces your markup, so treat that bump as the highest-risk item and review it in isolation.
- How do I upgrade laravel-trmnl-blade to 3.x without breaking my published views?
- Upgrade the Blade dependency in a dedicated branch, re-publish its views to a temporary path, and diff them against the copies you have published locally. That surfaces changes to component names, slots, config keys, and stub content before you adopt the parent package bump. Watch for silently stale published views, since re-publishing can overwrite local customisations, and check whether the 3.x release ships documented upgrade notes.
- How do I test TRMNL screen output in a Laravel test suite?
- Write HTTP tests that hit the screen route and assert the status code and key markup fragments, plus a snapshot test of the full rendered payload so format drift is caught. Be aware that markup can pass assertions yet still look wrong on a 1-bit e-ink display, so eyeball the output or render it to an image where possible. Also check what the package's own CI matrix covers, since a solo-maintainer project relying on automated dependency PRs is only gated by that suite.
- Is bnussbau/laravel-trmnl safe to use in production?
- It is reasonable for production as an output adapter, but not as a place to put business logic. The main concerns are governance rather than code: a single maintainer, a high bus factor, and dependency churn driven by bots instead of a published roadmap. Because the package is low-coupling and replaceable with a controller that returns the same markup, the blast radius of abandonment or a bad release is small.
- What are the alternatives to laravel-trmnl for serving a TRMNL screen?
- The simplest alternative is a hand-rolled Laravel route and Blade view that returns the same markup your device expects, which removes the dependency entirely. That is viable because the package does not touch domain models, persistence, or infrastructure, so replacing it is mostly a matter of copying view content. Choose the package if you want its config, routing, and Blade component conventions out of the box, and skip it if you only need one static screen.