obsidian-plugin/jalad25_contact-note
1
0
Fork 0
mirror of https://github.com/jalad25/contact-note.git synced 2026-07-22 06:53:06 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

editorconfig update. Minor docs updates.

Browse source
This commit is contained in:
Jalad 2026-05-10 19:18:41 -05:00
parent 3c713cc035
commit ca43b4e562
3 changed files with 4 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
.editorconfig
View file

@ -8,3 +8,4 @@ insert_final_newline = true
indent_style = tab
indent_size = 2
tab_width = 2
trim_trailing_whitespace = true

3
.github/PULL_REQUEST_TEMPLATE/refactor.md vendored
View file

@ -33,6 +33,3 @@
- [ ] `npm run lint` passes.
- [ ] `npm run build` passes with no TypeScript errors.
- [ ] I have tested the affected areas in a local vault to confirm no regression.
- [ ] I have tested in both the sidebar contacts view and a contacts base view (`.base` file), if the change touches shared rendering or contact data.
- [ ] I have tested the affected UI in both light and dark mode (if any styles or DOM structure were touched).
- [ ] I have tested the affected behavior on both the Obsidian desktop application and the Obsidian mobile app (if relevant).

6
DEVELOPMENT.md
View file

@ -172,10 +172,10 @@ Both flows take `useFolder`, `folderPath`, `tag`, and the user-entered `viewName
Plugin configurations are versioned through [`ConfigurationSchemaMigration.ts`](src/ConfigurationSchemaMigration.ts). The `schemaVersion` field on `ContactNoteConfiguration` records the version of the data on disk, and `CURRENT_SCHEMA_VERSION` (defined in [`main.ts`](src/main.ts)) records the version the running code expects.
On every plugin load, `loadSettings()` runs the user's saved data through `migrate(...)`, which steps the data forward one version at a time using the entries in the `MIGRATIONS` array. If anything was migrated, the upgraded settings are written back to disk so the user only pays the migration cost once.
On every plugin load, `loadConfiguration()` runs the user's saved data through `migrate(...)`, which steps the data forward one version at a time using the entries in the `MIGRATIONS` array. If anything was migrated, the upgraded settings are written back to disk so the user only pays the migration cost once.
> [!IMPORTANT]
> Adding or removing a field that doesn't conflict with existing data does **not** require a migration. `loadSettings()` merges saved data over `DEFAULT_CONFIGURATION` (so new fields get their default) and drops keys that aren't in `DEFAULT_CONFIGURATION` (so removed fields disappear from `data.json` on the next save). A migration is only needed when an existing field needs to be renamed, restructured, or replaced with a non-default value.
> Adding or removing a field that doesn't conflict with existing data does **not** require a migration. `loadConfiguration()` merges saved data over `DEFAULT_CONFIGURATION` (so new fields get their default) and drops keys that aren't in `DEFAULT_CONFIGURATION` (so removed fields disappear from `data.json` on the next save). A migration is only needed when an existing field needs to be renamed, restructured, or replaced with a non-default value.
### Adding a new migration
@ -213,7 +213,7 @@ See [CONTRIBUTING.md](CONTRIBUTING.md) for the full workflow, including how to f
## Releasing
> [!IMPORTANT]
> [!IMPORTANT]
> Releasing is restricted to project maintainers.
The release process is automated through two GitHub Actions workflows: