[FEATURE] Support `--configuration .../pyproject.toml`

[RenjiSann]

• [x] I've searched the issues
• [x] I've read the docs

Feature Request

Hi ! Currently, the CLI parameter --configuration needs to be given a path to a .djlintrc JSON file, but there is no way to specify a path to a pyproject.toml file.

In my use case, my pyproject.toml is in a subfolder of the git repo, so the djlint pre-commit hook needs to be passed the path to the file as an argument.

Have a good day !

[welcome[bot]]

Thanks for opening your first issue here!

[RenjiSann]

After looking a bit at the code, it looks like when specifying a config file with --configuration ../.djlintrc, the given configuration might be overriden by the configuration present in the CWD.

This raises some questions to me:

1. Shouldn't --configuration flag prevent djlint from searching for any config file in the CWD ? (my guess is it should)
2. If not, shouldn't it at least have priority over the discovered config files, as it is explicitely given ?
3. In the case where --configuration config loading fails (no such file, not a config file, etc...), should djLint abort or go on with discovered config files (or default config) ?
4. In the case where there is a .djlintrc and a pyproject.toml with [tool.djlint] section in the same folder, what should the behavior be: 4.1. Only read one of the two arbitrarily (I would say .djlintrc first, as it is its sole purpose) 4.2. Read both configs and merge them, while giving priority to one arbitrarily (I would say .djlintrc again) 4.3. Anyway maybe that should print some sort of warning imo

Based on these questions, here is how I would see the most sound solution:

flowchart TD
    x(Default config) --> 0
    0{--configuration flag ?} -->|yes| 1(Read given file)
    0 -->|no| 2(Search for config in filesystem)
    1 -->|file error| 3(Abort)
    1 -->|ok| 6(Apply given file options)
    2 -->|found| 4(Apply found config file options)
    2 -->|not found| 7
    2 -->|conflicting files| 9(Warning + Apply .djlintrc options)

    9 --> 7
    6 --> 7
    4 --> 7
    7(Apply CLI options) --> 8(Final config)

Please feel free to discuss this workflow :grin:

[christopherpickering]

This looks good, I'm just wondering if local config should continue to override the global?

In any case I will be happy to accept a pr to address the primary issue. Thanks for thinking this through.

[christopherpickering]

:tada: This issue has been resolved in version 1.34.0 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket: