The plugin model
Why capability enablement controls native output.
A manifest connects a JavaScript command contract to native implementations. The same Effect Schema codecs supply argument types, result validation, and rejection mapping.
flowchart TD Custom[Config plugins: custom manifest paths] --> Resolve[Resolve enabled manifests] Internal[internalPlugins flags and registry defaults] --> Resolve Push[pushNotifications] --> Notifications[notifications] Notifications --> Network[network] Network --> Internal Resolve --> Validate[Validate schemas, options, and installed dependency versions] Validate --> Clients[virtual:radical/plugins and plugins.d.ts] Validate --> Plan[Compose native build contributions] Plan --> Sources[Enabled sources and native registration] Plan --> Deps[npm, Gradle, and SPM requirements] Plan --> Config[Permissions, plist, entitlements, and runtime defines] Plan -->|Conflicting contributions| Fail[Generation failure]
Custom plugins stay disabled until listed in config. Internal device and transitions default to enabled; other capabilities are opt-in. Required implications override explicit false flags.
Build contracts and runtime contracts stay separate
Browser-safe manifests describe commands. Build-only contributions add camera descriptions, Firebase files, entitlements, and runtime defines. Conflicting plist values fail generation instead of depending on plugin order.
Generated clients preserve schema-derived types. Type generation neither installs missing packages nor implements native methods. Changing the plugin set requires native regeneration.
Add a typed native plugin contains the authoring procedure. Plugin manifest reference lists fields and error rules.