Using position: relative for the banner while offsetting the fixed navigation bar via --vp-layout-top-height causes a visual gap at the top of the viewport when scrolling down. As the banner scrolls away, the navigation bar remains fixed at its offset position. Changing the banner to position: fixed ensures it stays at the top of the viewport along with the navigation bar, providing a consistent user experience.

The initBanner function should be idempotent to prevent multiple fetches or redundant banner injections if the function is called multiple times (e.g., during development with HMR or if enhanceApp is triggered again).

let initialized = false;
export function initBanner(): void {
  if (typeof window === "undefined" || initialized) return;
  initialized = true;

The banner's height can change if the window is resized (e.g., text wrapping on smaller screens). Using a ResizeObserver ensures the --vp-layout-top-height CSS variable stays in sync with the actual height of the banner. This prevents layout issues where the navigation bar might overlap the banner or leave a gap.

  const observer = new ResizeObserver(() => {
    document.documentElement.style.setProperty(
      "--vp-layout-top-height",
      `${el.offsetHeight}px`,
    );
  });

  btn.addEventListener("click", () => {
    localStorage.setItem(STORAGE_KEY, b.id);
    observer.disconnect();
    el.remove();
    document.documentElement.style.removeProperty("--vp-layout-top-height");
  });
  el.appendChild(btn);

  document.body.prepend(el);
  observer.observe(el);

initBanner() called in enhanceApp rather than onMounted

enhanceApp runs synchronously during Vue app bootstrap, before the component tree is mounted. All other imperative DOM work in this file (star count) is deferred to onMounted() for exactly this reason. While the async fetch means render() only runs after the DOM is ready in practice, the call site pattern is inconsistent and could break if an eager document.body access is ever added. Moving initBanner() inside the existing onMounted would align it with the established pattern.

Strict equality breaks dismissal for non-string banner IDs

Medium Severity

The BannerData.id is typed as string, but since the data comes from an external JSON endpoint with only a type assertion (as Promise<BannerData>), a numeric id (e.g., 1) won't be caught at runtime. localStorage.setItem coerces the value to "1", but the subsequent localStorage.getItem(STORAGE_KEY) === b.id performs strict equality between "1" and 1, which is always false. This makes the banner undismissable whenever the upstream JSON uses a numeric id.

 

^{Reviewed by Cursor Bugbot for commit 07edbff. Configure here.}