Alpine.js and Asynchronous Bundlers: Component Initialization Timing

Direct answer

Alpine.js does not wait for other bundles. With the default Alpine.js v3 auto-start build, the library evaluates x-data at boot: on DOMContentLoaded if the document is still parsing, or immediately if parsing is already complete. It initializes elements present at boot and does not automatically retry elements whose evaluation already failed. If your production bundle loads Alpine with defer or async while the data those expressions depend on arrives in a later bundle, Alpine can boot before the data exists, leaving components non-functional in production even when synchronous end-of-body scripts worked in development.

Confirmed behavior versus likely explanation

Confirmed (default Alpine.js v3)

• Boot timing is tied to document readiness, not to other scripts or bundles.
• x-data expressions are evaluated once during initialization; failed evaluations are not retried automatically.
• Lifecycle hooks observe initialization but do not provide a standard mechanism to pause boot for bundler-initialized data.

Likely explanation for the production gap

Local development often loads scripts synchronously at the end of <body>. Production build tools commonly emit defer or asynchronous entry points. A deferred script can run after DOMContentLoaded has already fired, so a listener that waits for that event is not a reliable sequencing gate. The data bundle may therefore resolve after Alpine has already evaluated x-data on the page.

Steps for this case

1. Confirm how Alpine is loaded: global <script defer src> tag or ESM import, and whether the missing data comes from a separate async bundle. This detail changes the fix.
2. If the data is available synchronously, define it in an inline script or register it with Alpine.data before the Alpine script tag or import is evaluated.
3. If the data is asynchronous, delay Alpine entirely: resolve the data promise first, then dynamically import Alpine or inject and run the Alpine script, so x-data evaluation happens after the data exists.
4. Do not place data initialization in a DOMContentLoaded listener that runs after Alpine is imported; that is too late for existing x-data markup.
5. Do not call Alpine.start() expecting it to repair components that already failed. Re-initialize only newly added subtrees, or reload the page after correcting script order.

Verification

• Check the installed version and loading mode, for example npm ls alpinejs and inspect your build output for defer, async, or dynamic import().
• Reproduce on a staging page with cache disabled and a simulated slow network: load Alpine before the data bundle, confirm missing bindings or console errors, then reorder so data precedes Alpine and confirm bindings attach.
• Use Alpine lifecycle observers only to confirm boot timing; they do not supply data to expressions evaluated earlier.

Assumption: this answer covers default Alpine.js v3 auto-start behavior. Custom builds, major-version differences, or bundler plugins that control Alpine.start() manually may change boot timing and require a different approach.

Missing diagnostic detail: Is Alpine loaded as a global deferred script tag or as an ESM import, and is the missing data produced by a separate async bundle?