Extend declarative configuration UI controls #42

New issue

Closed

opened 2026-05-21 06:27:44 +00:00 by steve · 0 comments

steve commented

2026-05-21 06:27:44 +00:00

Owner

Expand manifest-declared configuration schema rendering so plugins can use
normal settings controls without custom DOM for common settings surfaces.

Context

The configuration system already supports schema-backed settings. New Lapis
plugins should be able to express common settings declaratively, while the
trusted DOM compatibility path remains available for Obsidian-style custom
settings tabs.

Acceptance Criteria

Configuration schemas support enum/select, array-of-enum multiselect,
numeric ranges, color values, object groups, and descriptions.
Settings UI renders each supported schema shape with an appropriate control.
Defaults are applied on first load and preserved across reloads.
Invalid enum, range, and array values are rejected with useful validation
messages.
Plugin-owned setting keys remain namespaced and uninstall-safe.
Tests cover every new control type, default application, validation, and
persistence.
The configuration spec documents supported schema features and fallback
behavior for unsupported schema shapes.
Settings components use the same shadcn/svelte components as the rest of the
application. Re-use anything in packages/ui as required and import any useful
components from shadcn/svelte that don't exist in the ui package.
Components should follow the same css styling as the rest of the app.

Notes

This reduces pressure to use plugin-owned DOM for routine settings UI.

Implementation Summary

Expanded declarative configuration schemas with nested object groups, enum-array multiselects, runtime validation/default materialization, schema-driven workspace controls, and updated spec coverage.

Expand manifest-declared configuration schema rendering so plugins can use normal settings controls without custom DOM for common settings surfaces. ## Context The configuration system already supports schema-backed settings. New Lapis plugins should be able to express common settings declaratively, while the trusted DOM compatibility path remains available for Obsidian-style custom settings tabs. ## Acceptance Criteria - Configuration schemas support enum/select, array-of-enum multiselect, numeric ranges, color values, object groups, and descriptions. - Settings UI renders each supported schema shape with an appropriate control. - Defaults are applied on first load and preserved across reloads. - Invalid enum, range, and array values are rejected with useful validation messages. - Plugin-owned setting keys remain namespaced and uninstall-safe. - Tests cover every new control type, default application, validation, and persistence. - The configuration spec documents supported schema features and fallback behavior for unsupported schema shapes. - Settings components use the same shadcn/svelte components as the rest of the application. Re-use anything in `packages/ui` as required and import any useful components from `shadcn/svelte` that don't exist in the ui package. - Components should follow the same css styling as the rest of the app. ## Notes This reduces pressure to use plugin-owned DOM for routine settings UI. ## Implementation Summary Expanded declarative configuration schemas with nested object groups, enum-array multiselects, runtime validation/default materialization, schema-driven workspace controls, and updated spec coverage.

steve added the

labels

2026-05-21 06:27:44 +00:00

steve referenced this issue

2026-05-21 09:40:03 +00:00

Fold list-callout into markdown plugin #58

steve