context.languageOptions.parser is I believe the only ESLint v9 API that we haven't implemented yet.
The lack of this feature has been said to block Svelte community from migrating to Oxlint.
Reason is that it's tricky is that Oxlint's JS-side code is architected for performance, and one aspect of that is that pretty much everything is a singleton, including the current AST. That works because linting is single-threaded and synchronous, so only one AST is "in play" at any time. But if we expose the ability to parse code in the middle of linting, it breaks that assumption.
I realised that I think we can work around this problem by using normal JSON transfer for AST in parser.parse. That would be slower than raw transfer, but it'd solve the problem of conflicting with the AST which Oxlint uses internally - they'd be completely disconnected code paths and data structures.
Like oxc-parser, loc property wouldn't be present on AST nodes (#10307), but probably that won't affect most use cases. start, end, and range would be present on all nodes. We also have the beginnings of support for tokens in oxc-parser.
context.languageOptions.parseris I believe the only ESLint v9 API that we haven't implemented yet.The lack of this feature has been said to block Svelte community from migrating to Oxlint.
Reason is that it's tricky is that Oxlint's JS-side code is architected for performance, and one aspect of that is that pretty much everything is a singleton, including the current AST. That works because linting is single-threaded and synchronous, so only one AST is "in play" at any time. But if we expose the ability to parse code in the middle of linting, it breaks that assumption.
I realised that I think we can work around this problem by using normal JSON transfer for AST in
parser.parse. That would be slower than raw transfer, but it'd solve the problem of conflicting with the AST which Oxlint uses internally - they'd be completely disconnected code paths and data structures.Like
oxc-parser,locproperty wouldn't be present on AST nodes (#10307), but probably that won't affect most use cases.start,end, andrangewould be present on all nodes. We also have the beginnings of support for tokens inoxc-parser.