Modules
Modules are Formie's browser enhancement layer.
They add client-side behavior to a form, field, or provider integration after the base HTML has rendered. Built-in modules are lazy-loaded when a form needs them, and some also load module-owned CSS or third-party SDKs as part of setup.
A module is defined by an id such as date-picker or stripe, a module definition with match() and setup() functions, and one or more manifest targets telling Formie where the module should attach.
For your own modules, the public workflow is to provide src so Formie can import your module file. Built-in module manifests are generated by Formie for you, so consumers usually do not need to author or edit id-only manifest markup directly.
Module manifest shape
This is the manifest shape Formie reads from data-formie-modules:
type FormModuleManifest = {
id: string;
src?: string;
type: string;
targets?: Array<{
targetType: 'form' | 'field' | 'page' | 'button' | 'selector';
targetId: string;
}>;
config?: Record<string, unknown>;
};Targeting modules
Formie supports these target types:
formfor the whole form rootfieldfor a field handle such asprojectBriefpagefor a page idbuttonfor a button action such asnext-pageselectorfor a CSS selector scoped inside the current form
Field modules usually target a field handle, provider modules usually target the form root, and selector-based targets stay scoped inside the current form.
When you are reading generated markup, targetId usually maps to a field handle, page id, button action, or the special form root target. For consumer-authored modules, use Build a custom module for the actionable src workflow rather than trying to hand-author built-in manifest markup.
Address, captcha, and payment modules often depend on provider configuration as much as markup, so their dedicated pages in this section are the better reference once you know which module family you need.