Ignore known template/backup file suffixes when determining file type

[Ville Skyttä]

Would be nice for dprint to ignore various trailing known filename suffixes that are commonly used for template or backup files.

bat does it by first checking if a filename resolves to a known file type; while not, iterate through a list of known template/backup filename extensions, remove one if found (one at a time), and do the check for the resulting filename, looping more until no ignored extension is found. This is good as it allows an arbitrary number of ignored trailing extensions, for example .in.in are not that rare.

Backup filenames are not terribly interesting in dprint's case, but support for them wouldn't hurt. The template ones would be more useful (for example foo.json.in).

[David Sherret]

Would you be able to expand on what you mean? I don't fully understand. For example, given a dprint configuration file, list of files on the file system, and running dprint output-file-paths, what would be some example output?

[Ville Skyttä]

Basic dprint config file in the current directorly, like

{
  "json": {
  },
  "excludes": [
    "**/*-lock.json"
  ],
  "plugins": [
    "https://plugins.dprint.dev/json-0.19.1.wasm"
  ]
}

File named foo.json.in in the current directory, with JSON inside.

dprint fmt foo.json.in would format it as JSON. Currently it errors out with "No files found to format with the specified plugins at ...".

But note that this is in no way limited to JSON. The ignored suffix processing would apply to all filenames and filename extensions recognized by dprint.

[David Sherret]

This is possible today by using the associations feature:

{
  "json": {
    "associations": "**/*.{json,jsonc,json.in}"
  },
  "excludes": [
    "**/*-lock.json"
  ],
  "plugins": [
    "https://plugins.dprint.dev/json-0.19.1.wasm"
  ]
}

But note that this is in no way limited to JSON. The ignored suffix processing would apply to all filenames and filename extensions recognized by dprint.

Right now, the dprint CLI gets the extensions to format from the plugins. Perhaps it could get these extensions then also add searching for these other backup extensions. However, this would greatly expand the number of file extension tests it needs to do per file, which might affect performance. Additionally, I think some people might find this behaviour undesirable. It also seems like an edge case that the associations feature covers.

I'm wondering if perhaps these kinds of extensions should only be matched for if they are explictily provided on the command line.