fix: report precise error line numbers in --show-errors

[frankieyan]

Previously, --show-errors reported the line number where the function starts rather than the exact line where the React compiler violation occurs. This made it harder to locate and fix issues.

Now --show-errors displays precise error locations:

🔍 Checking 1 file for React Compiler errors…
Errors:
    - src/bad-hook.ts: Line 9: Cannot access refs during render (x2)
    - src/bad-hook.ts: Line 10: Cannot access refs during render
❌ React Compiler errors have increased in:
  • src/bad-hook.ts: +3

The fix uses primaryLocation() for CompileError events to get the precise error location, falling back to the function location if unavailable.

Test plan

Test locally by running against the sample project fixtures:

npm run build
cd src/__fixtures__/sample-project

• Verify precise line numbers are shown

  node ../../../dist/index.mjs --show-errors --check-files src/bad-hook.ts

  Should show Line 9 and Line 10 (the actual error lines), not Line 6 (the function start).

• Verify all commands with --show-errors show precise locations

  node ../../../dist/index.mjs --show-errors
  node ../../../dist/index.mjs --overwrite --show-errors

[doistbot-app]

Thanks for this improvement to error reporting, which now shows the precise line number for React compiler violations instead of just the start of the function. This change will make it significantly easier for developers to locate and fix issues. It looks like there may be a potential runtime crash if an error's location data is incomplete, and a new dependency may have been added that appears to be unused.

[doistbot-app]

[P1] Possible runtime crash when primaryLocation object lacks start. primaryLocation() can return an object without a start (or with start undefined), so loc.start.line will throw at runtime. This will surface when the compiler provides a location object that doesn't include start (or uses a different shape), breaking --show-errors. Use optional chaining or a guard like loc && typeof loc === 'object' && loc.start ? loc.start.line : null to avoid throwing.

[frankieyan]

If we are to trust the types, then then start is a non-nullable property on the object returned from primaryLocation (SourceLocation type from Babel), if it's a non-null and non-symbol value.