packages/cli/bin/unhead.mjs (1)

4-7: Optional: prefer process.exitCode = 1 over process.exit(1) to avoid truncating buffered stderr.

process.exit(1) terminates the process synchronously and can drop pending stdio writes on some platforms. Setting process.exitCode lets Node finish flushing the console.error output before exiting naturally.

♻️ Proposed refactor

 import ('../dist/index.mjs').then(m => m.run()).catch((err) => {
   console.error(err)
-  process.exit(1)
+  process.exitCode = 1
 })

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/cli/bin/unhead.mjs` around lines 4 - 7, The catch block currently
calls process.exit(1) which can truncate buffered stderr; change it to set
process.exitCode = 1 instead and allow the process to exit naturally after
logging the error (keep the existing console.error(err) call in the Promise
rejection handler that follows the dynamic import and m.run invocation). Target
the Promise chain created by import('../dist/index.mjs').then(m =>
m.run()).catch((err) => { ... }) and replace the synchronous exit call with
setting process.exitCode so pending stdio can flush.

packages/cli/test/lint.test.ts (1)

17-27: Brittle assertion — duplicate rule hits or extra fixture files will break it.

results[0].messages.map(m => m.ruleId) includes one entry per ESLint message. If any rule fires more than once on the fixture (or if a future fixture file is added under **/*.ts), the sorted-array toEqual will fail even when behavior is correct. Also, parse errors surface as ruleId: null, which would silently appear in the array.

Consider asserting on the unique set instead, and asserting non-null:

♻️ Proposed refactor

-    expect(results).toHaveLength(1)
-    const ruleIds = results[0].messages.map(m => m.ruleId).sort()
-    expect(ruleIds).toEqual([
-      '@unhead/defer-on-module-script',
-      '@unhead/no-html-in-title',
-      '@unhead/non-absolute-canonical',
-      '@unhead/preload-font-crossorigin',
-      '@unhead/robots-conflict',
-      '@unhead/twitter-handle-missing-at',
-    ].sort())
+    expect(results).toHaveLength(1)
+    const ruleIds = new Set(results[0].messages.map(m => m.ruleId))
+    expect(ruleIds.has(null)).toBe(false) // no parse/config errors
+    expect(ruleIds).toEqual(new Set([
+      '@unhead/defer-on-module-script',
+      '@unhead/no-html-in-title',
+      '@unhead/non-absolute-canonical',
+      '@unhead/preload-font-crossorigin',
+      '@unhead/robots-conflict',
+      '@unhead/twitter-handle-missing-at',
+    ]))
     expect(errorCount + warningCount).toBeGreaterThan(0)

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/cli/test/lint.test.ts` around lines 17 - 27, The assertion is
brittle because results[0].messages may contain duplicate ruleIds and nulls;
update the test in lint.test.ts to dedupe and filter out null ruleIds before
asserting: derive the uniqueRuleIds from results[0].messages by filtering
m.ruleId != null and creating a Set (or equivalent) to remove duplicates, then
assert that the expected list (the six '@unhead/...' IDs) is a subset of
uniqueRuleIds (e.g., use an arrayContaining-style assertion or compare Sets) and
keep the existing non-zero error/warning check; reference the variables/results
used in the diff: results, results[0].messages, ruleIds, and
errorCount/warningCount.

packages/eslint-plugin/src/rules/canonical-rules.ts (1)

4-6: Protocol comparison should be case-insensitive.

URL schemes are case-insensitive per RFC 3986, so a literal like HTTP://example.com would be (incorrectly) reported as non-absolute. Trivially fixed:

♻️ Proposed fix

 function isAbsolute(url: string): boolean {
-  return url.startsWith('http://') || url.startsWith('https://')
+  return /^https?:\/\//i.test(url)
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/eslint-plugin/src/rules/canonical-rules.ts` around lines 4 - 6, The
isAbsolute function incorrectly treats schemes case-sensitively; update
isAbsolute to compare the URL scheme case-insensitively by normalizing the input
(e.g., call toLowerCase() on the url) or use a case-insensitive regex when
checking startsWith('http://') || startsWith('https://') so URLs like
"HTTP://..." are recognized as absolute; update the function name isAbsolute
accordingly and ensure any callers still receive the same boolean behavior.

packages/eslint-plugin/src/rules/twitter-handle-missing-at.ts (1)

40-40: Fixer rewrites the original quote style.

The fix unconditionally emits a single-quoted literal ('@${v}'), so a source like content: "foo" becomes content: '@foo'. That conflicts with projects whose quotes rule prefers double quotes and produces churn / autofix loops with stylistic linters. It also doesn’t escape v, so a value containing a ' would emit broken syntax (unlikely for a Twitter handle, but the literal itself is untrusted user code).

A range-insert preserves the original quote and avoids escape concerns:

♻️ Proposed fix

-        fix: fixer => fixer.replaceText(value, `'@${v}'`),
+        fix: fixer => fixer.insertTextAfterRange([value.range![0], value.range![0] + 1], '@'),

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/eslint-plugin/src/rules/twitter-handle-missing-at.ts` at line 40,
The fixer currently calls fixer.replaceText(value, `'@${v}'`) which force‑writes
a single‑quoted string and doesn't escape v; change the fixer to insert the @
inside the existing string token instead of replacing it: locate the string
token represented by value, detect its original quote char, and use a
range/insert fixer (e.g. fixer.insertTextAfterRange or fixer.replaceTextRange on
value.range) to insert '@' immediately after the opening quote (or insert before
closing quote if needed), using the original quotes so you preserve quote style
and avoid introducing escaping issues for v; keep using the existing v variable
to build the inserted text.

packages/eslint-plugin/src/rules/title-rules.ts (1)

5-46: Minor false-positive risk and a small coverage gap.

• HTML_CHARS_RE = /[<>]/ will trigger on legitimate titles such as "5 < 10" or breadcrumbs like "Docs > API". Since the rule is a warn, this is tolerable, but the message ("HTML characters") may be confusing in those cases. Tightening the regex to detect tag-like patterns (e.g., /<\/?[a-z][^>]*>/i) or entity references would reduce noise.
• The rule only inspects string titles. useHead({ title: { textContent: '...' } }) is a supported form and would silently bypass this check. Optional to extend, but worth a comment if intentionally out of scope.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/eslint-plugin/src/rules/title-rules.ts` around lines 5 - 46, The
current HTML_CHARS_RE in noHtmlInTitle is too broad and misses object-form
titles; replace HTML_CHARS_RE with a stricter pattern that matches tag-like
sequences and entity references (e.g. /<\/?[a-z][^>]*>/i or also detect
/&[a-zA-Z0-9#]+;/) and use that in checkTitle to reduce false positives;
additionally update the CallExpression visitor (inside create) to also handle
title provided as an ObjectExpression with a textContent property by using
findProperty on the title object and passing its value into checkTitle (or add a
comment if you intentionally keep object-title out of scope), ensuring
references to HTML_CHARS_RE, checkTitle, CallExpression, and findProperty are
updated accordingly.

packages/cli/src/commands/migrate.ts (1)

14-35: Positional arg patterns is declared but unused; consume args.patterns consistently.

The patterns positional is declared in args, but the code reads args._ directly and ignores args.patterns. With citty's positional handling this happens to work, but it's confusing for maintainers and breaks if citty's positional shape changes (e.g., the named-positional binding moves from _ to args.patterns). Either drop the named positional, or read it through the typed args accessor.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/cli/src/commands/migrate.ts` around lines 14 - 35, The code declares
a positional arg "patterns" but then reads args._ directly; update the run logic
in the migrate command to consume args.patterns (or remove the named
positional). Specifically, inside async run({ args }) replace the positional
extraction that uses args._ and instead read const positional =
(Array.isArray(args.patterns) ? args.patterns : (args.patterns ?
[String(args.patterns)] : [])) .map(String).filter(Boolean) (or simply use
args.patterns as an array) and then compute patterns = positional.length > 0 ?
positional : DEFAULT_PATTERNS; ensure any fallbacks to args._ are removed so the
code consistently uses args.patterns and keep references to DEFAULT_PATTERNS and
cwd resolution unchanged.

packages/eslint-plugin/test/no-deprecated-props.test.ts (1)

8-30: Coverage looks solid; consider one extra case.

The current invalid cases each exercise one deprecated prop in isolation. Worth adding a single invalid case combining multiple deprecations on one tag (e.g., { children: 'x', body: true, hid: 'k' }) to lock in the behavior when multiple fixes are applied in the same pass — historically a common source of fixer conflicts.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/eslint-plugin/test/no-deprecated-props.test.ts` around lines 8 - 30,
Add an invalid test case to the tester.run('no-deprecated-props',
noDeprecatedProps, ...) suite that exercises multiple deprecated props on the
same tag (e.g., an object with children: 'x', body: true, hid: 'k') so the fixer
is validated to handle simultaneous fixes; specify the expected output with
children → innerHTML, body → tagPosition: 'bodyClose', hid → key, and include
corresponding errors (messageId: 'deprecated' entries for each deprecated prop)
to ensure all fixes are applied in one pass by the rule's fixer.

packages/eslint-plugin/src/rules/preload-rules.ts (1)

43-60: LGTM with a tiny redundancy.

Logic and autofix look correct, including trailing-comma cases. Small nit: findProperty(tag, 'as') is called twice (once via getStringProp on Line 49 and again on Line 53 with a ! non-null assertion). Capture it once to drop the assertion:

-      if (getStringProp(tag, 'as') !== 'font')
+      const asProp = findProperty(tag, 'as')
+      if (!asProp || getStringValue(asProp.value) !== 'font')
         return
       if (findProperty(tag, 'crossorigin'))
         return
-      const asProp = findProperty(tag, 'as')!
       ctx.report({

Optional.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/eslint-plugin/src/rules/preload-rules.ts` around lines 43 - 60,
Capture the "as" property once to avoid the redundant call and drop the non-null
assertion: in the createTagVisitor -> onTag handler, call findProperty(tag,
'as') once into a const (e.g., asProp), early-return if it's missing, then use
getStringProp(tag, 'as') to check it's 'font' and finally use the captured
asProp in the fixer instead of calling findProperty(tag, 'as')!; this removes
the extra lookup and the `!` assertion while preserving the same logic.

packages/eslint-plugin/src/rules/robots-conflict.ts (1)

24-31: Extend conflict detection to treat none as equivalent to noindex, nofollow.

Google's robots meta documentation confirms that none is equivalent to noindex, nofollow. The current implementation misses real conflicts like content="none, index" or content="none, follow". Adding this equivalence would improve the rule's conflict coverage without additional complexity.

♻️ Proposed extension

       const directives = content.toLowerCase().split(',').map(d => d.trim())
-      if (directives.includes('index') && directives.includes('noindex'))
+      const hasNone = directives.includes('none')
+      const hasNoindex = directives.includes('noindex') || hasNone
+      const hasNofollow = directives.includes('nofollow') || hasNone
+      if (directives.includes('index') && hasNoindex)
         ctx.report({ node: tag, messageId: 'indexConflict' })
-      if (directives.includes('follow') && directives.includes('nofollow'))
+      if (directives.includes('follow') && hasNofollow)
         ctx.report({ node: tag, messageId: 'followConflict' })

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/eslint-plugin/src/rules/robots-conflict.ts` around lines 24 - 31,
The rule currently parses meta tag content into directives but doesn't treat
"none" as equivalent to "noindex" and "nofollow", so conflicts like
content="none, index" are missed; update the logic in robots-conflict.ts (around
getStringProp, tag, directives, and the ctx.report checks) to normalize "none"
by mapping it to both "noindex" and "nofollow" (e.g., if
directives.includes('none') then treat it as if directives also include
'noindex' and 'nofollow') before running the existing index/follow conflict
checks that call ctx.report with messageId 'indexConflict' and 'followConflict'.

packages/eslint-plugin/src/index.ts (1)

33-39: Optional: keep plugin meta.version in sync with package.json automatically.

The '3.0.5' literal duplicates packages/eslint-plugin/package.json's version and will drift on release. Since you're building with unbuild, you can inline the version from package.json (e.g. via a replace step or by importing version from ../package.json with a JSON resolver) so future bumps don't require touching this file.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/eslint-plugin/src/index.ts` around lines 33 - 39, The hard-coded
plugin version in the plugin object (plugin.meta.version) will drift; replace
the literal '3.0.5' by sourcing the package version dynamically (e.g., import {
version } from the package.json or inject it during the unbuild replace step) so
plugin.meta.version uses that imported/injected version; update the plugin
object (plugin.meta.version) to reference that symbol instead of the string
literal.

packages/eslint-plugin/test/rules.test.ts (1)

11-157: LGTM — broad messageId + fixer-output coverage.

Good mix of valid cases and invalid cases asserting both messageId and (where applicable) the output after autofix. Consider adding at least one negative-fixer case (e.g., a twitter:site value that is purely numeric) to lock in the "don't fix numeric IDs" branch in twitter-handle-missing-at, but that's optional.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/eslint-plugin/test/rules.test.ts` around lines 11 - 157, Add a
negative-fixer test to the twitter-handle-missing-at suite: in the
tester.run('twitter-handle-missing-at', ...) invalid array add a case with code
`useHead({ meta: [{ name: 'twitter:site', content: '12345' }] })` that asserts
errors: [{ messageId: 'missingAt' }] but does NOT include an output property, so
the rule is tested to report the error without applying a fixer for numeric IDs;
locate the twitter-handle-missing-at test block and append this invalid case
alongside the existing cases.

packages/cli/src/commands/validate-html.ts (1)

17-38: Drop unused patterns declaration — args._ is the recommended approach for citty.

patterns is declared as a single positional in args but run() ignores it and reads args._ directly. This declaration is dead code and should be removed.

Note: Citty does not support variadic/rest positional arguments in stable releases (a feature request exists as PR #199). Using args._ to access unmatched positionals is the officially recommended approach until that feature lands.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/cli/src/commands/validate-html.ts` around lines 17 - 38, Remove the
unused positional declaration "patterns" from the args object since run() reads
unmatched positionals via args._; update the args block to only include cwd and
json (or any true named positionals you need), leaving DEFAULT_PATTERNS and the
logic in run() unchanged (the run function already resolves cwd, reads args._
into positional, and falls back to DEFAULT_PATTERNS), and ensure no other code
references args.patterns so there are no remaining dead symbols.

packages/eslint-plugin/src/rules/numeric-tag-priority.ts (1)

33-36: Optional: simplify alias→messageId mapping with a lookup table.

The nested ternary works but is harder to extend. A small map keeps the relationship explicit:

♻️ Proposed refactor

-        suggest: (['critical', 'high', 'low'] as const).map(alias => ({
-          messageId: alias === 'critical' ? 'suggestCritical' : alias === 'high' ? 'suggestHigh' : 'suggestLow',
-          fix: fixer => fixer.replaceText(value, `'${alias}'`),
-        })),
+        suggest: ([
+          ['critical', 'suggestCritical'],
+          ['high', 'suggestHigh'],
+          ['low', 'suggestLow'],
+        ] as const).map(([alias, messageId]) => ({
+          messageId,
+          fix: fixer => fixer.replaceText(value, `'${alias}'`),
+        })),

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/eslint-plugin/src/rules/numeric-tag-priority.ts` around lines 33 -
36, Replace the nested ternary used to pick messageId inside the suggest map
with an explicit lookup table to make the relation clearer and easier to extend:
define a const mapping (e.g., messageIdMap = { critical: 'suggestCritical',
high: 'suggestHigh', low: 'suggestLow' }) and then in the suggest map (the array
mapping over alias) use messageId: messageIdMap[alias] while keeping the
existing fix: fixer => fixer.replaceText(value, `'${alias}'`).

packages/eslint-plugin/src/rules/viewport-user-scalable.ts (1)

4-5: Optional: dedupe regexes shared with the runtime validator.

USER_SCALABLE_NO_RE / MAX_SCALE_RE are duplicated verbatim from packages/unhead/src/plugins/validate.ts. Since the goal of the unhead/validate subpath is exactly this kind of shared rule data, consider exporting these from unhead/validate so the lint rule and runtime check can never drift.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/eslint-plugin/src/rules/viewport-user-scalable.ts` around lines 4 -
5, Replace the duplicated regex constants in the lint rule with imports from the
shared validator module: export USER_SCALABLE_NO_RE and MAX_SCALE_RE from the
unhead/validate subpath (where the runtime validator lives) and then remove the
local definitions in packages/eslint-plugin/src/rules/viewport-user-scalable.ts
and import those two symbols instead; update any usages in the rule to reference
the imported USER_SCALABLE_NO_RE and MAX_SCALE_RE so the runtime validator and
linter share the same single source of truth.

packages/unhead/src/plugins/validate.ts (1)

412-437: Optional: merge the two adjacent for (const tag of tags) loops.

The deprecated-props check and the numeric-tagPriority check both walk every tag back-to-back. Folding them into a single pass is a small but free win and keeps related v2→v3 migration warnings co-located.

♻️ Proposed refactor

           // Deprecated v2 property names (no longer auto-converted)
           for (const tag of tags) {
             for (const propName of Object.keys(DEPRECATED_PROPS)) {
               if (!(propName in tag.props))
                 continue
               if (propName === 'body' && tag.props.body !== true)
                 continue
               const { replacement, ruleId } = DEPRECATED_PROPS[propName]
               const message = propName === 'body'
                 ? `"body: true" was removed in v3. Use "${replacement}" instead.`
                 : `"${propName}" was removed in v3. Use "${replacement}" instead.`
               report(ruleId, message, 'warn', tag)
             }
-          }
-
-          // Numeric tagPriority (alias is preferred for readability and stability)
-          for (const tag of tags) {
             if (typeof tag.tagPriority === 'number') {
               report(
                 'numeric-tag-priority',
                 `Numeric tagPriority (${tag.tagPriority}) is brittle. Prefer an alias ('critical' | 'high' | 'low'), or 'before:<key>' / 'after:<key>' to position relative to another tag.`,
                 'info',
                 tag,
               )
             }
           }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/unhead/src/plugins/validate.ts` around lines 412 - 437, Merge the
two adjacent iterations over tags into a single loop to avoid double traversal:
inside one "for (const tag of tags)" handle both the DEPRECATED_PROPS check
(including the special-case "body" handling that compares tag.props.body ===
true and uses DEPRECATED_PROPS[propName].replacement and .ruleId to call report)
and the numeric tagPriority check (if typeof tag.tagPriority === 'number' call
report with the same message). Keep the same report ruleIds, messages and
severity levels and ensure both checks run for every tag in that single loop.

packages/cli/package.json (1)

53-55: Consider adding an engines.node field to prevent install-time failures on incompatible Node versions.

@unhead/cli peers on eslint >= 9, which requires Node ^18.18.0 || ^20.9.0 || >=21.1.0. Without an engines field, users on EOL Node versions will encounter opaque ESLint runtime errors rather than clear install-time warnings.

Proposed addition

  "peerDependencies": {
    "eslint": ">=9.0.0"
  },
+  "engines": {
+    "node": "^18.18.0 || ^20.9.0 || >=21.1.0"
+  },
  "dependencies": {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/cli/package.json` around lines 53 - 55, Add an engines.node entry to
package.json to prevent installs on unsupported Node versions: edit
package.json's "engines" field (key "engines.node") to at least the range
required by the peer dependency (eslint), e.g. " ^18.18.0 || ^20.9.0 ||
>=21.1.0", so that npm/yarn will warn/refuse installs on incompatible Node
runtimes; ensure you update the package.json that contains the existing
"peerDependencies" block and run a quick package lint/format afterwards.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

packages/cli/src/commands/validate-html.ts (1)

46-50: Optional: parallelize file reads.

readFile is awaited sequentially per file. For large output dirs (e.g., a static site with hundreds of HTML files), Promise.all would noticeably reduce wall-clock time without changing behavior.

♻️ Proposed refactor

-    const reports: ValidationOutput[] = []
-    for (const file of files) {
-      const html = await readFile(file, 'utf8')
-      reports.push(validateHtml(html, file))
-    }
+    const reports: ValidationOutput[] = await Promise.all(
+      files.map(async (file) => {
+        const html = await readFile(file, 'utf8')
+        return validateHtml(html, file)
+      }),
+    )

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/cli/src/commands/validate-html.ts` around lines 46 - 50, The loop
currently awaits readFile sequentially; change it to parallelize reads by
mapping files to promises and awaiting Promise.all, then run validateHtml for
each result (or include validateHtml inside the mapped promise) so you still
populate reports (the reports array) with results corresponding to files; use
the existing readFile, files and validateHtml symbols to implement
Promise.all-based parallel reads while preserving order.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

packages/devtools-app/app/app.vue (1)

22-26: Minor: redundant spread.

applyOverrides already constructs a new array internally; the [...] copy here is redundant. You can pass state.value.validationRules || [] directly.

♻️ Optional cleanup

 const tagsWarnings = computed(() =>
-  applyOverrides([...(state.value.validationRules || [])], overrides.value)
+  applyOverrides(state.value.validationRules || [], overrides.value)
     .filter(r => r.severity === 'warn')
     .length,
 )

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/devtools-app/app/app.vue` around lines 22 - 26, The computed
property tagsWarnings creates an unnecessary shallow copy using
[...(state.value.validationRules || [])]; remove the redundant spread and pass
state.value.validationRules || [] directly into applyOverrides (i.e., update
tagsWarnings to call applyOverrides(state.value.validationRules || [],
overrides.value) and keep the rest of the chain/filter on r.severity === 'warn'
unchanged).

packages/devtools-app/app/composables/rule-overrides.ts (2)

15-30: Validate stored severities to harden against stale/unknown values.

readStorage casts the parsed JSON to OverrideMap without verifying that each value is one of 'warn' | 'info' | 'off'. If the storage schema ever changes (e.g., a future severity is added then removed, or someone hand-edits localStorage), rules with unknown severities silently fall through applyOverrides and are kept with their original severity instead of being treated as no-override. A small filter here prevents stale entries from accumulating.

♻️ Suggested hardening

-    const parsed = JSON.parse(raw)
-    if (!parsed || typeof parsed !== 'object')
-      return {}
-    return parsed as OverrideMap
+    const parsed = JSON.parse(raw)
+    if (!parsed || typeof parsed !== 'object')
+      return {}
+    const out: OverrideMap = {}
+    for (const [k, v] of Object.entries(parsed)) {
+      if (v === 'warn' || v === 'info' || v === 'off')
+        out[k as ValidationRuleId] = v
+    }
+    return out

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/devtools-app/app/composables/rule-overrides.ts` around lines 15 -
30, readStorage currently casts parsed localStorage directly to OverrideMap,
allowing stale/unknown severity strings to persist; update readStorage to
validate each parsed entry for STORAGE_KEY so only keys whose values are one of
'warn' | 'info' | 'off' are kept, and drop any other values (returning {} for
invalid input), ensuring applyOverrides sees only known severities; reference
the readStorage function, OverrideMap type and STORAGE_KEY constant when
implementing the filter/validation logic.

---

41-43: deep: true is unnecessary here.

set() and reset() both reassign overrides.value to a brand-new object, so a shallow watch already triggers. deep: true adds reactivity overhead without benefit.

♻️ Optional cleanup

-watch(overrides, v => writeStorage(v), { deep: true })
+watch(overrides, v => writeStorage(v))

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/devtools-app/app/composables/rule-overrides.ts` around lines 41 -
43, The watch on the overrides ref currently uses { deep: true } which is
unnecessary because set() and reset() reassign overrides.value to new objects;
remove the deep option so the watch becomes a shallow watcher (keep
watch(overrides, v => writeStorage(v)) ), and verify functions that mutate
overrides (set, reset, any direct assignments) still reassign overrides.value
rather than mutating in-place to ensure the shallow watch triggers.

packages/devtools-app/app/composables/open-in-editor.ts (1)

6-17: Consider checking the response status.

fetch only rejects on network errors; a 404/500 from the dev server (e.g., when the path can't be resolved by launch-editor) will resolve silently. Logging non-OK responses would make editor-launch failures easier to diagnose.

♻️ Optional refinement

-  fetch(url).catch((err) => {
-    console.warn('[unhead devtools] open-in-editor failed:', err)
-  })
+  fetch(url)
+    .then((res) => {
+      if (!res.ok)
+        console.warn(`[unhead devtools] open-in-editor returned ${res.status} for ${source}`)
+    })
+    .catch((err) => {
+      console.warn('[unhead devtools] open-in-editor failed:', err)
+    })

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/devtools-app/app/composables/open-in-editor.ts` around lines 6 - 17,
The openInEditor function currently ignores non-network HTTP errors from fetch;
update openInEditor to await the fetch response and check response.ok, and when
not ok log a clear warning including response.status and response.statusText
(and optionally response.text() for more details) so 404/500 editor-launch
failures are visible; keep the existing catch to handle network errors. Ensure
you reference the openInEditor function and the fetch call when making this
change.

packages/devtools-app/app/components/DevtoolsTagTable.vue (2)

382-390: (rule as any).source cast hints at a missing field in the rule type.

Runtime ValidatePlugin rules likely don't carry a source property — that's an artifact added by the bundler's source-location injection / CLI lint output. Casting to any works but loses type safety and silently hides cases where source is undefined (the v-if only checks truthiness, not type).

If the template intentionally surfaces source for rules that originate from tags (carrying the tag's _source), it's worth adding an optional source?: string to the validation rule type emitted into devtools state, so this doesn't need a cast.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/devtools-app/app/components/DevtoolsTagTable.vue` around lines 382 -
390, The template is casting (rule as any).source because the rule type lacks an
optional source field; add source?: string to the validation rule type used by
the devtools state (the rule interface/type that populates DevtoolsTagTable.vue)
so components can reference rule.source without any casts, update any code that
populates rules (e.g., where ValidatePlugin rules are added) to assign the tag's
_source into the new source property when present, and remove the (rule as any)
casts and rely on the typed property in the template and the
openInEditor((rule).source) usage.

---

1-6: Add explicit openInEditor import for clarity.

openInEditor is invoked from the template (lines 345, 386) but relies on Nuxt's auto-import, which is enabled in your config. While this works, adding an explicit import would improve code clarity and align with how other composables are imported in this file:

import { applyOverrides, useRuleOverrides } from '~/composables/rule-overrides'
+import { openInEditor } from '~/composables/open-in-editor'
import { state } from '~/composables/state'

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/devtools-app/app/components/DevtoolsTagTable.vue` around lines 1 -
6, The template calls openInEditor but the file relies on Nuxt auto-imports;
explicitly import openInEditor (the openInEditor symbol) at the top of the
<script setup> alongside other composables to improve clarity and consistency
with applyOverrides/useRuleOverrides/state imports; update the import list so
openInEditor is imported from Nuxt's runtime (e.g., the '#app' export) and used
directly in the template.

packages/unhead/src/validate/rules.ts (2)

1-69: Manual sync between VALIDATION_RULE_IDS and PR-claimed rules — consider adding a guard.

The PR objectives mention CLI/eslint-plugin rules (e.g., prefer-define-helpers, no-deprecated-props, no-unknown-meta, preload-font-crossorigin) that aren't in this list. That's expected if those are eslint-only rule IDs, but with the union derived only from this array, drift is silent. A small integration test that asserts every runtime rule emitted by ValidatePlugin and every rule documented in @unhead/eslint-plugin either belongs to VALIDATION_RULE_IDS or is intentionally excluded would catch future drift.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/unhead/src/validate/rules.ts` around lines 1 - 69,
VALIDATION_RULE_IDS is the single source used to derive ValidationRuleId but the
PR notes show eslint-only rule IDs live elsewhere, so add a test to prevent
silent drift: create an integration test that imports VALIDATION_RULE_IDS and
(a) collects runtime rule IDs emitted by ValidatePlugin (e.g., from its exported
rule list or factory) and (b) collects rule IDs exported by the
`@unhead/eslint-plugin` package, then assert every ID from both sources is either
present in VALIDATION_RULE_IDS or explicitly listed in an "eslintOnlyExclusions"
array in the test; fail the test when an ID is neither present nor intentionally
excluded so future PRs must update VALIDATION_RULE_IDS or the exclusion list.

---

8-8: Remove the ineffective /* @pure */ annotation from the array literal.

Rollup and esbuild only recognize the @__PURE__ annotation on CallExpression and NewExpression (function calls and constructor calls). The annotation has no effect on array literals and serves only as misleading comment.

♻️ Suggested cleanup

-export const VALIDATION_RULE_IDS = /* `@__PURE__` */ [
+export const VALIDATION_RULE_IDS = [

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/unhead/src/validate/rules.ts` at line 8, The `/* `@__PURE__` */`
annotation attached to the array literal is ineffective and misleading; remove
the comment so the declaration "export const VALIDATION_RULE_IDS" is simply an
array export without the annotation, i.e. delete the `/* `@__PURE__` */` token
adjacent to VALIDATION_RULE_IDS and run tests/build to confirm no regressions.

packages/bundler/src/devtools/rpc/functions/run-lint.ts (1)

37-42: Consider extending the default ignore set and allowing user overrides for lint scope.

The hardcoded ignore list (node_modules, dist, .output, .nuxt) misses common output directories like coverage/, build/, .cache/, and .git/, which can cause ESLint to parse unnecessary files, adding noise and latency in larger projects.

Two improvements, neither blocking:

1. Expand the default ignore list to include **/coverage/**, **/build/**, **/.cache/**, and **/.git/**.
2. Extend RunLintArgs to accept optional patterns and ignore parameters so downstream tooling (audit page, CI) can customize the lint scope—e.g., "lint changed files only" or "skip specific directories."

The underlying lib.runLint() already supports both parameters; they're simply hardcoded in the RPC handler.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/bundler/src/devtools/rpc/functions/run-lint.ts` around lines 37 -
42, The RPC handler calling lib.runLint hardcodes patterns and an incomplete
ignore list; update the handler to merge a wider default ignore set (add
"**/coverage/**", "**/build/**", "**/.cache/**", "**/.git/**") and allow callers
to override both patterns and ignore via RunLintArgs (make patterns? and ignore?
optional), then call lib.runLint({ patterns: args.patterns ?? defaultPatterns,
ignore: args.ignore ? args.ignore.concat(defaultIgnore) : defaultIgnore, mode,
cwd }) so downstream callers can pass custom scopes; reference lib.runLint and
the RunLintArgs type in your changes.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

packages/eslint-plugin/src/utils/visitor.ts (1)

38-45: Optional: handle ChainExpression callees.

getCalleeName won't resolve callees wrapped by optional chaining (e.g. unhead?.useHead({...}) or obj?.useHead?.()), where node.callee is a ChainExpression whose inner expression is the MemberExpression. Probably rare in practice, but a one-line unwrap would close the gap:

♻️ Optional refactor

 export function getCalleeName(node: ESTree.CallExpression): string | undefined {
-  const callee = node.callee
+  let callee = node.callee
+  if (callee.type === 'ChainExpression')
+    callee = callee.expression
   if (callee.type === 'Identifier')
     return callee.name
   if (callee.type === 'MemberExpression' && callee.property.type === 'Identifier')
     return callee.property.name
   return undefined
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/eslint-plugin/src/utils/visitor.ts` around lines 38 - 45, The
getCalleeName function doesn't handle optional chaining where node.callee can be
a ChainExpression; update getCalleeName to unwrap a ChainExpression (access its
.expression) before the existing checks so Identifier and MemberExpression cases
still work (retain the property.type === 'Identifier' check for
MemberExpression); modify the logic inside getCalleeName to normalize callee by
replacing node.callee with callee.expression when callee.type ===
'ChainExpression' so existing return paths (callee.name or callee.property.name)
cover optional chaining scenarios.

packages/eslint-plugin/src/rules/prefer-define-helpers.ts (1)

21-33: Consider validating the import source module in helperIsImported.

The function currently accepts any ImportDeclaration with a specifier named defineLink or defineScript, regardless of source. If a user imports an identically-named symbol from an unrelated package, the autofix will incorrectly wrap the call. Restricting the check to known unhead packages (unhead, @unhead/vue, @unhead/react, @unhead/solid-js, @unhead/svelte, @unhead/angular, etc.) would be safer.

Additionally, the ImportDefaultSpecifier check at line 28 is dead code — defineLink and defineScript are only ever named exports across the monorepo. ImportNamespaceSpecifier (e.g., import * as h from 'unhead') also won't match this function, so users importing via namespace only receive suggestions, which is the conservative behavior.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/eslint-plugin/src/rules/prefer-define-helpers.ts` around lines 21 -
33, The helperIsImported function currently treats any ImportDeclaration with a
matching specifier name as valid; change it to also verify the import source is
one of the known unhead packages (e.g., 'unhead', '@unhead/vue',
'@unhead/react', '@unhead/solid-js', '@unhead/svelte', '@unhead/angular', etc.)
before accepting a specifier, and remove the dead ImportDefaultSpecifier branch
since defineLink/defineScript are named exports; leave ImportNamespaceSpecifier
unmatched (so namespace imports only trigger suggestions, not autofix). Ensure
you update helperIsImported (the function name) to check node.source.value
against the allowed-package list and only then inspect specifiers for
ImportSpecifier matches.

packages/devtools-app/app/composables/state.ts (1)

56-98: Lint result types LGTM; consider an automated drift guard.

The added types correctly mirror packages/bundler/src/devtools/rpc/types.ts (including endLine/endColumn, which the prior audit.vue duplication was missing) and match the discriminated union shape returned by runLintRpc. The inline comment justifying the duplication pattern is appreciated.

Since two copies now have to be kept in sync by hand, you may want a lightweight type-equivalence assertion (e.g. a satisfies check or a small expectTypeOf test importing both modules) so future divergence — for instance, if LintMessage gains a field on the bundler side — fails CI rather than silently typing it as any downstream.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/devtools-app/app/composables/state.ts` around lines 56 - 98, Add an
automated drift guard to ensure the duplicated lint types stay in sync: import
the canonical types from packages/bundler/src/devtools/rpc/types.ts and assert
equivalence against the local LintMessage, LintFileResult, LintRunResult,
LintUnavailableResult (and LintResponse) using either a TypeScript
`satisfies`-style check or a small type-only test (e.g., expectTypeOf or a
compile-time assertion) so CI will fail if the shapes diverge; place the
assertion/test near the existing type declarations in app/composables/state.ts
or in a new test file that imports both modules.

packages/devtools-app/app/pages/audit.vue (2)

31-44: Optional: clear result when starting a new run.

error.value is reset at the top of run() but result.value isn't. That's fine for the success path (it produces a smooth replace), but if a previous run succeeded and a subsequent run throws, the user sees the new error banner via v-if="error", and as soon as they dismiss/retry, the previous result (possibly from a different mode) re-appears. Either clearing result here, or clearing it on error specifically, makes the displayed state unambiguously tied to lastMode.

 async function run(mode: 'audit' | 'migrate') {
   loading.value = true
   error.value = null
+  result.value = null
   lastMode.value = mode

Non-blocking.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/devtools-app/app/pages/audit.vue` around lines 31 - 44, The current
run() clears error.value but not result.value, which causes an old successful
result to reappear after a failed run; update run() to also reset result.value
at the start (e.g., set result.value = null) so the UI state is unambiguous and
tied to lastMode.value; alternatively, clear result.value in the catch block
when handling err, but prefer clearing it at the beginning of the run() function
that calls callRpc<LintResponse>('unhead:run-lint', { mode }) to ensure no stale
output is shown during loading or on error.

---

161-161: Don't render ?:? for messages without a location.

openFile already gates on message?.line != null and falls back to opening the file without a line/column, but the template unconditionally renders {{ m.line ?? '?' }}:{{ m.column ?? '?' }}, so messages without source positions display as ?:? — visually noisy and inconsistent with the click behavior.

✏️ Proposed tweak

-                  <span class="font-mono text-muted text-[10px]">{{ m.line ?? '?' }}:{{ m.column ?? '?' }}</span>
+                  <span v-if="m.line != null" class="font-mono text-muted text-[10px]">{{ m.line }}{{ m.column != null ? `:${m.column}` : '' }}</span>

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/devtools-app/app/pages/audit.vue` at line 161, The template
currently always renders the location span "{{ m.line ?? '?' }}:{{ m.column ??
'?' }}" causing "?:?" for messages without positions; change the template to
only render the location span when m.line (or message?.line) is not
null/undefined to match openFile's gating logic—locate the span using the m.line
/ m.column bindings in audit.vue and wrap it in a conditional (e.g.,
v-if="m.line != null") so messages without locations omit the "?:?" text and
keep click behavior unchanged.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes