Skip to content

v1.2.0

Choose a tag to compare

@saberzero1 saberzero1 released this 18 Sep 22:19
· 15 commits to main since this release
v1.2.0
611f291

Fixed

Repositories without a package-lock.json no longer fail

actions/setup-node throws when cache: npm cannot find a lockfile matching the selected package manager, so the reusable release workflow failed before this action ever ran.

This affected:

  • Theme repositories, which commonly contain only theme.css and manifest.json
  • Any repository using pnpm, since pnpm-lock.yaml is not one of npm's recognized
    lockfile patterns

cache: has been removed from the reusable workflow, and the package manager is now detected from the committed lockfile instead of assumed. pnpm, yarn and bun use their own frozen-install commands. If the detected tool is unavailable on the runner, the action warns and falls back to npm install rather than failing the job.

If you copied the release workflow from the README, remove the cache: npm line from your actions/setup-node step.

Closes #12

Stylelint findings were being discarded

Stylelint writes its JSON report to stderr. The action read only stdout, so every Stylelint finding was silently dropped and reported as inconclusive.

Plugins with no CSS no longer report a false error

Stylelint was invoked even when a repository contained no CSS files, and its "no matching files" exit was reported as a failure.

Added

Per-finding results

Previously an entire Stylelint or ESLint run collapsed into a single generic warning, with the real diagnostics visible only in raw log output.

Findings now carry a stable rule ID, severity, status and source location, and are emitted as annotations with file and line — so they appear directly on the diff.

Job summary

Every run writes a summary containing:

  • Findings grouped by check, with rule IDs, locations and remediation links
  • A coverage table showing what was checked here, what is partial, and what cannot run until a published release exists
  • An explicit statement that passing here does not guarantee directory acceptance

Expanded community directory parity

New checks for plugin and theme manifests, README content, manifest URLs, dependency pinning, directory ID/name conflicts, and repository metadata, plus an advisory preflight over the locally built main.js.

Themes now require author and minAppVersion, matching the directory.

Obfuscation, funding and AI-generated detection are deliberately excluded.

strict input

- uses: obsidianmd/obsidian-workflows@v1
  with:
    strict: 'true'   # default: 'false'

Policy findings are advisory by default and reported as warnings. They will not fail your build. Set strict: true to enforce them.

Correctness failures remain hard errors in both modes: a failed build, an unparsable manifest.json, or missing release assets.

Upgrade notes

No action required. Because policy findings are advisory by default, existing workflows will not start failing.

You will see new warnings and a job summary. These reflect requirements the community directory already enforces — the action previously just didn't report them. We recommend reviewing them ahead of the end of the grandfathering period, after which they will apply to existing plugins and themes as well.

Plugin and theme IDs are exempt permanently: identifiers cannot change without breaking existing installations, so entries already in the directory keep theirs.

To pin to the previous behavior, use @v1.1.0.