fix: avoid requiring eslint package metadata

[camc314]

fixes oxc-project/oxc#17734 (comment)

There are scenarios when eslint will not be available - e.g. when using oxlint.

This PR adds some safety when requiring eslint to avoid message.js throwing an error, and preventing oxlint user from using this plugin.

cc @xsjcTony

[codecov]

Codecov Report

❌ Patch coverage is 66.66667% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 97.69%. Comparing base (c9a2de7) to head (1861533).

Files with missing lines	Patch %	Lines
lib/util/message.js	66.66%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4010      +/-   ##
==========================================
- Coverage   97.71%   97.69%   -0.02%     
==========================================
  Files         137      137              
  Lines       10188    10192       +4     
  Branches     3797     3798       +1     
==========================================
+ Hits         9955     9957       +2     
- Misses        233      235       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds a defensive fallback for environments where eslint isn’t installed (e.g., oxlint), preventing lib/util/message.js from throwing when trying to read ESLint’s package metadata.

Changes:

• Wrap require('eslint/package.json') in a try/catch to tolerate missing ESLint installations
• Switch message selection logic to depend on an optional eslintVersion value

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[camc314]

this seems unnecessary - the only thing that can throw here is requireing eslint/package.json

[ljharb]

This is an eslint plugin, and if something wants to support eslint plugins, it shouldn't require any changes in the eslint plugin, no matter what it's doing.

If we can't detect the eslint version, the plugin can't function properly, and its use is not supported. Perhaps oxlint can rewrite specifiers to produce the appropriate eslint package.json?