Ignore known template/backup file suffixes when determining file type

[scop]

Ignore known template/backup file suffixes when determining file type

[dsherret]

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?

[scop]

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.

[dsherret]

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.