Skip to content

bug(module): b24ui.version is honoured by the Vite plugin but silently ignored by the Nuxt module #314

Description

@IgorShevchik

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

  1. 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.
  2. Document it as reserved — add JSDoc saying the option applies to the Vite plugin only and is ignored by the Nuxt module.
  3. 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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions