feat(config): walk file hierarchy for project configuration

[Nytelife26]

Relevant issues

Required for #1466.

Brief

The current naïve implementation of attempting to load configuration from the current working directory is insufficient for having project-wide selection of checks. Here, we traverse the file tree down to the current working directory in search of configuration files, enabling proselint to find them at the project root.

This approach is not perfect, and may cause strange behaviour. It would be worth evaluating the configuration approach taken by other linters down the line for a more concrete solution, such as walking up the file tree and stopping at the nearest configuration file instead of merging them all together.

Changes

• Walk the filesystem hierarchy to find project configuration above the current working directory

Remaining items

• Document configuration behaviour and loading order

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.56%. Comparing base (505e07c) to head (e7a90eb).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1468   +/-   ##
=======================================
  Coverage   92.56%   92.56%           
=======================================
  Files         100      100           
  Lines        1022     1022           
=======================================
  Hits          946      946           
  Misses         76       76           

Flag	Coverage Δ
macos-latest	91.97% <100.00%> (ø)
py3.10	92.56% <100.00%> (ø)
py3.11	92.56% <100.00%> (ø)
py3.12	92.56% <100.00%> (ø)
py3.13	91.97% <100.00%> (ø)
py3.14	91.97% <100.00%> (ø)
ubuntu-latest	91.97% <100.00%> (ø)
windows-latest	92.56% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[drainpixie]

I agree that our behaviour might be a bit quirky right now, I'd personally suggest having explicit inheritance (e.g. an extends key) over our current model, implicit merging can be a source of major headaches and it's not in line with major linters such as Ruff & ESLint either way.

Global configuration should probably be highly discouraged as well since it'll become as unwieldy and unpredictable as implicit merging.

[Nytelife26]

Global configuration should probably be highly discouraged as well since it'll become as unwieldy and unpredictable as implicit merging.

I think global configuration can be useful. It'd be rather irritating to have to copy your default configuration around everywhere. My proposal would be to search for per-project configuration first, and completely discount global configuration if per-project configuration is found (the approach taken by rustfmt). What do you think?

[drainpixie]

Global configuration should probably be highly discouraged as well since it'll become as unwieldy and unpredictable as implicit merging.

I think global configuration can be useful. It'd be rather irritating to have to copy your default configuration around everywhere. My proposal would be to search for per-project configuration first, and completely discount global configuration if per-project configuration is found (the approach taken by rustfmt). What do you think?

That, or having a base extends you can enable sound good.