Allow global dprint config file

[khrj]

I often use the dprint vscode extension, and I'm editing a file that's not part of the current folder. It'd be great to support a global dprint config file, something along the lines of ~/.dprint/dprintrc.json.

A command called dprint init-with-global would also be great, and it'd just copy the global config file to your current directory.

[disrupted]

I agree. This would be great to have and make it easier to manage consistent formatting across projects.

[dsherret]

This is something that could be added to the VS code extension. I've opened https://github.com/dprint/dprint-vscode/issues/13

For the CLI, it's possible to specify a config file via the --config flag and you can specify a URL there or a file path on the file system (see https://dprint.dev/cli/). I don't want to encourage having a global configuration file as people should define configuration files per project so that someone else who goes to work on that project can know what the config is for that project.

That said... if you are on linux and only working from a descendant directory of the home folder then it is possible to define a configuration file at ~/.dprint.json (hidden file config name is supported in dprint >= 0.13.0) and the CLI will pick it up if it can't find a config file in a closer directory (on windows, you could put it in the root folder of wherever you do development from).

This would be great to have and make it easier to manage consistent formatting across projects.

To ensure this, you should create a dprint configuration file per project, but you can host a configuration file somewhere and specify that in an "extends" property. For example:

{
  "$schema": "https://dprint.dev/schemas/v0.json",
  "incremental": true,
  "extends": "https://yourdomain/path/to/config/file.v1.json",
  // todo: specify includes and excludes here
}

Or even...

{
  "$schema": "https://dprint.dev/schemas/v0.json",
  "incremental": true,
  "extends": [
    "https://yourdomain/path/to/config/file.v1.json",
    "https://yourdomain/path/to/config/other.v1.json"
  ],
  // todo: specify includes and excludes here
}

See https://dprint.dev/config/ for more details.

[dsherret]

Comment from @insomnimus:

Please support a global config file.

Running dprint init is fine, however it always initializes with the defaults and I always end up configuring it.

I know i can pass the config file from the command line but a default one is many times better than specifying it through the command line each time.

I also tried adding .dprint.json at the root of my development directory but this doesn't work well because everything under the root directory gets formatted.

Another way of accomplishing this would be if dprint supported extensions like cargo. For example some dprint-custominit in $PATH, where I myself could write the executable.

I think it's worth exploring this a bit more.

[dsherret]

What I'm thinking here is essentially:

1. If the ancestor directory tree HAS a dprint configuration file in it (local config):
   • It will resolve to using that config and work as-is.
2. If the ancestor directory tree does NOT have a dprint config file in it:
   1. It will print a warning that it's using the global config.
   2. The global configuration will be similar to a local configuration and contain a list of plugins along with their configuration.
      • I'm not sure that having an "includes" or "excludes" is useful or makes sense so probably at the start these would be ignored.
   3. If there are any plugins out of date, it will print a warning MAX once a week that their plugins are out of date and they can run dprint config update to update their plugins.
   4. MAYBE: If no global configuration file exists, then it will use a default remote configuration file that contains the latest plugins.

The global configuration would be stored in the user's local application data. Since this isn't always that easy to find, I think it would be beneficial to add a dprint config edit command that would launch an editor to edit the local or global configuration depending on what folder the user is in.

[edwardloveall]

Thanks for considering this 🙂 My primary use case is formatting my git commit messages which I write in markdown so having a global config is exactly what I need. I have a little feedback on your proposed idea above:

• 1: 👍
• 2-i: I'm not sure a warning would be helpful, or at least not by default. Maybe in a verbose mode? I generally treat warnings as a bad practice I should consider fixing, but this sounds like a feature not a bad practice. Is that how you see it?
• 2-ii: I think includes and excludes could make sense because they support patterns and not just specific files. e.g. "I want to format all markdown documents wherever I am". Treating both global and local configs the same also has the advantage (I assume) of making the configuration code simpler.
• 2-iii: that makes sense as a warning to me 👍

[edwardloveall]

And FWIW, I found a couple tools that do something similar:

• bottom: code, docs
• pijul: code, docs
• lsd: code, docs
• tokei: code, docs
• procs: code, docs

Here's also an interesting spec that some of these tools use, if that's helpful: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

[ZaLiTHkA]

howdy.. 🖖🏼

I started down the path of reseaching dprint earlier this evening, and one of my biggest questions was quite simply: "what happens when there's no local config file?" and suddenly I was falling down a rabbit hole..

