oxfmt --migrate prettier|biome has implemented, however there is still room for improvement.

overrides

Current implementation:

• Uses prettier.resolveConfig() to read Prettier configuration
• This handles all config file formats that Prettier supports
  • JSON, YAML, TOML, JS, TS, etc.
  • Also handles package.json with prettier field

Problem is resolveConfig() returns resolved options, meaning overrides are also resolved.
= There is no way to access the raw overrides array from the resolved result.

• To access raw overrides, we need to stop using resolveConfig() and manually parse the config file obtained from resolveConfigFile()
• However, this means we would need to implement parsers for all config file formats ourselves:
  • .prettierrc (YAML, no extension)
  • .prettierrc.json / .json5
  • .prettierrc.yaml / .yml
  • .prettierrc.toml
  • .prettierrc.js / .cjs / .mjs / .ts / .cts / .mts
  • prettier.config.*
  • package.json (prettier field)
  • https://prettier.io/docs/configuration
• Prettier's internal config loaders are not exposed as public API

Nested config

When we first implemented this, Oxfmt didn't support nested configurations. Because of that, it is hardcoded the root as a virtual path, which means it always generates only one file.

Config file extension

Even if the original file is a prettier.config.ts file, it ends up outputting a .oxfmtrc.json file instead with resolved fixed values.

May not be formatted after migration

The generated files themselves might end up in a "dirty" state due to subsequent formatting.

This is particularly common when converting .prettierignore to ignorePatterns, where arrays may be collapsed into a single line.

It might be enough to just display a message telling the user to run the format.

Anyway, the situation has changed slightly since then.

Should we shift our focus toward improving the documentation to make it more useful for AI?