Console Output Baseline

When you load a WireKit-using Laravel page in a browser, the developer console should be quiet. Any message that DOES appear should be attributable to a documented source — your own code, a dependency's init log, or a known dev-mode warning.

This page catalogs what to expect on a clean install. Use it as a reference when triaging unexpected console output or when writing browser tests that gate on console.error.

A bare console.error.length === 0 assertion is stricter than this baseline. WireKit reserves error for a page that is broken or a component that cannot do its job — and a missing optional dependency is one of those, so an editor, map or chart page can be a correct page that still logs one. The table under Messages WireKit Logs at error Level is the full set; filter against it rather than against a single remembered string.

First-Paint — Production Build

If you're seeing anything in any of these channels on first paint of a production build, that's actionable feedback. Look the message up in the two tables below first — if it is one of ours, it names the install step that resolves it. If it is not, investigate it as a bug.

First-Paint — Development Build

Vite's dev server adds a small number of informational messages:

These are dev-mode-only. A production build (npm run build) does not emit them.

During Page Interaction

WireKit's interactive components log nothing during normal interaction. You should never see a console message when:

• Clicking a button
• Opening a modal, drawer, dropdown, or popover
• Sorting a table
• Submitting a form
• Triggering a toast
• Scrolling a page with reading-progress / reading-spine

If you DO see a message during any of these interactions on a clean install, that's a bug — capture the message and the user action that triggered it.

Messages WireKit Logs at error Level

WireKit reserves console.error for a page that is broken or a component that cannot do its job. It is never used for style advice, and it is never used for something the page recovers from invisibly. This is the whole set:

Missing-dependency lines are error, not warn, on purpose. A chart with no charting library, an editor with no editor and a map with no map engine all render a container the reader can see and cannot use. The component degrades rather than throwing — the rest of the page keeps working — but nothing on the page says so, and a warning is too quiet for a feature that is simply absent. Each of those is emitted once per page however many instances are on it, so a dashboard of twelve charts logs one line, not twelve. The interaction-time diagnostics behave the other way and should: an editor command that failed, a refused link and a rolled-back optimistic action each report every time they happen, because each one is a separate thing the user just did.

The overlay-styles line deserves its own note for the same reason. A dialog that renders inside the page instead of over it looks finished and cannot be used, and on a long page it can sit below the fold where nobody finds it:

[WireKit] Overlay styles are missing, so dialogs, drawers and the command palette will
render in normal page flow instead of over the page. They will look correct and be
unusable — on a long page the panel can sit below the fold entirely.

It has a consequence for your test setup, and it is worth knowing before you meet it. A browser or console check that fails the run on any error will go red in this situation rather than amber — and the cause is an install step, not a defect in your page. If one of your lanes gates on error, expect that shape: a red run whose message names a missing stylesheet.

The fix is the install step the message itself names:

{{-- 1. The directive that loads the package stylesheet. --}}
@wirekitStyles

# 2. Or check the whole install at once, which reports this and everything adjacent.
php artisan wirekit:verify

Messages WireKit Logs at warn Level

A warn is a page that works and a decision that is probably not the one you wanted. These are the recurring families:

These are deliberate and actionable: each one names the prop, the selector or the install step that produced it. Install the dependency, correct the selector, or stop using the component on that page, and the line goes away.

Filtering Known-Noisy Messages in Browser Tests

If your lane gates on console.error, filter out the messages your own setup produces on purpose before you assert. The list below is an example, not a baseline to copy verbatim — put in it only what your pages genuinely expect, and take the WireKit substrings from the error table above:

const knownNoise = [
    // 1. Dev-server chatter, present only under `npm run dev`.
    '[vite] connected.',
    // 2. Browser-extension chatter, present only in a developer's own browser.
    'Download the React DevTools',
    // 3. A WireKit diagnostic THIS page expects — here, a chart demo with no
    //    charting library installed. Take the substring from the error table
    //    above; a string that never ships filters nothing and reports green.
    'WireKit: Chart.js is not loaded',
];

const realErrors = capturedErrors.filter(err =>
    ! knownNoise.some(noise => err.includes(noise))
);

// realErrors.length should be 0 on a clean install.

Common Mistakes That Cause Console Noise

When you see unexpected output, the most common causes are:

1. Forgetting to publish WireKit assets — php artisan vendor:publish --tag=wirekit-assets. Without this, the runtime can't find wirekit.js and emits a 404 in the network tab plus a ReferenceError in the console.
2. Missing @wirekitStyles / @wirekitScripts in your layout — WireKit components throw ReferenceError because Alpine isn't loaded. Run php artisan wirekit:verify to diagnose.
3. Stale compiled views — php artisan view:clear resolves it. Symptom: changes to @props blocks in templates don't reflect at runtime.
4. Out-of-order Blade directives — @vite([...]) MUST appear in <head> BEFORE @wirekitStyles. Reversing the order means the Vite-compiled CSS overrides WireKit's CSS variables and styling drifts unpredictably.
5. Custom Alpine plugin holding an unguarded observer reference — see Authoring Custom Alpine Plugins. Symptom: TypeError: Cannot read properties of null (reading 'disconnect'). Run php artisan wirekit:doctor to detect.

Cross-References

• Authoring Custom Alpine Plugins
• Pest Browser-Test Setup
• CLI Reference — wirekit:verify / wirekit:doctor diagnostics.
• Integration Guide — common setup pitfalls.