Seems like a well-maintained nvim-treesitter alternative with regular commits:
LLM disclosure: some code, especially around lockfile generation, was originally drafted by GPT-5.5 via ChatGPT web. I did review and edit a lot of its code however.
Do you know how does this compares with whatever is in NixVim?
1 Like
What makes this limited to experimental flakes only?
As far as I can see NixVim still just uses the archived nvim-treesitter.
Mostly just that I’m used to writing every file as a flake-parts module so I can refactor easier, and because I like the module system in general, and think a top-level one is very useful. However, this is probably stable enough to refactor into a default.nix without losing too much personal DX (because I won’t have to develop it, hopefully) once I get this TODO out of the way. I recognize that flakes aren’t perfect, and I’m not against npins/Nixtamal users using my software, I just prefer the DX with Flakes/flake-parts.
So, I guess you’re not a NixVim user?
1 Like
Nope, neovim - nix-wrapper-modules all the way (former NixCats user, love writing Lua configs in Lua and not Nix)! I am interested if NixVim does something else I’m not seeing though, please send a link!
UPDATE: I now have a default.nix powered by my new (admittedly AI-generated, but has undergone some basic (relatively comprehensive for the amount of time I spent) testing and it seems to work well) flake-ultra-polyfill project (like flake-compat, but supports some methods of overriding inputs as a consumer and uses upstream call-flake.nix).
See the new section in the README.
Adding flake-ultra-polyfill to firefox-extensions-declarative next.
I was thinking hard about why you would be adding an nvim tree-sitter package to Firefox extensions 
Looks like an interesting project. I really like flake-parts, but would prefer not having to use flakes at all. Might have a look at this.
1 Like
Oops, clarified that 
. You may also want to take a look at goldstein/unflake: an alternative dependency resolver & runtime for Nix flakes - Codeberg.org, which has its own dependency resolver (not flake.lock-based AFAIK) and might be more like what you want if you aren’t writing flakes to be consumed externally.
flake-ultra-polyfill is more like what you want if you are writing a flake that will primarily be used as a flake, but want to support non-flake users as well.
BTW, with flake-ultra-polyfill you still need to at least run nix flake lock and nix flake update.
1 Like
No offense but I think you are designing in the wrong direction to do “AI-generated polyfill”. These flake “polyfill” options are adding extra unnecessary dependencies to the toolchain for users. flake.nix can import files/overlays or use callPackage with stable Nix code without workarounds—& this, in my experience, tends to lead to better design & modularity when designing for stable Nix first, with flakes just being a convenience. Developers tend to want to code their way out of corners from design choices they made instead of stepping back, doing a bit of rearchitecting & choosing the simpler option that doesn’t require extra code (see my arguments for removing useless .envrc from Nixpkgs as folks are trying to suggest coding all of these workarounds (some with security issues), versus the simpler setup: delete the .envrc if it is just use nix). It might be a one-liner, but how much complexity is going to be added behind that one line? These tools should be a last resort—not the first option.
2 Likes
I was planning on doing this but wondering where to put the files, found this on @mightyiam’s dendritic README:
Built (with an LLM) a thing so it gets auto-wired with flake-parts and gracefully degrades to manual callPackage. Also adopted at firefox-extensions-declarative.