Error on invalid configuration

[hauntsaninja]

Currently if you make a typo when configuring Black you don't get an error

[JelleZijlstra]

I'm a little concerned this could cause problems if people use the same configuration file across multiple versions of Black. Do other comparable tools tend to raise errors on any unrecognized keys?

[dankrzeminski32]

I'm a little concerned this could cause problems if people use the same configuration file across multiple versions of Black. Do other comparable tools tend to raise errors on any unrecognized keys?

Ruff and isort notified me of incorrect settings.

Ruff:

(venv) ➜  test_ruff_typo ruff test.py
ruff failed
  Cause: Failed to parse /Users/danielkrzeminski/Desktop/test_ruff_typo/pyproject.toml
  Cause: TOML parse error at line 1, column 1
  |
1 | [tool.ruff]
  | ^^^^^^^^^^^
unknown field `lin-length`

isort (raises UnsupportedSettings):

File "/Users/danielkrzeminski/Desktop/test_ruff_typo/venv/lib/python3.11/site-packages/isort/main.py", line 1123, in main
    config = Config(**config_dict)
             ^^^^^^^^^^^^^^^^^^^^^
  File "/Users/danielkrzeminski/Desktop/test_ruff_typo/venv/lib/python3.11/site-packages/isort/settings.py", line 529, in __init__
    raise UnsupportedSettings(unsupported_config_errors)
isort.exceptions.UnsupportedSettings: isort was provided settings that it doesn't support:

	- proile = hug  (source: '/Users/danielkrzeminski/Desktop/test_ruff_typo/pyproject.toml')

For a complete and up-to-date listing of supported settings see: https://pycqa.github.io/isort/docs/configuration/options.

[JelleZijlstra]

Thanks! Prettier just shows a warning:

% prettier --write docs 
[warn] Ignored unknown option { prroseWrap: "always" }. Did you mean proseWrap?

That might be a safer option.

[dankrzeminski32]

Agreed, I'll adjust the PR to print a warning instead.

[hauntsaninja]

The downside of a warning is that we encourage our users to invoke Black less interactively, e.g. via IDE or pre-commit or whatever. Still, definitely better than today / we can always make it stricter later if we feel the need to!

cause problems if people use the same configuration file across multiple versions of Black

I think this might be a feature if the config file contains flags specific to some version of Black

[JelleZijlstra]

I think this might be a feature if the config file contains flags specific to some version of Black

That's definitely a reasonable point, but we already have the required_version flag to do that explicitly. There are some reasonable situations where we could drop a flag but it's harmless if a user still specifies it. Example scenario: in Black 24.2 we decide to drop the --color flag (https://black.readthedocs.io/en/stable/usage_and_configuration/the_basics.html#color-no-color). If a project sets color = false in its config for the benefit of users running Black 24.1, it's not a big deal for users running Black 24.2 if the flag is still there.