Gently Updating Style Settings

[sigrunixia]

I spoke to MG on how we should handle Style Settings-

He is fine with the community taking over for this plugin, and others, but the changes need to respect the vision and intention of the plugins, and do their best to "not annoy current users". (We could have a discussion around the word annoy, but lets not get sidetracked).

Which, we love MG, we're not going to do his plugins dirty like that. So:

• We're going to make slow and small PR's
• We're going to test well
• We're going to talk about these things
• We're going to take our time

Sound good?

The big 3 of his priorities are Style Settings, Kanban, Zotero. For this discussion, we will focus on style settings.

@saberzero1 and @Jalad25

[sigrunixia]

Fixes and Breaking Changes

#220 , #221 , and #222 were just merged. These added some gentle fixes and tests. We have 1.13 release coming up which has some major settings changes, which may be a good time to also time 1 breaking change if we have any.

[sigrunixia]

Going through FR's

We can and should go through FR's and close the ones that are out of scope of the plugin. I don't use style settings, though, so I am not the best person for this.

[sigrunixia]

I have pruned down many of the issues, so its not as overwhelming. :)

[saberzero1]

Excellent.

I believe the very first thing to do now is to add a GitHub Actions workflow that runs the test suite on commit/pull request.

As for potentially introducing breaking changes, is there anything that is a likely candidate for that? We obviously don't have to make breaking changes, but this is the moment if we want to make any.

Likely options are either removal of parts of the API (e.g. gradient, which lacks implementation anyway) or increasing strictness (e.g. forbidding lack of missing defaults, forbidding missing values, tightening value checks, etc.)

[saberzero1]

I'll submit a PR tomorrow morning for the CI.

I have an implementation ready for the missing gradient option, so I could upstream that. It is not really a breaking change; just implementing what is already described in the schema.

As for breaking changes, I suspect that a likely breaking changes could be gating some features behind version checks. For example, color-mix() is likely not supported in older Obsidian versions.

[sigrunixia]

Ah, true, and thats not a bad one to have considering how many support emails I get on people needing older installers.

[sigrunixia]

After that, we should work on the settings API update for 1.13 as we getting closer there and looking to 1.14.

[saberzero1]

After that, we should work on the settings API update for 1.13 as we getting closer there and looking to 1.14.

I'll look into it.

I'm currently working on improving the baseline CI, adding test suite run, release attestation, and updating eslint.

[saberzero1]

Here is the PR for the CI improvements: #227

It adds the eslint plugin, release attestation, and runs the linting and tests on both commit/PR and release.

The linting flags many issues, so the linting does not fail the CI at the moment. I'll remove this in a followup PR when I address the flagged issues.