- What is awcodes/typebar and what does it do?
- awcodes/typebar is a lightweight Filament plugin that adds a mobile-friendly Markdown symbol row to Filament's MarkdownEditor field. It is a presentation-layer enhancement for admin and editor surfaces rather than core domain logic, so content storage and rendering do not depend on it. In v0.1.2 its assets load conditionally, meaning they are only pulled in on pages that actually use typebar().
- How do I install awcodes/typebar in a Laravel app?
- Install it with Composer, publish any assets the package requires, and register typebar() only on the editor pages that need it. Clear your view, config and asset caches, then smoke-test the affected editor pages on a dedicated test page before rollout. New installs should first check Composer and front-end compatibility against your application's Laravel, PHP and editor versions.
- Which Laravel and Filament versions does typebar support?
- The package's published Composer constraints are the authoritative answer, so check them against your application's Laravel, PHP and Filament versions before installing. Documentation is now hosted at docs.aw.codes, and you should confirm the docs match the version you install. Because the package is pre-1.0, do not assume API stability across releases.
- Should I use typebar v0.1.2 or is v0.1.1 fine?
- Treat v0.1.2 as the minimum viable version. v0.1.1 shipped with a total asset-loading failure, and v0.1.2 fixes it while adding conditional asset loading. Pin to v0.1.2 or later rather than using floating constraints in production.
- How do I upgrade typebar from v0.1.1 to v0.1.2?
- Update the package with Composer, then remove any custom render hooks you added as workarounds for the broken asset loading. Clear view, config and asset caches, rebuild front-end assets if your pipeline requires it, and verify assets load only where typebar() is used. Finish with a light-mode, dark-mode and fullscreen smoke test on the affected editor pages.
- Does typebar load its JavaScript and CSS on every page?
- In v0.1.2 assets are loaded conditionally, so they only ship on pages that actually use typebar(). That is a positive performance signal and avoids shipping editor assets globally across your admin panel. If you are still on v0.1.1, expect different behavior and upgrade.
- Is typebar production-ready at v0.1.x?
- It is usable but carries medium technical risk because it is a pre-1.0 package. The recommended approach is to pilot it in internal or admin tooling first and avoid making it a critical dependency of customer-facing authoring until releases are steadier. Pin versions, review releases, and monitor asset 404s and console errors after deploying.
- How should I test typebar after installing or upgrading?
- Create a dedicated test page that uses typebar() and confirm assets load only there rather than globally. Test light mode, dark mode and fullscreen editing, then exercise the save and render paths. Watch the browser console for JavaScript errors and 404s, since asset-loading regressions are a known risk with this package.
- Why does the fullscreen editor break in light mode?
- The light-mode fullscreen bug was caused by an undefined CSS variable, so it is a styling issue rather than a logic bug. Visual QA across light and dark themes matters after every upgrade. If you see it, check that the package CSS is actually loading and is not blocked by stale caches or a restrictive CSP.
- Where can I find typebar documentation and support?
- Documentation is now centered on docs.aw.codes, so confirm the docs match your installed version. Support is likely author and community driven, with no enterprise SLA indicated. Keep an internal runbook covering asset loading, cache clearing and removal of any workaround render hooks.