Follow-up from the review of #306.
The problem
ModuleOptions declares a public version option:
// src/module.ts:32
version?: string
The Nuxt module never reads it. It assigns the constant imported from the package manifest instead:
// src/module.ts:9
import { name, version } from '../package.json'
// ...
// src/module.ts:209
nuxt.options.appConfig.version = version
The Vite/unplugin entry point, on the other hand, does honour the user's value:
// src/unplugin.ts:100
version: options.version,
So the same public, typed option works through one entry point of the package and is silently dropped in the other.
Why it matters
appConfig.version is what src/runtime/plugins/ui-version.ts renders into <meta name="b24ui" content="...">. A user who sets
// nuxt.config.ts
b24ui: { version: '1.2.3-custom' }
gets no error, no warning, and no effect — the meta tag keeps showing the packaged version. The type promises configurability that the Nuxt path does not provide.
Additionally, version?: string is the only field in that interface with no JSDoc — every neighbouring option carries @defaultValue or an @see link (compare colorModeStorageKey just above it and theme just below). So there is not even prose telling the reader what it is for.
Options
- Honour it, keeping the current value as the default:
nuxt.options.appConfig.version = options.version ?? version
This makes the two entry points consistent and matches what the type already claims.
- Document it as reserved — add JSDoc saying the option applies to the Vite plugin only and is ignored by the Nuxt module.
- Remove it from the Nuxt-facing type if it was never meant to be configurable there.
Option 1 looks right: the default is already the package version, so honouring an explicit value is a strict improvement and not a breaking change for anyone who never set it.
Whichever is chosen, the field should get a JSDoc comment like its neighbours.
Not urgent
Cosmetic in effect — it only influences a <meta> tag. Raised because a public typed option that silently does nothing is the kind of thing that costs someone an afternoon.
Follow-up from the review of #306.
The problem
ModuleOptionsdeclares a publicversionoption:The Nuxt module never reads it. It assigns the constant imported from the package manifest instead:
The Vite/unplugin entry point, on the other hand, does honour the user's value:
So the same public, typed option works through one entry point of the package and is silently dropped in the other.
Why it matters
appConfig.versionis whatsrc/runtime/plugins/ui-version.tsrenders into<meta name="b24ui" content="...">. A user who setsgets no error, no warning, and no effect — the meta tag keeps showing the packaged version. The type promises configurability that the Nuxt path does not provide.
Additionally,
version?: stringis the only field in that interface with no JSDoc — every neighbouring option carries@defaultValueor an@seelink (comparecolorModeStorageKeyjust above it andthemejust below). So there is not even prose telling the reader what it is for.Options
Option 1 looks right: the default is already the package version, so honouring an explicit value is a strict improvement and not a breaking change for anyone who never set it.
Whichever is chosen, the field should get a JSDoc comment like its neighbours.
Not urgent
Cosmetic in effect — it only influences a
<meta>tag. Raised because a public typed option that silently does nothing is the kind of thing that costs someone an afternoon.