Split the frontend helpers.js into $conditions and $passkeys entry points #1479

helpers.js gives you two things:

• $conditions, which evaluates a field's conditions against the form's values.
• $passkeys, a WebAuthn client wrapping @simplewebauthn/browser, for passkey registration and login.

They're unrelated, and the docs put them in different places:

• The form:create docs say to add the script to your layout just before </body>, so for conditional fields it ends up on every page.
• The user:login_form docs say to include it on the page with your login form.

Either way you end up sending a fair bit you never call:

• If you're using conditional fields, every anonymous visitor gets a WebAuthn client, on every page.
• If you're using passkeys, your login page carries the conditions evaluator.

Short of building your own bundle there's no way to take one without the other.

The file is around 99 KB today, but most of that is a separate problem I've reported as statamic/cms#15173: marked and DOMPurify ride in through a barrel import, and nothing on the public side calls either. With that fixed the bundle is about 28 KB, and the WebAuthn client is roughly 9 KB of it.

So this isn't a big number on its own. It's about a third of what's left, on every page, whether or not the site uses passkeys at all.

It wasn't always both. resources/js/frontend/helpers.js was created for field conditions back in January 2022, and passkeys landed in April 2026.

Possible shapes

Separate entry points

Publish conditions.js and passkeys.js next to helpers.js and leave helpers.js alone, so nothing changes for anyone already including it. The two new files would each need to merge into window.Statamic instead of replacing it, so a page that pulls in more than one still works.

The wrinkle is the build. vite-frontend.config.js uses formats: ['umd'], and Vite's lib mode only takes one entry for UMD, so more than one output means more than one build, or a different format.

Lazy-load the WebAuthn client

Importing it inside $passkeys on first use would work too, and wouldn't change any published paths. Probably the smaller change, though it does mean a round trip when someone starts a passkey flow. It only helps one direction, though: a login page would still carry the conditions evaluator.