matryer/xbar · warning

Variables: ${v.name} has unsupported type ${v.type} (skippin

Error message

Variables: ${v.name} has unsupported type ${v.type} (skipping)

What it means

This is a client-side console.warn emitted by updateValues() in InstalledPluginView.svelte while seeding default values for an installed plugin's variables. The code switches on v.type and only knows 'string', 'select', 'boolean', and 'number'; any other type string hits the default branch and the variable is skipped (no default value is written into the values object). It is not an exception — the UI continues rendering, but the variable will have no initialized value.

Source

Thrown at app/frontend/src/InstalledPluginView.svelte:86

		if (!variables || !values) return; // wait for both
		variables.forEach((v) => {
			if (typeof values[v.name] !== 'undefined') {
				return;
			}
			switch (v.type) {
				case 'string':
				case 'select':
					values[v.name] = v.default;
					break;
				case 'boolean':
					const def = v.default || '';
					values[v.name] = def.toUpperCase() == 'TRUE';
					break;
				case 'number':
					values[v.name] = parseFloat(v.default) || 0;
					break;
				default:
					console.warn(
						`Variables: ${v.name} has unsupported type ${v.type} (skipping)`
					);
			}
		});
	}

	function onValuesChanged() {
		saveVariableValues(installedPlugin.path, variableValues);
	}

	let pluginEnableToggleWaiter = 0;
	function toggleEnabled() {
		pluginEnableToggleWaiter++;
		installedPlugin.enabled = !installedPlugin.enabled;
		setEnabled(installedPlugin.path, installedPlugin.enabled)
			.then((updatedPath) => {
				// redirect to new place
				selectedInstalledPluginPath.set(updatedPath);

View on GitHub (pinned to d624239058)

Solutions

1. Fix the variable's type in the plugin's metadata so it is exactly one of 'string', 'select', 'boolean', or 'number' (check for typos, casing, and trailing whitespace).
2. Add a case for the new type in updateValues() in app/frontend/src/InstalledPluginView.svelte:73 so the variable gets a sensible default instead of being skipped.
3. Normalize the type before the switch (e.g. v.type.trim().toLowerCase()) to tolerate formatting differences in plugin metadata.
4. Give the variable a fallback default (e.g. treat unknown types as strings) if skipping leaves the UI in a broken state.

Example fix

// before
default:
    console.warn(
        `Variables: ${v.name} has unsupported type ${v.type} (skipping)`
    );
// after
default: {
    console.warn(
        `Variables: ${v.name} has unsupported type ${v.type} (skipping)`
    );
    values[v.name] = v.default ?? ''; // treat unknown types as strings
}

const SUPPORTED_TYPES = ['string', 'select', 'boolean', 'number'];
const unsupported = (plugin.vars || []).filter(v => !SUPPORTED_TYPES.includes(String(v.type).trim().toLowerCase()));
if (unsupported.length) {
    console.warn('Unsupported variable types:', unsupported.map(v => `${v.name}:${v.type}`));
}

function isSupportedVarType(type) {
    return ['string', 'select', 'boolean', 'number'].includes(String(type).trim().toLowerCase());
}

When it happens

Trigger: A plugin's metadata (installedPlugin.vars) contains a variable whose v.type is not one of 'string', 'select', 'boolean', or 'number' — e.g. a typo like 'bool', 'string ' with trailing whitespace, 'int', 'list', uppercase 'String', or a newer variable type added by the plugin API that this view does not handle yet.

Common situations: Plugin authors misspelling or capitalizing the type in their plugin manifest/metadata; a plugin schema evolved to add new types (e.g. arrays or secret) while the frontend switch was not updated; stale plugin metadata cached from an older format; copy-pasted type names from another plugin system.

AI-assisted analysis of matryer/xbar@d624239058 (2026-09-02). Data as JSON: /api/errors/a84d48161774040f. Report an issue: GitHub.