Fix vault-wide property rename semantics and metadata type bookkeeping #66

New issue

Closed

opened 2026-05-21 13:29:36 +00:00 by steve · 0 comments

steve commented

2026-05-21 13:29:36 +00:00

Owner

Harden MetadataTypeManager property renames so vault-wide frontmatter updates,
metadata indexes, and types.json stay consistent for top-level and nested
properties.

Context

Audit findings from the current implementation:

MetadataTypeManager.rename(prevId, newId) uses prevId.split(".")[0] to find
the tracked property and then iterates that top-level property's files. Nested
paths can miss files or rely on the wrong property index.
renameProperty() moves values with lodash get/unset/set, but there is
no coverage for nested paths, collisions, falsey values, arrays, or destination
paths that already exist.
The UI duplicate check uses get(frontmatterData, newId) and isNil, so an
existing destination value of null or undefined is treated as absent while
other falsey values rely on lodash path semantics.
Renaming a persisted typed property does not appear to rename the corresponding
types.json entry or clean up stale properties/files state immediately.
processChange() only adds file membership; it does not remove a file from
old property entries when a note changes and drops/renames a property unless a
delete event runs.
There are no focused unit tests for MetadataTypeManager.rename(),
processChange() membership cleanup, or type-definition migration.

Acceptance Criteria

Property rename resolves the exact property path being renamed and enumerates
the correct affected files for top-level and nested properties.
Rename semantics explicitly handle destination collisions, falsey values,
arrays/object paths, and missing files.
Persisted type definitions in types.json are moved from the old property name
to the new name when applicable.
Runtime properties membership and counts converge immediately after property
update, removal, or rename without requiring a full cache rebuild.
The rename API reports partial failures in a way UI callers can surface.
Unit tests cover top-level renames, nested renames, collision prevention,
falsey values, type migration, and property membership cleanup.

Notes

Relevant files:

packages/api/src/lib/metadata.svelte.ts
packages/plugins/plugin-markdown/src/lib/components/frontmatter/frontmatter.svelte
packages/api/src/lib/file-manager.ts

Implementation Summary

Hardened MetadataTypeManager rename semantics for nested and falsey values, prevented destination collisions, migrated persisted type definitions, cleaned up runtime property membership, and added focused rename/index regression tests.

Harden `MetadataTypeManager` property renames so vault-wide frontmatter updates, metadata indexes, and `types.json` stay consistent for top-level and nested properties. ## Context Audit findings from the current implementation: - `MetadataTypeManager.rename(prevId, newId)` uses `prevId.split(".")[0]` to find the tracked property and then iterates that top-level property's files. Nested paths can miss files or rely on the wrong property index. - `renameProperty()` moves values with lodash `get`/`unset`/`set`, but there is no coverage for nested paths, collisions, falsey values, arrays, or destination paths that already exist. - The UI duplicate check uses `get(frontmatterData, newId)` and `isNil`, so an existing destination value of `null` or `undefined` is treated as absent while other falsey values rely on lodash path semantics. - Renaming a persisted typed property does not appear to rename the corresponding `types.json` entry or clean up stale `properties`/`files` state immediately. - `processChange()` only adds file membership; it does not remove a file from old property entries when a note changes and drops/renames a property unless a delete event runs. - There are no focused unit tests for `MetadataTypeManager.rename()`, `processChange()` membership cleanup, or type-definition migration. ## Acceptance Criteria - Property rename resolves the exact property path being renamed and enumerates the correct affected files for top-level and nested properties. - Rename semantics explicitly handle destination collisions, falsey values, arrays/object paths, and missing files. - Persisted type definitions in `types.json` are moved from the old property name to the new name when applicable. - Runtime `properties` membership and counts converge immediately after property update, removal, or rename without requiring a full cache rebuild. - The rename API reports partial failures in a way UI callers can surface. - Unit tests cover top-level renames, nested renames, collision prevention, falsey values, type migration, and property membership cleanup. ## Notes Relevant files: - `packages/api/src/lib/metadata.svelte.ts` - `packages/plugins/plugin-markdown/src/lib/components/frontmatter/frontmatter.svelte` - `packages/api/src/lib/file-manager.ts` ## Implementation Summary Hardened MetadataTypeManager rename semantics for nested and falsey values, prevented destination collisions, migrated persisted type definitions, cleaned up runtime property membership, and added focused rename/index regression tests.

steve

2026-05-21 13:29:36 +00:00