so, I see this idea has already been around for a while, but as it's still open I'm going to bravnaively asuming it's still open for discussion.. 🤔

---

first a little disclaimer: I have always preferred the idea of unopinionated configuration for tools like this. I firmly believe that certain things, such as codebase formatting, should be explicitly defined by the developer(s) responsible for a project. this is also not something that should change very often at all, even (especially?) across multiple projects under the same group.

if you get tired of setting the same config for every project, well.. then get lazy and script it. heck, create an alias with your preferred command and arguments and call dprintify once whenever you generate a new project (which is most likely also a one-liner, if you do that often enough).

still, I fully appreciate the convenience of the more opinionated tools as well (I use Prettier.. a lot..), but I'm also all too keenly aware of how limiting these systems can be. for example, Prettier and "explicit multi-line formatting", ultimately resulting in a third-party plugin called prettier-plugin-multiline-arrays being created for those specific cases (and yes, I use that too.. a lot..).

---

with that out of the way, I fully agree with @dsherret here:

This is something that could be added to the VS code extension. I've opened dprint/dprint-vscode#13

adding "default" or "base" configuration logic to an IDE makes perfect sense. in my mind, one of the biggest benefits of any Integrated Development Enviromnent is the numerous layers of "configurability" they provide.. alas, I fear I might effectively be preaching to the choir on that front.

but at the same time, I believe the CLI can do a little more of the legwork here, affording an opportunity to bring CLI and IDE usage more inline with each other.

so, building on the concept of a --global CLI tool argument...

For the CLI, it's possible to specify a config file via the --config flag and you can specify a URL there or a file path on the file system (see dprint.dev/cli). I don't want to encourage having a global configuration file as people should define configuration files per project so that someone else who goes to work on that project can know what the config is for that project.

...what if this was effectively just an alias for something akin to --config ~/.dprint.json?

in this case, I would say the following guidelines would be sufficient for providing near-zero configuration, without sacrificing per-project customisations:

• with local project configuration, pick that and don't check any other possible config locations
• without local project configuration or with --global set, try use the file at ~/.dprint.json.
• without any of the above, dprint has no rules to reference and, well, simply does nothing.. or prints a warning (CI/CD env?).. or throws an error (dev env?)..

naturally, the --global and --config <path> arguments would have to be mutually exclusive. in which case I would favour the explicit --config argument over anything else. (or throw a usage warning.. or error.. etc)

---

there is one point here that I feel might be a little too limiting though, highlighted below:

That said... if you are on linux and only working from a descendant directory of the home folder then it is possible to define a configuration file at ~/.dprint.json (hidden file config name is supported in dprint >= 0.13.0) and the CLI will pick it up if it can't find a config file in a closer directory (on windows, you could put it in the root folder of wherever you do development from).

why does the working directory need to be a descendant of the user's home folder? sure, my workspace folder lives within my user folder, and I assume many other peoples' do as well.. but I have dev friends (yay) who put theirs on a completely separate partition to their user profile folder.

I would say, first search up the tree from the current working directory, then check the explicit user home folder path afterwards if need be.

at the end of the day, developers are lazy... if we don't need to do something, we don't. and if we need to do something repeatedly, we script it. 😎 not so?

[ghost]

Instead of a dotfile in the user's home directory, please consider storing in the standard config directory of the OS. This crate documents them pretty well: https://github.com/dirs-dev/directories-rs#readme

[nuke-web3]

Really would love this feaure, outside the use of VSCode - for example, I use https://docs.helix-editor.com/ and would like to call dprint from anywhere on file types I have in a global config and also (presumably required) global cache of the plugins set there.

IMHO the ideal would be to have a default global setting for the cached plugin - if it matched the local config - be used instead of re-installing the plugin in that local .cache/... location.

[utkarshgupta137]

My use case is that I want to use dprint for all my formatting. My work projects all have dprint configuration, but most of my other projects don't. I don't think there is an easy way in most editors to say to try dprint & fallback to prettier if it fails. So I want to use dprint everywhere. So I want a fallback to a global file, but as others have noted, it is not preferable to have it in $HOME.

Instead of a dotfile in the user's home directory, please consider storing in the standard config directory of the OS. This crate documents them pretty well: https://github.com/dirs-dev/directories-rs#readme

Please don't use this crate as it uses a really obscure path on macOS. Most users on macOS prefer the XDG paths. If you want to be able to do it easily, might I suggest etcetera instead (disclosure: I maintain it). If the maintainers are interested, I can raise a PR.