feat: support extends configuration from oxlint config content

[yunarch]

Description

This PR introduces an initial implementation to support the extends property in configuration files and follow the full chain of extended files.

Currently, it handles merging of only the following fields:

• rules
• plugins
• overrides

These are the only fields currently supported by oxlint, and it doesn’t appear necessary to support others at this stage.

Fixes #386

[Sysix]

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 ❤️

[yunarch]

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 😃.

[Sysix]

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 🤞

[yunarch]

@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? 🤔