User-defined Idioms

[kylechui]

Is your feature request related to a problem? Please describe.

Right now, it seems like there is no static analysis inside callback functions being used for overriding certain packages/attributes in a derivation or derivation set. For example, if we want to override some of the pkgs.vimPlugins, then it seems like the fixed-point function we pass to pkgs.vimPlugins.extend does not get statically analyzed to recognize the oldAttrs and finalAttrs as "the same shape" as pkgs.vimPlugins.

Describe the solution you'd like

Would it be possible for the language server to do a bit more inference for these fixpoint functions?

Maybe a different way to get around things: I did some snooping in the codebase, and my understanding is that pkgs and lib are hard-coded constants, where variables with those names are assumed to follow the format of the nixpkgs field in settings.nixd.nixpkgs.expr. Could it be possible to have more user-defined mappings, so I could define e.g. oldVimAttrs to point to (import <nixpkgs> { }).vimPlugins or something like that?

Describe alternatives you've considered

I tried looking around the existing issues but did not find anything that seemed super-related to this ask.

Additional context

Thanks a bunch for your work on this project! I also understand that since Nix is dynamically-typed, a lot of these static analyses may not be possible---feel free to close this issue if that ends up being the case.

[inclyc]

Thank you for your in-depth research and positive feedback!

Right now, it seems like there is no static analysis inside callback functions being used for overriding certain packages/attributes in a derivation or derivation set.

Providing more precise static analysis is indeed a classic pain point.

In the early design of nixd, we experimented with directly hooking into the C++ Nix evaluator for general-purpose static inference. In practice, however, this generic approach performed poorly in the context of real‑time LSP editing (severe lag), so we put that path aside for now. Essentially, to achieve the kind of precise type inference you are looking for, we would need a "TypeScript for Nix"—that is, full type inference over Nix's dynamic fixed‑points. This is a highly challenging topic both academically and engineering‑wise, and the current maintenance resources and community organization of nixd are not yet able to support a project of that scale.

Regarding your suggestion about "allowing user‑defined mappings (e.g., pointing oldVimAttrs to vimPlugins)", I hold a "not recommended" stance. The reason is that if we expose such mapping interfaces through configuration files, comments, or special syntax, we would essentially be "inventing a new type description language". This would greatly increase the maintenance complexity of the project and make nixd's static analysis opaque and difficult to debug.

That said, I don't think we should hit a dead end and simply give up. In the short term, I would suggest exploring whether we can systematically extend our heuristic module—perhaps using coding agents or similar AI‑powered tools—to recognise some very common, community‑accepted cases, and then evaluate whether such additions are "worth it"—i.e., whether they can satisfy the majority of users without introducing excessive complexity.

If that path turns out not to be feasible, I have recently noticed work in the NixOS community such as typenix. Perhaps you could take a look to see if typenix can address your problem, or even consider incorporating some of its design ideas into nixd. I am open to that direction.

[kylechui]

Thanks for the quick response, and pointers! I agree that the "extra idioms" I was originally asking for are merely a band-aid solution to a broader problem---the forked tsgo compiler sounds very interesting! I have my reservations that it will become "official" anytime soon, but perhaps the gradual typing lessons the community has learned from TypeScript will translate well to any future tooling on the Nix side. It's also not abundantly clear to me if Nix/TypeScript even have the same semantics (my guess is no, e.g. laziness), but maybe TypeNix is good enough for my purposes. I'll give it a try and see how it goes!