vue-lynx/plugin / PluginVueLynxOptions
#Interface: PluginVueLynxOptions
Options for pluginVueLynx.
#Properties
| Property | Type | Default value | Description | Defined in |
|---|---|---|---|---|
optionsApi? | boolean | true | Whether to enable Vue's Options API support. Disabling it reduces bundle size. | index.ts:55 |
prodDevtools? | boolean | false | Whether to enable Vue devtools in production builds. | index.ts:61 |
enableCSSSelector? | boolean | true | Whether to enable CSS selector support in the Lynx template. When enabled, CSS from Vue <style> blocks and imported CSS files will be compiled into the Lynx bundle and applied via class selectors. | index.ts:69 |
enableCSSInheritance? | boolean | false | Whether to enable CSS inheritance in the Lynx engine. When enabled, CSS property values (including CSS custom properties / variables) cascade from parent elements to children, matching standard CSS behavior. Required for design-token patterns where CSS variables are set on a parent and consumed by descendants. | index.ts:79 |
customCSSInheritanceList? | string[] | undefined | A list of additional CSS properties to inherit beyond the engine defaults. Only effective when enableCSSInheritance is true. | index.ts:86 |
enableCSSInlineVariables? | boolean | false | Whether to enable CSS custom properties (variables) in inline styles. When enabled, setting --* properties via :style bindings will be recognized by the Lynx engine at runtime. | index.ts:94 |
debugInfoOutside? | boolean | true | Whether to place debug info outside the template bundle. Reduces template size in dev builds. | index.ts:101 |
autoPixelUnit? | boolean | true | Whether to automatically append 'px' to numeric style values (e.g. fontSize: 24 → '24px'). Dimensionless properties like flex, opacity, and zIndex are never converted. This convenience behavior is deprecated and will default to false in the next major version. Prefer explicit string units (e.g. fontSize: '24px'). Deprecated Will default to false in the next major version. | index.ts:115 |
enableElementTemplates? | boolean | enableIFR | Whether to enable element templates (compile-time template lowering). Eligible template subtrees — plain elements with compile-time-known structure — are lowered into "element templates": the static skeleton becomes a straight-line element-creation function executed on the main thread via a single INSTANTIATE_TEMPLATE op, and interior dynamic parts ("holes") receive deterministic ids updated through the ordinary ops. This removes the per-static-node vdom/ops/interpreter cost on first render and shrinks the cross-thread payload — for both the normal pipeline and IFR (they compose). Structural features (components, v-if/v-for hosts, slots, refs, directives, <list>) always stay on the normal vdom path; lowering is purely an optimization and never changes rendering semantics. Defaults to the value of enableIFR: enabling IFR also enables element templates unless this option is explicitly set to false. It can still be enabled independently when IFR is off. | index.ts:139 |
enableIFR? | boolean | false | Whether to enable IFR (Instant First-Frame Rendering). When enabled, the main-thread bundle contains the full Vue runtime and app code (instead of only worklet registrations). The first screen is rendered synchronously on the main thread during loadTemplate — before any background JavaScript runs — eliminating the blank-frame gap. When the background thread boots, its initial render is hydrated against the main-thread output instead of being re-applied. Constraints (matching ReactLynx IFR): - First-screen render output must be deterministic and thread-agnostic (no Math.random() / Date.now() in render, no thread-dependent branching). Divergence is detected and falls back to a full background render, losing the IFR benefit for that screen. - Side effects belong in lifecycle hooks (onMounted, watch callbacks) — these never run during the main-thread render. - Increases the main-thread bundle size (it now carries the Vue runtime). See https://lynxjs.org/guide/interaction/ifr | index.ts:164 |
includeWorkletPackages? | readonly (string | RegExp)[] | [] | Allowlist of bare-import specifiers whose 'main thread' worklets should be reached by the MT bundler. The worklet loader follows relative imports (./foo, ../bar) and resolves non-relative imports: path aliases and tsconfig paths that point at project source (outside node_modules) are followed automatically. Imports resolving INTO node_modules are dropped by default — list the package names (or RegExps matching them) here to follow worklets shipped as a published/installed package. Both checkpoints reduce their input to the package root before matching, so a pattern always matches the package name (e.g. '@my-org/foo'), never a subpath or the resolved filesystem path: - strings match the root exactly — '@vue-lynx/motion-mini' covers the package and all its subpath imports, but NOT '@vue-lynx/motion-mini-x'; - a RegExp like /^@my-org// matches whether the package is reached as an import or carved out of the node_modules loader exclude. Example pluginVueLynx({ includeWorkletPackages: ['@vue-lynx/motion-mini', /^@my-org/lynx-/], }) | index.ts:194 |