Wire Table Laravel Package

Product Decisions This Supports

• Build vs. buy for a recurring UX pattern. In-page navigation — anchor deep links, "back to top," sticky sub-nav, FAQ jump links, docs sidebars, "jump to latest" in activity feeds — shows up on nearly every content-heavy surface. This package lets us configure that behavior instead of writing bespoke scroll JS per feature.
• Roadmap sequencing. v2.2.0 added custom scrollTo targets, moving offset-aware scrolling (fixed headers, sticky nav bars) from "custom build" to "configure and ship." That unblocks in-page navigation work we'd otherwise defer behind a frontend spike.
• Confidence in config-driven rollout. v2.2.1 fixes nested configuration values not falling back to package defaults. This matters directly to the buy case: the entire value proposition is "configure, don't code." A silent failure to inherit defaults on partially-overridden nested keys would have produced mysterious behavior on a per-feature basis and invited exactly the bespoke patching we're trying to avoid. With the fix, a config file that overrides one nested key inherits the rest — so we can publish partial config per surface without forking or vendoring.
• Scope discipline. The package covers the scroll/interaction layer only. It is not a routing, SPA, or animation engine — treat it as a small dependency, not a platform decision. If a roadmap item needs complex animation timelines or virtualized list handling, this is not the tool and shouldn't be evaluated as one.
• Definition of done for polish work. Gives PM a concrete acceptance bar for navigation quality ("anchor links land correctly under the fixed header, with configurable offsets") rather than an open-ended "make scrolling nicer" ticket.
• Upgrade triage. v2.2.0 was purely additive; v2.2.1 is a single bug fix in config merging. Neither carries breaking changes, deprecations, or migration steps, and neither alters a prior decision — they ride along with routine maintenance rather than consuming a dedicated upgrade slot.

When to Consider This Package

Adopt when:

• We're in a Laravel/PHP codebase and want declarative scroll targets configured alongside existing app configuration, not a separate frontend toolchain.
• The need is standard in-page scrolling behavior — anchor links, offset compensation for sticky headers, back-to-top, cross-section links.
• We want to override only a subset of scroll settings per surface and rely on package defaults for the rest (reliable as of v2.2.1).
• The team wants a thin, low-maintenance dependency over hand-rolled scroll code duplicated across features.
• We want a low-risk minor/patch bump: existing markup and configuration keep working.

Look elsewhere when:

• The requirement is heavy animation choreography (scroll-linked timelines, parallax, spring physics) — a dedicated animation library is the right call.
• The problem is virtualized/windowed long lists or infinite scroll performance — that's a rendering concern, not a scroll-target concern.
• The work is JS-only with no Laravel context; the framework fit is then incidental overhead.
• The team has a strict "no new frontend dependencies" policy — this should be argued as config-over-custom-code, but it is still a dependency.
• We need scroll behavior that's critical-path and unmaintained upstream; check release cadence and issue responsiveness before adopting.

Adoption note: pin to ^2.2.1. v2.2.1 is backward compatible and drop-in over v2.2.0 — no spike, no migration, no regression window beyond the usual smoke test on navigation surfaces. Because the fix changes how nested config is merged, spend the smoke test specifically on any published config file that overrides nested keys, confirming defaults still apply to the unset keys.

How to Pitch It (Stakeholders)

To executives (one paragraph): We're adopting a small Laravel-compatible package that handles in-page scrolling — anchor links, jump-to-section, back-to-top — instead of building it ourselves. It now supports custom scroll targets (v2.2.0), which is the capability needed to make navigation land correctly under fixed headers, and the latest patch (v2.2.1) fixed a configuration bug so partial per-page settings inherit sensible defaults instead of silently breaking. It's a low-risk, low-cost addition: no breaking changes, no migration work, and it removes a repeated custom-build cost from our roadmap. Recommendation is to approve and let it ship with routine maintenance.

To engineering (the pitch):

• v2.2.1 fixes nested configuration values not being loaded from defaults — partial nested overrides now inherit the rest of the package config. No API changes, no deprecations, no migration.
• v2.2.0 (already available) made custom scrollTo targets configurable — that's the feature we actually want; v2.2.1 just makes the config layer trustworthy.
• It replaces per-feature bespoke scroll handlers with one declarative configuration surface, which cuts duplicated code and the associated bug class (off-by-header-height, wrong target on dynamic content).
• Testable at the feature level: assert the configured target resolves and the offset applies. No new build pipeline or frontend framework required.
• Ask: bump to ^2.2.1 in the next dependency maintenance pass; smoke-test navigation surfaces (marketing pages, docs sidebar, FAQ) and any published config that overrides nested keys. Flag any need for scroll-linked animation or virtualized lists as out of scope — we'll evaluate a different tool for those.

Risk statement (both audiences): The dependency is small and peripheral, not critical-path, and the one open config-merge defect is now closed. The main risk is scope creep — teams assuming it solves animation or list virtualization. Keep it positioned as the in-page scroll layer and it stays cheap to own.