-
-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ignore known template/backup file suffixes when determining file type #791
Comments
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 |
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
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. |
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"
]
}
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. |
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
).The text was updated successfully, but these errors were encountered: