Typebar Laravel Package

Getting Started

awcodes/typebar adds a floating "typebar" row to a Filament rich editor field. It's early (0.1.x), so treat the API as unstable and pin your constraint (^0.1.2).

1. Install:

   composer require awcodes/typebar:^0.1.2
   

2. Add the modifier to a rich editor field you already have:

   use Filament\Forms\Components\RichEditor;
   
   RichEditor::make('content')
       ->typebar()
   

3. Open the form in the browser and confirm the row renders above/below the editor. If you're coming from v0.1.1, this is the fix release — v0.1.1 never loaded the package's script or stylesheet at all, so nothing appeared for anyone.

Where to look first: the docs at docs.aw.codes (the README in v0.1.2 was deliberately trimmed to a landing page pointing there). Second stop is vendor/awcodes/typebar/resources/ — the Blade view and CSS are the fastest way to see what the row actually is and which CSS variables it depends on.

First use case: put ->typebar() on the one editor your content authors use most (e.g. a Post body field), verify light and dark mode, then roll out to the rest.

Implementation Patterns

Treat typebar() as a chained modifier, not a global switch. It's applied per-field, so you can roll it out to select editors:

RichEditor::make('body')->typebar(),
RichEditor::make('internal_notes'),          // plain editor, no typebar

Modifier order is not significant. The docs now state explicitly that typebar modifiers can be chained in either order. Pick one convention for your codebase and stick to it so reviewers don't churn on ordering:

->typebar()->fullscreen()   // pick this
->fullscreen()->typebar()   // ...not both styles in the same repo

Wrap it in your own field factory if you have more than a couple of editors. It gives you one place to change when the API shifts between 0.x releases:

// app/Filament/Fields/TypebarEditor.php
public static function make(string $name): RichEditor
{
    return RichEditor::make($name)->typebar();
}

Custom editors / non-standard render paths. Because v0.1.2 loads assets only on pages that need them, any place where the typebar renders outside the normal Filament field lifecycle (a custom Livewire component, a Blade partial using the panel layout, a PDF/preview view) is where you're most likely to see the un-styled row. Test those explicitly rather than assuming the auto-registration covers them.

Filament panel + SPA navigation. Forms reached via wire:navigate re-mount Livewire components; verify the row re-initialises on client-side navigation between resource pages, not just on hard reloads. This is the single most common "it worked on my machine, then it didn't" report for toolbar-style plugins.

Upgrading from 0.1.1: this is a pure bug-fix release. Two things to do:

• composer update awcodes/typebar and bump your constraint.

• Remove any workaround you added to load the assets — a FilamentAsset::register() call in a service provider, a ->registerAssets()/render hook, a manual <link>/<script> in a panel render hook, whatever you improvised. Leaving it in means the assets load twice.

  grep -rn "typebar" app/Providers resources/views
  

  Then php artisan filament:assets (and view:clear) after removing it.

Gotchas and Tips

v0.1.1 is unusable — don't debug it. If a colleague reports "the typebar row doesn't show up", check composer.lock before anything else. The root cause in 0.1.1 was that the script and stylesheet were never loaded; no amount of ->typebar() chaining fixes that. Confirm the version, then debug.

Light mode fullscreen was transparent. v0.1.2 fixed an undefined CSS variable that made the fullscreen editor see-through and stripped the white fill from the row's buttons. If you wrote CSS to patch that (an --typebar-* variable override, a background-color: white !important), delete it — it will now fight the package's own styles and can break dark mode. If you have custom theming on the typebar, re-check it in both modes after upgrading.

Verify the fix by inspecting the DOM, not by eyeballing. Load the page, view source, and confirm the package's CSS/JS are present exactly once. Two copies after an upgrade means a leftover workaround.

Check the assets are actually conditional. The point of the fix is "only on the pages that need them". Navigate to a page with no typebar and confirm the assets aren't loaded — if they are, something else in your panel (or a leftover hook) is registering them globally, and you're paying that cost on every page.

Publishing/overriding views is an upgrade hazard at 0.1.x. If you published the package views or CSS to customise the row, a fix release can leave your copy stale — you'd keep the transparent-fullscreen bug even after upgrading. Prefer CSS overrides in your own theme over published Blade until the API stabilises.

Noisy changelog, small surface. Most of v0.1.2 is internal: CI workflow normalisation and SHA pinning, Rector/PHPStan path alignment, Focus-generated screenshots and share cards, README trim. Only PR #15 touches runtime behaviour. When triaging a future release, read the "Fixes" section first and skim the "What's Changed" list for anything that isn't ci: / chore: / docs:.

Pin the CI you depend on. The package now triggers CI on workbench/ and bin/ changes and pins the shared workflow to a commit SHA. If you keep a fork or a local workbench for reproducing issues, mirror that — otherwise your local CI won't run on the same paths that upstream's does.

Debugging checklist, in order: version in composer.lock → assets present in page source → ->typebar() actually on the field → light and dark mode → hard reload vs wire:navigate → published views stale.

Budget for churn. At 0.1.x the modifier names and defaults can still move. Keep the typebar() calls behind your own field factory (above) so an API change is a one-file edit, and read the docs at docs.aw.codes rather than the README before writing new code.