Keep unknown keys in overrides[].options

[tryone144]

Related to an issue raised in #70

Current behaviour only keeps the known configuration directives in the options object of an override. This implicitly drops any plugin configuration, while upstream prettier (legacy CLI) keeps them.

This PR copies the whole options object and only normalizes the know directives — similar to how the top-level configuration object is constructed. This now allows overriding plugin configuration for specific files.

Let me know if this isn't the way we want to go or if plugin options should be handled more strictly.

[IanVS]

Thanks, I had previously reported this in #9, which was fixed, but seems to have been subsequently broken again?

[43081j]

This looks good but can we find out why 3517afc didn't fix it already? Afaict it was intended to

Maybe we need @fabiospampinato to have a quick look before we merge this

[tryone144]

I have a hard time believing that 3517afc actually fixed this before. Its changes are limited to the CLI parsing and don't touch the config file validation directly.

I can reproduce the issue (plugin options are not respected in overrides of config file) with said commit as well as tagged release v0.5.0 that was used in the v4.0.0-alpha.9 release of prettier.

Example config

File .prettierrc.yml:

# All files
useTabs: true
tabWidth: 4
singleQuote: true
printWidth: 120

# JS/TS specific
trailingComma: es5
htmlWhitespaceSensitivity: ignore
arrowParens: avoid
quoteProps: preserve

plugins:
    - '@ianvs/prettier-plugin-sort-imports'

importOrder:
    - '^@core/(.*)$'
    - '^@server/(.*)$'
    - ''
    - '^@ui/(.*)$'

overrides:
    - files: 'frontend/**/*'
      options:
          useTabs: false
          tabWidth: 2

    - files: 'frontend/backend/**/*'
      options:
          importOrder:
              - '^@ui/(.*)$'
              - ''
              - '^@core/(.*)$'
              - ''
              - '^@server/(.*)$'

[43081j]

makes sense 👍

that's all i was wondering, didn't have time to investigate it myself

i do wonder if the normalizeFormatOptions function should just start with {...options} itself. but lets wait and see what Fabio thinks of this