1435: Update Storybook to latest version and move to Vite

[nJim]

#1435: Update Storybook to latest version and move to Vite (via Emulsify update)

Description of work

• Updates every dist/js/<tier>/... library reference in atomic.libraries.yml to the new dist/js/components/<tier>/... path
• dist/css/style.css, dist/css/link-treatment.css, and the FontAwesome CSS paths are unchanged as the component-library-twig's build was patched to keep emitting those at their original locations

Functional testing steps:

• No standalone testing here as this is a path-only change with nothing to render on its own. Verify it alongside the matching component-library-twig and yalesites-project branches via the multidev preview

---

Related PRs (cross-repo work unit)

This change spans three repos and has to be reviewed and merged as one unit.

Repo	PR	Base	Contains
component-library-twig	#672	after-2260	the Storybook/Vite migration itself
atomic	#495	after-2260	Drupal library paths for the new dist/ layout
yalesites-project	#1413	after-2260	frontend build, sprite path config, getAssetPath docs

Merge order: component-library-twig → atomic → yalesites-project. The Vite build code-splits micromodal, so dist/js/.../yds-calendar.js is now an ES module; atomic #495 is what loads it with type: module. If the component library ships ahead of atomic, the events calendar goes inert with nothing but a console parse error. The same coupling applies to the dist/assets/icons.svg sprite path.

Issue: yalesites-org/YaleSites-Internal#1435

[dblanken-yale]

Brought this branch current with after-2260 (clean merge — the base only bumped the component-library dep in package-lock.json) and pushed one fix.

The events calendar was inert

dist/js/components/03-organisms/calendar/yds-calendar.js is a real ES module under the Vite build. It literally begins:

import{n as g}from"../../../../assets/micromodal.es-Dp1N63aw.js";Drupal.behaviors.eventsCalendar={...

The calendar library loaded it as a plain script. A classic script containing a top-level import is a parse-time SyntaxError, so nothing in the file executes and Drupal.behaviors.eventsCalendar is never registered. The calendar renders its markup and is completely inert — no month/prev/next navigation, no event modals, no day-cell interaction — with only a console parse error to go on.

Cause: the calendar and the modal component both import micromodal, and Rollup hoists a module shared by two entries into dist/assets/. Webpack inlined it per entry, which is why this was a plain script before and why the library never needed a micromodal dependency.

I swept all 30 component-library dist files this theme loads — the calendar is the only one affected. (yds-modal.js is also an ES module but isn't loaded here.)

Fix: attributes: { type: module } plus preprocess: false on that one file, with a comment recording the why. Module scripts are deferred but execute after parsing and before DOMContentLoaded, and Drupal attaches behaviours on DOMContentLoaded, so the behaviour registers in time; preprocess: false keeps aggregation from concatenating a module into a classic bundle.

I did not fix it on the build side: Rollup deliberately dedupes a module imported by two entries and offers no supported way to duplicate a static import back into each one.

Verified

All 30 dist/... paths this file references exist in a fresh build (0 missing), and dist/assets/icons.svg is present for the sprite path. component-library-twig #672 now carries a test that fails when the set of ES modules under dist/js/ changes, so the next occurrence surfaces there rather than as an inert component in production.

Please click through the events calendar on the multidev before merging — this is the one thing a build-and-diff review can't confirm, and I couldn't exercise it locally because this checkout's node_modules/@yalesites-org/component-library-twig symlinks to a different, stale checkout.

Merge after component-library-twig #672 and before yalesites-project #1413.

[dblanken-yale]

Pushed one follow-up commit here (a8ef4a30) — comment-only, no behaviour change.

The type: module rationale was written out in three places across two repos, and the cross-repo copy is the one that drifts unnoticed. Trimmed this one to what a Drupal developer reading atomic.libraries.yml actually needs — why this single script is a module and what breaks without it — and pointed at scripts/dist-module-format.test.mjs in component-library-twig, which enforces the contract and carries the full explanation.

Also worth recording here: I verified that dist/assets/micromodal.es-*.js — the chunk yds-calendar.js imports — does ship in the published component-library package and resolves correctly from the calendar file's relative specifier. I checked inside the extracted npm pack tarball, so the type: module fix isn't undermined by a missing import target.

The events calendar still wants a human click-through on the multidev before merge; I couldn't exercise it locally because this checkout's node_modules/@yalesites-org/component-library-twig symlinks to a different, stale checkout. The project multidev has been rebuilt against these companions and is green.