Modules
Everything Vueform does beyond its data layer — Validation, Conditions, HTTP, Dates, Locales, theming — is a Module, an implementation the core looks up by key on the Vueform Instance instead of importing directly. The core only defines the interface each key must satisfy, so whatever is registered under a key is what runs. That makes Modules dependency injection at the framework level, and the lever for two things — bundle size, because unused Modules stay out of the build, and control, because any built-in behavior can be replaced without touching the rest.
Registering Modules
The Full Bundle registers every built-in Module, so there is nothing to do there. The bare @vueform/ui entry in Modular Setup registers none, and you pass them under the modules config option yourself:
import { createVueform } from '@vueform/ui'
import { model, validation, conditions } from '@vueform/ui/modules'
createVueform({
modules: { model, validation, conditions },
})The rest of a Modular Setup — components, rules, adapters, and what each part costs — is covered in Code-Splitting.
modules merges per key over the entry's set, so on the Full Bundle passing one key replaces only that Module and keeps every other built-in — the mechanism Swapping a Module builds on.
Each Module reads its options from a $-prefixed config key named after it — $http, $conditions, $security, and so on — listed in Configuration. A non-empty $<name> object in your config without a registered <name> Module warns in development, since the options read as if they were in effect.
The Built-in Modules
Most Modules are documented where their feature lives, so the table links each one to its home:
| Module | Provides | Without it |
|---|---|---|
model | The form data layer | Required — see leaving a Module out. |
validation | Rules and validators | Everything counts as valid — warns once in dev when an element has rules. |
conditions | Conditional availability and conditional props | Every Condition counts as met. |
expression | {...} templates and Expression Conditions | Strings pass through as literal text — warns once in dev when a feature needs an engine. |
autosave | Remote Autosave and local Drafts | The autosave and draft props have no effect (warns once in dev), and the form's Autosave and Draft methods no-op. |
http | Network requests | Every request rejects with a "not registered" error. |
date | Date parsing and comparison | useDate(), date Conditions, date rules, and date Expression functions throw. |
i18n | Framework strings and localization | Built-in strings show their raw tags, Locale Maps fall back to their first entry, and switching the Locale warns in dev. |
theme | Token CSS generation, injection, and dark mode | No Token CSS is generated or injected — a tokens prop warns once in dev. |
router | Browser-history sync for multi-page forms | Navigation doesn't touch the URL — warns once in dev when history tracking is enabled. |
security | HTML/component gating, sanitization, origin policy, ciphers | Nothing is enforced — see The Security Module. |
Leaving a Module Out
model is the one Module Vueform can't run without, since every other Module builds on the data layer. The Bare Entry's createVueform doesn't type-check a config without modules.model and throws at runtime.
Every other Module is optional, and a missing one never breaks the code. Consumers read an inert stand-in in its place, so the outcome is one of two kinds, per the table's last column:
- Most degrade to "the feature isn't there" — Conditions are met, everything is valid, strings stay literal. Where a config or prop shows clear intent —
rulesset, atokensprop passed, a locale switch, history tracking turned on — development warns once. httpanddatehave no sensible fallback, so they fail at the point of use. Anhttprequest rejects — getting the client never throws, so forms that never hit the network keep working — anddatethrows as soon as a date is needed.
security is the one exception where configuration changes the outcome, because a policy configured without the Module fails closed in production — see The Security Module.
Replacing a Module's engine, swapping one out, or writing your own is covered in In-Depth Modules.