Skip to content

Version Packages - #411

Merged
oekazuma merged 1 commit into
mainfrom
changeset-release/main
Aug 8, 2026
Merged

oekazuma merged 1 commit into
mainfrom
changeset-release/main

Conversation

@github-actions

@github-actions github-actions Bot commented Aug 8, 2026 •

Copy link
Copy Markdown
Contributor

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@svelte-vitals/core@0.39.0

Minor Changes

  • a3dffb3: architecture/prop-count now counts named props destructured alongside a rest element (let { a, b, ...rest } = $props()) instead of treating the whole destructure as uncountable and staying silent. The named count is a lower bound on the true prop count, and the rule only flags a component whose named-prop count exceeds its max option (default 6), so this can only surface findings on previously invisible components — never a false positive. A bare rest element with no named props (let { ...rest } = $props()) and a non-destructured $props() are still not counted.

    Re-measured the per-repo p90 median across the same 10-repo corpus from the 2026-07-25 threshold recalibration with the fix applied: 6.5 (was 6). MAX_PROPS stays 6.

  • 8e8bd5c: architecture/reserved-directory-names, architecture/directory-naming and architecture/unit-entry-file
    now report examined counts in the JSON report, the same mechanism architecture/reserved-name-placement
    already used: per declaration, how many places it judged, keyed by the same bare glob string its own
    diagnostic names. A run configuring all four rules previously got one examined entry and silence for the
    other three, even though all three already emit a project-scoped finding for a declaration that matched no
    directory — the count fills in the missing number for a key that governed a hundred directories versus one.

    No exported shape changes: runRules, RuleContext.recordExamined and JsonReport.examined already exist.
    This is JSON-only, matching the existing feature — no CLI or console output changes.

  • ac41349: Every rule's PASS results now carry the same location a penalized result on the same route/file would — visible to library consumers reading results and in the rules.*.passed counts, not only the two rule ids (seo/title-presence and the headTagRule-backed family) that already did this. (The JSON report's routes[].issues/siteIssues arrays stay penalized-only, so this isn't visible there.) Fixes files:-scoped severity: 'off' overrides silently failing to remove a passing seed (issue files:-scoped 'off' cannot remove passing seeds from seo/title-length, seo/description-length, performance/preconnect #382): overrideMatches matches files: against a result's location, and a PASS with no location could never match, so 'off' removed a rule's penalized findings but left its passing seed counted. route:-scoped overrides were unaffected.

    architecture/unit-entry-file's per-declaration pass (deliberately route-less since fix(core): make a displayed score of 100 mean zero findings #337) is unchanged — it never had this bug (location without route was never reachable by a route: glob to begin with, and files: already matched it via location).

    No rule's id, severity, or detection changes, and score.ts never reads location directly. Scores can still move in any mode through the fix itself: a files:-scoped 'off' now removes the passing seeds it always claimed to (the issue's reproduction moves 98 → 96 once the seed is gone), where before it silently removed only the penalized findings. Benign display change: the console reporter's --verbose Passed listing prints location ?? route, so a rule newly carrying location on PASS now lists the file path there instead of the route id. See docs/superpowers/specs/2026-08-08-pass-result-location-design.md for the full design record and blast-radius enumeration.

  • 65ce0c1: The HTML report and the dev dashboard now show each category's reach ("N of M keys affected") beside its score. The score floor design (2026-08-05) moved magnitude out of the score and into categories[cat].affectedKeys/keys, so a reader could no longer tell one affected file from forty-one — both surfaces received the fields and rendered nothing. Per-route category rendering (routes[].categories) remains a deferred, separate question.

  • acee3c6: Add anyCaseUnitScopes to architecture/reserved-directory-names: a counterpart to unitScopes that
    governs units whose name does not begin A–Z.

    unitScopes identifies a unit with isUnitDir, which requires the directory name to begin A–Z as well
    as holding a same-stemmed child file — so a lowercase, .ts- or .svelte.ts-entry unit's children (measured
    at 129 of 299 units, 43%, on a real tree) were never governed by any declaration. anyCaseUnitScopes takes
    the same option shape against isAnyCaseUnitDir, the same test without the letter requirement. Declaring
    the identical glob in both maps is not a collision: unitScopes governs at capitalised units,
    anyCaseUnitScopes governs alone at the lowercase ones unitScopes never reaches.

    Default behavior is unchanged — anyCaseUnitScopes defaults to {}, so a project that does not declare it
    sees no new findings.

