Take Tailwind out of the package, and its detection out of the guard
tests / feature (8.4) (push) Successful in 2m0s
tests / feature (8.5) (push) Successful in 2m0s
tests / browser (chrome, chromium) (push) Failing after 8m3s
tests / browser (firefox, firefox) (push) Failing after 12m58s
tests / browser (safari, webkit) (push) Failing after 13m8s

Tailwind left the stack in 2.0.0, but the package still carried about 330
mentions of it. What the guard's Tailwind detection protected — a class
that compiles to nothing — is now protected by a check that does not care
where a dead class came from.

DesignGuard: about 500 lines of Tailwind tables, scales, palettes and
"2.0.0 replacement" hints give way to one check — a class a view or PHP
file writes that neither the application's stylesheets nor the package's
own declare. It catches a utility of any framework, a typo and a class
whose rules were deleted alike, so it also found two classes ReStride
draws nothing with. A stylesheet has to be in reach for it: the `.css`
files among the scanned paths, or what the `missingStylesheets()` entry
imports. The class reader no longer mistakes an array index for a class
list (`$block['base']`), and it reads the array a class helper is given,
where it read nothing before.

The package's own three Tailwind self-guards go with it. Only their one
unique check stays, as a test of its own: every `matchMedia` width in
resources/js is an M3 breakpoint.

The pagination views are `material.blade.php` and
`simple-material.blade.php`; only Laravel's and Livewire's default theme
names ever made them `tailwind`. The provider sets `Paginator`'s default
views and switches `livewire.pagination_theme` to `material` when it is
still Livewire's own default, so no application can forget the config; a
theme an application chose, and a component's own `$paginationTheme` or
`paginationView()`, still win.

The rest is prose: the layer-order guidance for an application that still
builds Tailwind, the Tailwind wording in the README, the Boost guidelines
and the development skill, and about 25 "this used to be a Tailwind
utility" comments, along with every "plan step NN" pointer into a
gitignored folder. The reset keeps its credit, and NOTICE now carries it
too.

Feature suite 1159 passed, Chrome browser suite 299 passed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Andreas Reinhold / reini
2026-09-17 21:07:39 +02:00
co-authored by Claude Opus 5
parent 247c596c3a
commit fb7007c976
88 changed files with 649 additions and 1521 deletions
+30 -4
View File
@@ -3,6 +3,7 @@
namespace NoNameWeb\LivewireMaterial;
use Illuminate\Contracts\View\Factory;
use Illuminate\Pagination\Paginator;
use Illuminate\Support\Facades\Blade;
use Illuminate\Support\Facades\Route;
use Illuminate\Support\ServiceProvider;
@@ -133,10 +134,28 @@ class LivewireMaterialServiceProvider extends ServiceProvider
}
/**
* Put the M3 paginators in front of Laravel's and Livewire's own. Prepended to their
* namespaces rather than set as the default view, because Livewire sets its own default on
* every render; an application's published `vendor/pagination` or `vendor/livewire` views are
* looked up before any namespace path, so they still win.
* Put the M3 paginators in front of Laravel's and Livewire's own, and take over both
* frameworks' default theme so no application forgets the config and silently renders
* Laravel's or Livewire's own Tailwind view instead.
*
* The namespaces still go through callAfterResolving('view', …): the Factory instance only
* exists once the `view` service resolves, which may happen before or after this method runs.
* `Paginator::defaultView()`/`defaultSimpleView()` and `livewire.pagination_theme`, in
* contrast, are a plain static and a config value — nothing needs resolving first — so they
* are set here directly, during this provider's boot(). Package providers boot before the
* application's own (its `bootstrap/providers.php` list is appended after the discovered
* package providers), so an application that calls `Paginator::defaultView()` again, or sets
* `livewire.pagination_theme` itself, in its own boot() still wins. Deferring them into the
* callback instead would risk the opposite: `view` can resolve arbitrarily late — the first
* render, possibly after the application's own boot() already set its override — and this
* call would silently overwrite it.
*
* `livewire.pagination_theme` is only taken over while it still reads as Livewire's own
* default, `tailwind` — including when the key is missing entirely, since
* `SupportPagination::paginationView()` reads it with that same fallback. An application that
* chose another theme, or already set `material`, keeps it. Either way, a component's own
* `$paginationTheme` property or `paginationView()` method still wins over the config, because
* Livewire checks those first.
*/
protected function registerPagination(): void
{
@@ -148,6 +167,13 @@ class LivewireMaterialServiceProvider extends ServiceProvider
$view->prependNamespace('pagination', __DIR__.'/../resources/views/pagination/laravel');
$view->prependNamespace('livewire', __DIR__.'/../resources/views/pagination/livewire');
});
Paginator::defaultView('pagination::material');
Paginator::defaultSimpleView('pagination::simple-material');
if (config('livewire.pagination_theme', 'tailwind') === 'tailwind') {
config(['livewire.pagination_theme' => 'material']);
}
}
/**