Unable to follow minimal template due to error using prettier

[sstitle]

I followed exactly the steps for setting up the minimal template here: https://std.divnix.com/templates/minimal.html

test-std-project on  main [!+]
❯ git add . && git commit -m "feat: initial commit"
╭──────────────────────────────────────╮
│ 🥊 lefthook v1.5.2  hook: pre-commit │
╰──────────────────────────────────────╯
sync hooks: ✔️ (pre-commit, commit-msg)
┃  treefmt ❯

[WARN ] cache: failed to load the manifest due to: No such file or directory (os error 2)
[INFO ] #nix: 3 files processed in 9.57ms
[WARN ] Error using formatter #prettier:
    • [STDOUT]:

    • [STDERR]:
    [error] Cannot find module '/nix/store/lfjxr7afcn146kfb4lkm79z0c1jndamp-prettier-plugin-toml-1.0.0/lib/node_modules/prettier-plugin-toml/lib/index.js' imported from /home/samtitle/PersonalRepos/test-std-project/noop.js

[ERROR] #prettier's formatter failed: exit status 1

[blaggacao]

Jep, over time something happened to the toml plugin. Given enough time, software is like quicksand :-)

Should we just drop support for tonl.formatting via prettier? Any good ideas?

[blaggacao]

Copilot, please consider dropping support for the prettier toml plugin. We can consider adding back support for.toml.fo.ratting through other means later.

[DrTeagle]

should we still be using treefmt as we are? As treefmt-nix exists?

[blaggacao]

should we still be using treefmt as we are? As treefmt-nix exists?

Yep, we can probably do that. In Standard, it makes use of nixago to put the configuration files in place on-the-fly. However, I suppose there are also more maintained and evolved solutions for placing generated files into development environments by now?

We have two options, which we probably should approach sequentially:

• Just replace treefmt with treefmt-nix
• Swap nixago for a more modern tooling to take care of the additional file creations that do not fall under the catergory of formatters (e.g. .editorconfig, cog.toml, etc)

QQ:

1. Would you be willing to submit a PR moving us towards leveraging treefmt-nix?
2. Would you have a suggestion for file creation? (currently most promising project in the ecosystem, I haven't been following along too much recently)

[DrTeagle]

1. Yes, but I am in uni, so don't expect it soon.We don't even really need treefmt-nix we can achieve the same result with pkgs.treefmt.withConfig; its just that there sensible defaults in treefmt-nix, and it is easier to generate the config.
2. I dont know of any alternative to nixago. I didnt even know about it until recently

[DrTeagle]

also it seems that way long ago you had this same idea but decided against it, what was the reason for that again? and given the issue in the main repo was closed seemingly so badly that github wont even let me see it, have we decided to reimplement it anyway? also it seems that nixpkgs wants to make treefmt.withConfig better. should we for now just use nixpkgs.treefmt.withConfig as is or track development of the better configuration? once I get treefmt-nix working on my own config (which I am currently swapping away from flake-parts to this + hive) I will figure out how to wrap it and then open a PR.

[blaggacao]

also it seems that way long ago you had this same idea but decided against it, what was the reason for that again?

Honestly, I don't even know. Nor if I actually understand the reference.

and given the issue in the main repo was closed seemingly so badly that github wont even let me see it, have we decided to reimplement it anyway?

Dito.

also it seems that nixpkgs wants to make treefmt.withConfig better. should we for now just use nixpkgs.treefmt.withConfig as is or track development of the better configuration?

That seems like a good upstream development. I wasn't aware of it. Treefmt-nix might be a bit heavy handed, although it has a repository of existing configurations.

once I get treefmt-nix working on my own config (which I am currently swapping away from flake-parts to this + hive) I will figure out how to wrap it and then open a PR.

That'd be awesome! Both treefmt-nix or treefmt.withConfig are fine with me. Si habe no real preference other than we have long term stable support and expect low maintenance chore here downstream.

[DrTeagle]

the referenced Issues are these:

1. First idea: https://github.com/divnix/std/issues/208
2. Issue closed so badly I cant even see the response: https://github.com/numtide/treefmt-nix/issues/15

[DrTeagle]

I am also in a similar boat of trying to get arbitrary flake-parts modules working with this + hive.(I am also having infinite recursion issues with stylix, and can't seem to solve it) perhaps we could work together someway? The only thing that treefmt-nix provides that treefmt.withConfig doesn't is(besides a more user-friendly config) that it allows nix fmt to also use treefmt by default. However, given that in my experience nix fmt is about as fast as a dead snail(I think this is due to it copying whole thing to nix store??), I don't think this is much of an improvement.

As for alternatives to nixago, I cannot find any that allows arbitrary writing of dotfiles, the only ones I can find are more specialized like gen-luarc. and honestly? do we really need to write arbitrary dot files in nix? I get it for json formats(I hate writing json by hand) but things like toml should be fine. Now I do have a personal issue with project-local dotfiles not being in a centralized location (like .config) but it seems that we are stuck with having a bazillion dotfiles for repos.

[DrTeagle]

also my spanish is a little rusty, Si habe means yes They Speak? or was this an autocorrect issue?