Environment
main at 5a06163d. Noticed while writing test/module/module-setup.spec.ts in #483.
Description
theme.prefix is a public, documented module option. At runtime it reaches the app config and is read back from there:
// src/utils/defaults.ts
export function getDefaultConfig(theme?: ModuleOptions['theme']) {
return {
prefix: theme?.prefix,
tv: { twMergeConfig: { prefix: theme?.prefix } }
}
}
// src/module.ts:224
nuxt.options.app.rootAttrs.class = [
nuxt.options.app.rootAttrs.class,
`${options.theme?.prefix ? options.theme.prefix + ':' : ''}isolate`
].filter(Boolean).join(' ')
The type does not know about it. AppConfig['b24ui'] resolves to MergedAppConfig<{ tv: { twMergeConfig: {} } }, AppConfigRuntimeUI> — tv is declared, prefix is not. So this is a type error against a value the module itself put there:
const appConfig = useAppConfig()
appConfig.b24ui.prefix
// ^ Property 'prefix' does not exist on type
// 'MergedAppConfig<{ tv: { twMergeConfig: {}; }; }, AppConfigRuntimeUI>'
The spec in #483 has to widen the read to assert it:
expect((b24ui as Record<string, unknown> | undefined)?.prefix).toBe('smoke')
with a comment saying which side is wrong, so the cast is not mistaken for a test problem.
Why it matters
prefix is how an app avoids Tailwind class collisions with a host page — the Bitrix24 frame being the case this fork exists for. Anyone reading it back in TypeScript to build a class name hits an error on correct code, and the workaround they will reach for is as any, which then hides the next change.
Suggested fix
Declare prefix alongside tv wherever AppConfigRuntimeUI / the b24ui app-config shape is written, so the declared type matches what getDefaultConfig returns. Then drop the cast in test/module/module-setup.spec.ts — the spec already asserts the value, so the type change has a test waiting for it.
Worth checking at the same time whether anything else getDefaultConfig writes is undeclared; prefix was found by writing one assertion, not by an audit.
Environment
mainat5a06163d. Noticed while writingtest/module/module-setup.spec.tsin #483.Description
theme.prefixis a public, documented module option. At runtime it reaches the app config and is read back from there:The type does not know about it.
AppConfig['b24ui']resolves toMergedAppConfig<{ tv: { twMergeConfig: {} } }, AppConfigRuntimeUI>—tvis declared,prefixis not. So this is a type error against a value the module itself put there:The spec in #483 has to widen the read to assert it:
with a comment saying which side is wrong, so the cast is not mistaken for a test problem.
Why it matters
prefixis how an app avoids Tailwind class collisions with a host page — the Bitrix24 frame being the case this fork exists for. Anyone reading it back in TypeScript to build a class name hits an error on correct code, and the workaround they will reach for isas any, which then hides the next change.Suggested fix
Declare
prefixalongsidetvwhereverAppConfigRuntimeUI/ theb24uiapp-config shape is written, so the declared type matches whatgetDefaultConfigreturns. Then drop the cast intest/module/module-setup.spec.ts— the spec already asserts the value, so the type change has a test waiting for it.Worth checking at the same time whether anything else
getDefaultConfigwrites is undeclared;prefixwas found by writing one assertion, not by an audit.