Follow-up from #313, which is now closed: plugins/**/**.spec.ts is in the vitest nuxt project and test/plugins/ sits at 15/15 after #324 and #327.
Three things were deliberately left out of those PRs, each because it needs a test fixture this repo does not have yet. None is a defect — they are the places where a regression would still be invisible. Filing them so they are not rediscovered the next time something ships broken.
1. b24ui.version never goes through the module's real setup() (#314)
#324 fixed #314 by honouring the option:
// src/module.ts:217
nuxt.options.appConfig.version = options.version ?? version
test/plugins/ui-version.spec.ts covers the consuming half — the plugin renders whatever appConfig.version holds, including a custom value — but nothing exercises the line that puts the value there, which is where the bug actually lived.
Calling the module's setup() directly does not work: defineNuxtModule merges defaults through defu before setup() runs, and the body reaches for @nuxt/kit's ambient Nuxt context (addPlugin, installModule, …), which exists only inside a running Nuxt instance.
What it needs: a loadNuxt fixture — boot a throwaway Nuxt with the module registered and b24ui: { version: '1.2.3-custom' } in the config, then assert appConfig.version. That is a new test shape here (every current spec mounts a component inside the nuxt vitest environment), so it is a small infrastructure decision rather than a one-line spec.
Why bother: #314 is the class of bug where a public, typed option silently does nothing. There is no failure signal at all — no error, no warning, just a <meta> tag showing the wrong value.
2. platform.ts — the SSR branch is unreachable from the test runner
// src/runtime/plugins/platform.ts:47-49
const ua = import.meta.server
? useRequestHeader('user-agent')
: navigator.userAgentThe client half is covered: Bitrix Mobile, Bitrix Desktop and plain-web user agents, marker precedence when a UA carries both, the useState cache guard that skips re-parsing on client navigation, and the htmlAttrs getters. The server half never runs — the nuxt vitest environment is client-only, so import.meta.server is always false and useRequestHeader is never called.
This matters a little more than it looks: data-platform / data-version are what the Tailwind variants (bitrix-mobile:, bitrix-desktop:) key on, so a broken SSR branch means a flash of wrong styling on first paint in exactly the environment b24ui is built for — inside a Bitrix24 application frame.
What it needs: an SSR fixture — @nuxt/test-utils setup() with server: true, a route rendered with a BitrixMobile/Version=… user-agent header, asserting the <html> attributes in the returned markup.
3. Nothing in CI boots the package
Raised in #313 and still true: ci.yml runs lint → typecheck → test → build. No step starts a real application.
#301 — the crash that started this whole series — was a client-only boot failure. The unit suite stayed green for five weeks while the published package could not start an SPA. test/plugins/colors.spec.ts now catches that regression specifically (verified by reintroducing the bug and watching the spec fail), but only that one; the class of "builds fine, dies on boot" is still uncovered.
What it needs: a smoke layer — build a playground, serve it, load the page with Playwright, fail on any console error. The build half already exists: npm-publish.yml builds both playgrounds before publishing. What is missing is loading the result in a browser.
Suggested order
Items 2 and 3 are the same missing piece seen from two sides — an SSR/e2e fixture that exists for one is most of the work for the other, so they are best decided together. Item 1 is independent and is the cheapest of the three once someone picks the fixture style.
Ranked by what they would actually catch: 3 covers the widest class of failure, 1 protects a fix that has no other signal, 2 comes nearly free alongside 3.
Follow-up from #313, which is now closed:
plugins/**/**.spec.tsis in the vitestnuxtproject andtest/plugins/sits at 15/15 after #324 and #327.Three things were deliberately left out of those PRs, each because it needs a test fixture this repo does not have yet. None is a defect — they are the places where a regression would still be invisible. Filing them so they are not rediscovered the next time something ships broken.
1.
b24ui.versionnever goes through the module's realsetup()(#314)#324 fixed #314 by honouring the option:
test/plugins/ui-version.spec.tscovers the consuming half — the plugin renders whateverappConfig.versionholds, including a custom value — but nothing exercises the line that puts the value there, which is where the bug actually lived.Calling the module's
setup()directly does not work:defineNuxtModulemergesdefaultsthrough defu beforesetup()runs, and the body reaches for@nuxt/kit's ambient Nuxt context (addPlugin,installModule, …), which exists only inside a running Nuxt instance.What it needs: a
loadNuxtfixture — boot a throwaway Nuxt with the module registered andb24ui: { version: '1.2.3-custom' }in the config, then assertappConfig.version. That is a new test shape here (every current spec mounts a component inside the nuxt vitest environment), so it is a small infrastructure decision rather than a one-line spec.Why bother: #314 is the class of bug where a public, typed option silently does nothing. There is no failure signal at all — no error, no warning, just a
<meta>tag showing the wrong value.2.
platform.ts— the SSR branch is unreachable from the test runnerThe client half is covered: Bitrix Mobile, Bitrix Desktop and plain-web user agents, marker precedence when a UA carries both, the
useStatecache guard that skips re-parsing on client navigation, and thehtmlAttrsgetters. The server half never runs — the nuxt vitest environment is client-only, soimport.meta.serveris always false anduseRequestHeaderis never called.This matters a little more than it looks:
data-platform/data-versionare what the Tailwind variants (bitrix-mobile:,bitrix-desktop:) key on, so a broken SSR branch means a flash of wrong styling on first paint in exactly the environment b24ui is built for — inside a Bitrix24 application frame.What it needs: an SSR fixture —
@nuxt/test-utilssetup()withserver: true, a route rendered with aBitrixMobile/Version=…user-agent header, asserting the<html>attributes in the returned markup.3. Nothing in CI boots the package
Raised in #313 and still true:
ci.ymlrunslint → typecheck → test → build. No step starts a real application.#301 — the crash that started this whole series — was a client-only boot failure. The unit suite stayed green for five weeks while the published package could not start an SPA.
test/plugins/colors.spec.tsnow catches that regression specifically (verified by reintroducing the bug and watching the spec fail), but only that one; the class of "builds fine, dies on boot" is still uncovered.What it needs: a smoke layer — build a playground, serve it, load the page with Playwright, fail on any console error. The build half already exists:
npm-publish.ymlbuilds both playgrounds before publishing. What is missing is loading the result in a browser.Suggested order
Items 2 and 3 are the same missing piece seen from two sides — an SSR/e2e fixture that exists for one is most of the work for the other, so they are best decided together. Item 1 is independent and is the cheapest of the three once someone picks the fixture style.
Ranked by what they would actually catch: 3 covers the widest class of failure, 1 protects a fix that has no other signal, 2 comes nearly free alongside 3.