feature request: read configuration from file about dprint HOT 3 CLOSED

The resolve_config exists today in the crate, but I don't have the global configuration part. It wouldn't be too much extra work to add.

This will get slightly easier once I have the plugin infrastructure in place.

Other Config File Formats

I don't want to have multiple ways of reading configuration in dprint and since I'm running this from node (deno in the future :)) I am just going to keep loading the config in JavaScript for now. That might change in the future though. So I'd recommend creating a config file specifically for deno, read that into key value pairs, then use the api above that I will add soon. Perhaps then one day I could adopt that back in here. Does that sound good?

Overall, I wouldn't mind adding the code for reading a json configuration file to dprint, but I don't think I'd use it.

Yes, that's perfect!

By the way, just ignore the projectType field and please don't add it to the dprint config in deno :P (I don't even have a sponsorship model in place at the moment)

Sure!

from dprint.

Most likely the configuration file would have the following structure:

{
    // optional global config
    lineWidth: 80,
    indentWidth: 2,
    useTabs: false,
    newLineKind: "\n",

    // optional language specific config
    typescript: {
        // potentially override global config for the language
        indentWidth: 4,
        // ...language specific config...
        bracePosition: "nextLine",
        // ...etc...
    },
    markdown: {
        // ...etc...
    },

    // optional includes and excludes
    includes: [
        "**/*.{ts,tsx,js,jsx}"
    ],
    excludes: [
        "packages/playground/public/vs/**/*.*",
        "packages/playground/build/**/*.*",
        "build-website/**/*.*",
        "**/dist/**/*.*",
        "**/target/**/*.*",
        "**/wasm/**/*.*"
    ]
}

So in dprint I could provide the following functionality:

// pseudocode...
use dprint_core::{resolve_global_config};
use dprint_plugin_typescript::{resolve_config};

let mut config_map: HashMap<String, String> = ...; // parse json to string key/value pairs

// assume exists for this example... probably want something better than re-deserializing this
// from a string...
let typescript_config_map = deserialize_to_hash_map(config_map.remove("typescript").unwrap());

// get the global config
let global_config_result = resolve_global_config(&config_map);

for diagnostic in global_config_result.diagnostics {
    // includes stuff like excess properties and such
}

// resolve the typescript config
let config_result = resolve_config(&global_config_result.config, &typescript_config_map);

for diagnostic in config_result.diagnostics {
    // do something...
}

// now format with config_result.config...

The resolve_config exists today in the crate, but I don't have the global configuration part. It wouldn't be too much extra work to add.

This will get slightly easier once I have the plugin infrastructure in place.

Other Config File Formats

I don't want to have multiple ways of reading configuration in dprint and since I'm running this from node (deno in the future :)) I am just going to keep loading the config in JavaScript for now. That might change in the future though. So I'd recommend creating a config file specifically for deno, read that into key value pairs, then use the api above that I will add soon. Perhaps then one day I could adopt that back in here. Does that sound good?

Overall, I wouldn't mind adding the code for reading a json configuration file to dprint, but I don't think I'd use it.

By the way, just ignore the projectType field and please don't add it to the dprint config in deno :P (I don't even have a sponsorship model in place at the moment)

from dprint.

@bartomieju released in 0.3.0-alpha.5.

See here for docs and an example: https://docs.rs/dprint-plugin-typescript/0.3.0-alpha.5/dprint_plugin_typescript/configuration/fn.resolve_config.html

Note that all the configuration related stuff has been moved to a configuration sub module. For setting your own defaults, I recommend just inserting into the hashmap if no key exists there.

Also, in the future this api will be easier to use... this is just stepping stones to the final plugin formatter.

Good luck and let me know if you need anything else for this! :)

from dprint.