feat(napi/oxlint): add getFilename + getPhysicalFilename methods to Context

[overlookmotel]

Add getFilename and getPhysicalFilename methods to Context, to match ESLint's API.

[overlookmotel]

• feat(napi/oxlint): add getFilename + getPhysicalFilename methods to Context #12481 👈 (View in Graphite)
• feat(napi/oxlint): add filename property to Context #12497
• refactor(napi/oxlint): diagnostics communicate which rule via rule index, not rule ID #12482
• main

---

How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

• 0-merge - adds this PR to the back of the merge queue
• hotfix - for urgent hot fixes, skip the queue and merge this PR next

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.

[camc314]

i don't think we should implement deprecated APIs, just for the sake of filling out the context object

[overlookmotel]

I figured these methods are part of ESLint's API, so we should include them, even though they're deprecated. An older ESLint plugin might otherwise work quite happily with Oxlint, but it'd break if it uses these APIs.

[camc314]

Lets chat in a bit? I don't quite agree, especially since we don't have full compat with eslint, i don't think we should fill out deprecated APIs, we shuold instead push plugin maintainers to use the new APIs.

More of my reasoning is adding something deprecated, means that we definitly will remove it at some point which means a breaking change ect

[overlookmotel]

OK, we disagree here. I think we're aiming for ESLint compat, so we need to provide all ESLint's APIs, regardless of whether those APIs are deprecated or not.

But it's not important (yet). Feel free to close this if you disagree and we can always return to it later once we've confirmed that we are definitely going for ESLint compat.

[camc314]

yeah sorry to be a pain. I think let's close for now and return once it's confirmed.

[codspeed-hq]

CodSpeed Instrumentation Performance Report

Merging #12481 will not alter performance

_{Comparing 07-23-feat_napi_oxlint_add_more_file_path-related_apis_to_context_ (e053438) with main (515b473)¹}

Summary

✅ 34 untouched benchmarks

Footnotes

1. No successful run was found on 07-24-feat_napi_oxlint_add_filename_property_to_context_ (1e097b1) during the generation of this report, so main (515b473) was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[connorshea]

We may want to start opening issues in ESLint plugins still using getFilename/getPhysicalFilename if we intend to keep this decision (or maybe even start opening PRs to fix plugins where possible):

❌ Output for rule "storybook/default-exports":

  x Error running JS plugin.
  | File path: /Users/connorshea/code/oxlint-jsplugin-checker/testfile.ts
  | TypeError: context.getFilename is not a function
  |     at Program:exit (file:///Users/connorshea/code/oxlint-jsplugin-checker/node_modules/.pnpm/eslint-plugin-storybook@10.0.1_eslint@9.38.0_jiti@2.6.1__storybook@10.0.1_@testing-libr_b0686cb35cfd040b26303d90bb3d9af4/node_modules/eslint-plugin-storybook/dist/index.js:748:67)
  |     at walkProgram (file:///Users/connorshea/code/oxlint-jsplugin-checker/node_modules/.pnpm/oxlint@1.26.0/node_modules/oxlint/dist/plugins.js:9083:94)
  |     at lintFileImpl (file:///Users/connorshea/code/oxlint-jsplugin-checker/node_modules/.pnpm/oxlint@1.26.0/node_modules/oxlint/dist/plugins.js:10031:63)
  |     at lintFile (file:///Users/connorshea/code/oxlint-jsplugin-checker/node_modules/.pnpm/oxlint@1.26.0/node_modules/oxlint/dist/plugins.js:10001:10)
  |     at lintFileWrapper (file:///Users/connorshea/code/oxlint-jsplugin-checker/node_modules/.pnpm/oxlint@1.26.0/node_modules/oxlint/dist/cli.js:411:9)

Link to storybook eslint plugin source: https://github.com/storybookjs/storybook/blob/v10.0.5/code/lib/eslint-plugin/src/rules/default-exports.ts#L102

[overlookmotel]

Personally, I think we should reverse the decision and implement these APIs. IMO it's no big deal - they're all just another access method for data that existing getters on Context already provide.

Even if they disappear from ESLint in v10, there's no big problem I think with us supporting them indefinitely.

Trying to get every ESLint plugin to update is going to be an impossible task. Let's just accept the world as it is, warts and all!

Note: It's not just getFilename and getPhysicalFilename. There's a whole bunch of these deprecated get* methods.

[camc314]

Lets chat monday?