support zero configuration

[kevgo]

I find myself adding many dprint.json files that consist more or less of the standard dprint configuration. One of the biggest value propositions of gofmt, rustfmt, Prettier, StandardJS, YAPF, and other formatters is that they end the pointless bikeshed debates around code style by formatting everything into a style that everybody gets used to and then feels at home at. In this line of thinking (which is getting more popular these days), configuration and customizations are the exception to the rule. Good tools know their domain and do "the right thing" without needing manual configuration (but are of course flexible if needed).

Dprint is in a perfect position to be such a tool. To be the formatter that even ends the bikeshed debates which formatter to use! Without a configuration file, dprint could simply find all the files it can format and format them in dprint code style. If anybody feels strongly that dprint should behave more specific to their particular situation, they can always create a configuration file.

[joscha]

not a full answer on this, but --config allows you to pass a URL, so you can do a

dprint --config https://raw.githubusercontent.com/dprint/dprint/main/dprint.json check -- '**/*'

in any arbitrary folder and it will use the config and all referenced plugins to check all files that it can match.

Two caveats:

• bear in mind that the linked dprint.json above is unversioned and mutable, so depending on when you execute this, the result will differ
• referenced non-WASM plugins are not loaded via URLs

[dsherret]

This ties in with #355 and #410. The CLI itself doesn't really have any knowledge of the plugins, so there would need to be some way of configuring this (either via a global config file or some way to do it in the CLI) and it would have some defaults.

I don't view this solution is viable for a project to use, but more for one-off formatting. The project needs a config file stored in the repo to at least say what version of plugins should be used, otherwise everyone's plugin versions could easily be out of sync.

[joscha]

We could produce a repository in the dprint org space with an opinionated default configuration and one in each plugin repositories as well. If we tag these properly and never move tags then the main config could reference all plugin configs and you could have one global JSON endpoint that you can pass to --config - that would allow a prettier-like zero configuration usage of dprint, given you have the URL. The only caveat is that the list of plugins would grow over time, so whilst version 0.1 might have JSON,md,TS,toml future versions might grow excessively with every plugin in the dprint space to provide an opinionated variant.

FWIW whilst I completely understand the want for such a zero configuration kickstarter one of the strong reasons on why we chose dprint was because it was exactly not opinionated. Keeping it that way, independently whether there exists such an opinionated ootb provided config or not, would be great. Especially larger organizations with an opinionated set of formatting rules might have the need for their own config themselves. The fact that dprint allows config resolution via URLs should make it possible for everyone to easily produce their own opinionated global set of config values regardless.

[scottwillmoore]

This would be an awesome feature. I also support the idea of a default repository which can be overwritten by a .dprintrc.json, or .config/dprint.json. I often work on configuration files that are outside of a project, and many projects do not have a dprint.json. This makes dprint a little difficult to use with Visual Studio Code at the moment when compared with Prettier. Also, in these cases I usually don't care about a pinned version, I just want the latest version available.

I would be happy to help work on a pull request (or proposal) for dprint if everyone agrees on a good default. I think what @joscha suggestion makes a lot of sense. To add to it, dprint should probably lazily download plugins in the default configuration (with an option somewhere to download them all if desired), or just have a dprint install and dprint update command which can fetch the latest version.

Related: dprint/dprint-vscode#13

[azzamsa]

Come here for the same need. I use dprint across my repositories. But the config is just the same. It doesn't contain anything but plugin declarations. So it would be useful if the CLI is aware of the default config and we just need to pass --plugins toml,json without any additional configuration file.

[tomdavidson]

If one uses a system binary in the exec plug-in then some of the the one and done magic is gone. After reading this discussion I think I should move those outside of dprint until they are dprint plugins.

Soon as all the kinks are worked, out, Im just going to move my dprint.json to a open/shared space and provide the URL to the --config flag. Zero config with in my domain with some wiggle room.

Some auto magical stuff with the CLI recognizing the scm and looking the org's config in a conventional location might be nice, but coudnt we just place the org's dprint.json with a sharable config pkg if we didnt want to pass a config URL?

[godalming123]

I think that this could be implemented by having the --config flag set itself to ./dprint.json:$HOME/.dprint/dprint.json:/usr/env/dprint/dprint.json instead of being ./dprint.json by default. And then dprint would try to resolve the directories in that order. If the user has not created any dprint configs, then eventually dprint would fall back to it's default configuration (in this case assumed to be in /usr/env/dprint/dprint.json.) This would mean that the only setup needed to use dprint would be to install dprint to $PATH, and then set your editor up to use dprint, while still allowing users to edit their dprint config either for all files, or for just files in their project.