feat(wrapperModules.dprint): init

[rachitvrma]

add: Dprint is a code formatter built in rust. More detail in https://dprint.dev/

[BirdeeHub]

How is the package actually learning about our config file?

We constructed it. But I don't see us doing anything with it?

[rachitvrma]

My bad. Fixed now.

[rachitvrma]

Sorry, failed to run check first.

[BirdeeHub]

https://dprint.dev/cli/#using-a-custom-config-file-path-or-url

They have some kind of warning, and some resolution variable. Maybe we should make some kind of enum option for this other variable, and/or make setting --config optional and make sure the resolution thing is set correctly to find it when it is set?

I need to sleep but, look into that, otherwise seems like a good thing to wrap, could be quite useful for dev shells and stuff, and it doesnt write to its config file, so that should be all that is needed.

[rachitvrma]

    {
      wlib,
      pkgs,
      config,
      lib,
      ...
    }:
    let
      jsonFormat = pkgs.formats.json { };

      configJson = config.settings // {
        plugins = map (p: "${p}/plugin.wasm") config.plugins;
      };
    in
    {
      imports = [ wlib.modules.default ];

      options = {
        settings = lib.mkOption {
          inherit (jsonFormat) type;
          default = { };
          description = ''
            Settings to add to dprint.json.
          '';
          example = {
            excludes = [
              "**/node_modules"
              "**/*-lock.json"
            ];
            json = { };
            malva = { };
            markdown = { };
            toml = { };
            typescript = { };
            yaml = { };
          };
        };

        plugins = lib.mkOption {
          type = lib.types.listOf lib.types.package;
          default = [ ];
          description = ''
            Plugins to add to dprint runtime.
          '';
          example = lib.literalExpression ''
            plugins = with pkgs.dprint-plugins; [
              g-plane-pretty_yaml
              dprint-plugin-typescript
              dprint-plugin-json
              dprint-plugin-markdown
              dprint-plugin-toml
              g-plane-malva
            ];
          '';
        };
      };

      config = {
        package = lib.mkDefault pkgs.dprint;

        constructFiles.generatedConfig = {
          relPath = "${config.binName}-config/${config.binName}-config.json";
          content = builtins.toJSON configJson;
        };

        env.DPRINT_CONIFG_DIR = "${placeholder "out"}/${config.binName}-config";

        # flags = {
        #   "--config" = config.constructFiles.generatedConfig.path;
        # };

        meta.maintainers = [ wlib.maintainers.rachitvrma ];
      };
    }

We can have something like this.

[BirdeeHub]

env.DPRINT_CONIFG_DIR = "${placeholder "out"}/${config.binName}-config";

Is there something better about using this variable over --config?

Also you might enjoy setting it this way?

env.DPRINT_CONIFG_DIR = dirOf config.constructFiles.generatedConfig.path;

Does this just make it replace the normal global config dir with this one and otherwise still behave like normal, whereas --config is a 1 time use thing? I didnt see this variable in the docs when I looked last.

[rachitvrma]

IDK. The article just states that it is a "better experience" to not use the
--config flag and rather use the default config path($XDG_CONFIG_HOME/dprint/dprint.json)

Other than that it also gives the flag to disable config discovery. So maybe we can use either the
environment variable or the --config flag, but seeing the article, it doesn't say anything
about setting the environment variable causing a bad user experience, so just by that I think
we can use the environment variable (?)

---

Should we use the --config-discovery=false by default?

[BirdeeHub]

Ummm, unsure. I would need to test to see how it behaves with the env var vs the arg.

If it just pretends the env var is the normal global location, that is ideal for us. If it does something weird, then whatever just use --config

I am not sure what the best default for that resolution arg is, but we definitely should have a lib.types.enum option for it

[rachitvrma]

like you mean give users the option to choose to either use the --config flag or use the DPRINT_CONFIG_DIR variable?

[BirdeeHub]

No i mean actually try --config and DPRINT_CONFIG_DIR with different settings for --config-discovery, in order to figure out the differences between these methods for specifying the location of the config. They don't give us adequate info in the docs, so one of us has to take the time to experiment and figure out what it actually does.

If it turns out that DPRINT_CONFIG_DIR is treated as if it is the global config dir for the purposes of the --config-discovery option, that is good, that is what we want. We should use it in that case.

If it is not treated in that way, and it is treated in the same manner as --config is, then in that scenario --config would be the cleaner approach, as it points the file rather than the dir. But, if DPRINT_CONFIG_DIR is treated exactly like the global dir, then that would be better, and we would use DPRINT_CONFIG_DIR instead.

If DPRINT_CONFIG_DIR behaves exactly like the global config dir, then we should make a lib.types.enum option for --config-discovery, possibly defaulting to false, and use DPRINT_CONFIG_DIR to set the value.

Otherwise, we would just use --config and not worry about --config-discovery, because --config ignores discovery anyway

[rachitvrma]

Okay. I'll try it out.