Thanks for helping with the plugin ❤️
There needs more changes to be done to support extends like oxlint does.
Following changes needs to be done:

• move the logic inside buildFromOxlintConfig. This function is exported by NPM
• follow the file structure of the other oxlint config keys
• types
• ignore non file path extends
• nested extends
• creating tests for key extends
• creating tests for keys that are merged in extended files

The first 3 parts can be done easily. The others tasks, I do not expect to be resolved by you. I can follow up after that ❤️

Hey @Sysix 😄 I’ve updated the implementation based on your feedback:

• Moved the logic into buildFromOxlintConfig.
• Created a new extends.ts file with readExtendsConfigsFromConfig and handleExtendsScope. I tried following the same modular approach used for plugins or categories.
• Added a new OxlintExtendsConfigs type, currently defined as an array of strings. I assumed extends can only be an array of strings/paths.
• Added tests to validate the behavior.

Some Implementation Details:

• getConfigContent was moved to utilities so it can be reused in readExtendsConfigsFromConfig instead of duplicating logic. It felt cleaner than duplicating similar logic.
• readExtendsConfigsFromConfig:
  • Validates that the provided path exists and is a file. Non-file paths are ignored (this should cover the “ignore non-file path extends” case).
  • Reads and flattens the extended configs recursively to return an array of config contents. It felt the best place to do it.
• handleExtendsScope:
  • Merges the list of extended configs with the current one.
  • Handles only rules, plugins, and overrides (From the documentation it looks like only those keys are extended)
    • plugins are deduplicated.
    • rules are shallow-merged, with the most recent config taking precedence.
    • overrides are simply appended.
      Should we consider diffing and merging these too, or is that unnecessary?
      In my use cases I would expect overrides to not be merged

I tried to cover all the points — even the ones you said weren’t strictly necessary. If more changes are needed, feel free to guide me 😃.

Thank you ❤️

All extends should be relative to the provided config file. Someone can use oxlint.buildFromConfigFile("./folder/.oxlintrc.json").

Let me recheck, if something is done with overrides extends.
When extends: ["./folder/xyz/.oxlintrc.json"] then the overrides probably will be updated.

Extending a file without a "plugins" key will probably extend the default plugins.

If you want, you can tackle the problems down. Thank you already for the work 🫶
Will test it on Friday/weekend and try to merge it before the next release 🤞

@Sysix I tackled the problems down ☺️. However, I think the relative paths for the extends based on the provided config, should be tested carefully, maybe i should write tests for that? 🤔

@yunarch I updated the branch and simplified some bits.
getConfigContent makes already a file check and reports a warning. No need for the extra function.
Sorry if I told you to check for it.

Created a __misc property so buildFromOxlintConfig could use extends too if they provide a "fake" filePath.

Please recheck if I did not break something :)

@Sysix Everything looks good ☺️

Thank you for the work ❤️