svelte-vitals@0.44.1

Patch Changes

  • a9fba45: Fix --baseline silently masking a genuine regression: for the SEO rules whose passing results already carry a file location (seo/title-presence and the ten headTagRule-backed ids — canonical-url, og-title, og-image, charset, viewport, twitter-card, description-presence, og-description, json-ld, og-url), a route that passed at the baseline ref and then regressed (e.g. a <title> deleted) produced identical comparison keys on both sides and was dropped as "not new" instead of being reported. findingKey comparison is now penalized-findings-only on both the current and baseline sides (matching the pattern suppressions.ts already uses), so a passing result can never key-collide with a penalized one.

    Behavior change as a result: passing results no longer appear in --baseline output at all — previously, a route that was penalized at the baseline and now passes could still surface its passing result. Under --baseline --score, Health is now computed over the new penalized findings only — pass-seeded routes and categories no longer raise it — so a --baseline run's Health/--min-health can report a lower (stricter) score than before. See docs/superpowers/specs/2026-08-08-pass-result-location-design.md ("findingKey / filterToNewFindings" section) for the design record.

  • ac41349: Fix files:-scoped severity: 'off' overrides silently failing to remove a passing seed (issue files:-scoped 'off' cannot remove passing seeds from seo/title-length, seo/description-length, performance/preconnect #382), now that @svelte-vitals/core gives every rule's PASS result the same location its penalized counterpart would (see the linked design doc). Without a matching CLI-side fix, that alone would have broken --diff/--staged: filterToChangedFiles used to keep a result whenever it had any location in the changed set, so once passing results uniformly carried one, an incidental pass on a changed file could survive scoping.

    filterToChangedFiles (and its one call site, applyScope) now takes the resolved Config (optional, defaulting like filterToNewFindings in baseline.ts already does) and keeps a result only when it's penalized, or is architecture/unit-entry-file's deliberately route-less pass seed (PR fix(core): make a displayed score of 100 mean zero findings #337) — every other route-carrying PASS is dropped even when its location is in the changed set.

    Behavior change as a result: for seo/title-presence and the ten headTagRule-backed rule ids (canonical-url, og-title, og-image, charset, viewport, twitter-card, description-presence, og-description, json-ld, og-url) — which already carried location on PASS before this change — a passing result on a changed file no longer survives --diff/--staged filtering. This was a live, undetected leak: a single incidental passing check on a changed file could promote its whole category from absent to a fabricated 100, pulling --diff Health upward. Measured on the reference shape (one critical correctness finding plus one such SEO PASS, both on changed files, default config): Health moves from 89 to 79 — 79 is correct; 89 was the bug. A --min-health gate can now fail a run that previously passed only because of this leak. The three rules named in the design doc (seo/title-length, seo/description-length, performance/preconnect) newly gain location in this release too, but their PASS results are penalized-gated the same way, so they contribute no net --diff Health movement of their own — their location addition only matters for the files:-override fix above.

    architecture/unit-entry-file's route-less pass seed is exempt from the drop above (PR fix(core): make a displayed score of 100 mean zero findings #337) — this preserves pre-existing behavior, not a new exception: main's filterToChangedFiles already kept this pass unconditionally (no isPenalized gate at all), so a changed conforming unit already promoted architecture to a fabricated 100 in --diff Health before this release, and still does after — the tradeoff (that pass staying visible under --diff, at that cost) is fix(core): make a displayed score of 100 mean zero findings #337's, kept as-is, not something this PR introduces or removes.

    See docs/superpowers/specs/2026-08-08-pass-result-location-design.md for the full design record. The svelte-vitals-action repo bundles applyScope, so its --diff Health inherits this change on its next dependency bump — its own release notes should carry the same warning.

  • bd946e2: Let --out-file - (space-separated) and --out-file=- stream to stdout again, matching the documented contract (--help, the reporters guide, and svelte-vitals docs show output). The flag-shaped/empty-value guard added in the previous release rejected the literal - along with every other dash-prefixed value; - is now the one allowed exception, exempted only for --out-file. Regular file paths (e.g. --out-file report.html) were never affected and remain valid; dash-prefixed values for every other flag — and any dash-prefixed --out-file value other than exactly - — still exit 2 as before.

  • 7c5a11b: Exit 2 when --rules and --category are both passed and --category excludes every rule named in --rules. Previously analyzeProject's category filter ran after rule selection, so a --rules id whose category wasn't in --category was dropped silently — the run exited 0 with zero rules examined and nothing on stderr (issue cli: --rules with a --category that excludes every named rule runs nothing at exit 0 #384). The check mirrors the existing unknown-rule-id error: fatal, naming the excluded rule id(s) and the --category list. --ignore is unaffected — ignoring a rule that --category already excludes is harmless, not a conflict.

  • f0798b0: Update the registry-visible package descriptions and keywords, which still described svelte-vitals as an SEO-only checker. svelte-vitals's description now matches its own --help text — a deterministic SvelteKit code-health scanner across SEO, performance, correctness, security, and architecture — and adds performance, security, code-quality, static-analysis keywords. @svelte-vitals/vite's description now also mentions the live dev dashboard alongside the build-time prerendered-HTML analysis. No behavior change.

  • ab41e48: Scoped runs (--diff/--staged/--baseline) no longer report svelte-vitals-suppressions.json entries as stale just because the scope excluded their findings — staleness is now judged against the project-wide result set, so the documented CI recipe (--diff origin/main --baseline origin/main) no longer prints a misleading "N stale entries — re-run --update-suppressions to prune" on every run. --route runs, where even the project-wide set is collected route-narrowed, omit the stale count entirely rather than report an unreliable one. --update-suppressions combined with --route now refuses (exit 2) instead of silently pruning suppression entries outside that route.

  • 28d22ae: Naming a rule in --rules that a config overrides entry scopes 'off' (directly by rule id, or via its category key) now prints a startup warning naming the rule and the overrides entry's files/route scope, instead of silently reporting a compliant tree. The semantics — whether --rules should force-enable through a scoped 'off' — are deliberately unchanged; only the silence is fixed (cli: a rule named in --rules that config.overrides scopes off reports nothing, silently #385).

  • Updated dependencies [a3dffb3]

  • Updated dependencies [8e8bd5c]

  • Updated dependencies [ac41349]

  • Updated dependencies [65ce0c1]

  • Updated dependencies [acee3c6]

    • @svelte-vitals/core@0.39.0

@svelte-vitals/vite@0.29.1

Patch Changes

  • f0798b0: Update the registry-visible package descriptions and keywords, which still described svelte-vitals as an SEO-only checker. svelte-vitals's description now matches its own --help text — a deterministic SvelteKit code-health scanner across SEO, performance, correctness, security, and architecture — and adds performance, security, code-quality, static-analysis keywords. @svelte-vitals/vite's description now also mentions the live dev dashboard alongside the build-time prerendered-HTML analysis. No behavior change.
  • Updated dependencies [a9fba45]
  • Updated dependencies [ac41349]
  • Updated dependencies [a3dffb3]
  • Updated dependencies [8e8bd5c]
  • Updated dependencies [bd946e2]
  • Updated dependencies [ac41349]
  • Updated dependencies [65ce0c1]
  • Updated dependencies [acee3c6]
  • Updated dependencies [7c5a11b]
  • Updated dependencies [f0798b0]
  • Updated dependencies [ab41e48]
  • Updated dependencies [28d22ae]
    • svelte-vitals@0.44.1
    • @svelte-vitals/core@0.39.0

@github-actions
github-actions Bot force-pushed the changeset-release/main branch 9 times, most recently from 62f8492 to 70836c2 Compare August 8, 2026 14:02
@github-actions
github-actions Bot force-pushed the changeset-release/main branch from 70836c2 to 6234771 Compare August 8, 2026 16:00
@oekazuma
oekazuma merged commit d2e29c0 into main Aug 8, 2026
@oekazuma
oekazuma deleted the changeset-release/main branch August 8, 2026 16:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant