With the newer nixpkgs Neovim wrapper, plugin Lua dependencies are surfaced through neovimUtils.makeVimPackageInfo as vimPackageInfo.luaDependencies. Nixvim was still only feeding explicit extraLuaPackages into its wrapper Lua environment, so plugin-provided Lua modules stopped reaching the runtime search path after the flake.lock bump.
That showed up as real runtime failures: Telescope could not load plenary.strings and Neorg could not load lua-utils, even though explicit extraLuaPackages still worked.
Fix that by computing vimPackageInfo from config.build.plugins and appending vimPackageInfo.luaDependencies to the wrapper's extraLuaPackages. That keeps Nixvim aligned with the nixpkgs/Home Manager dependency resolution path instead of maintaining a separate recursive Lua dependency collector.
Add focused regression coverage for the two reported plugin cases:
- telescope -> plenary.strings
- neorg -> lua-utils
nixpkgs deprecated neovimUtils.makeNeovimConfig in favor of
wrapNeovimUnstable. Keep Nixvim's current generated init.lua startup
model, but stop routing wrapper construction through the deprecated
helper.
Switch modules/top-level/output.nix to call wrapNeovimUnstable
directly and preserve the existing wrappedNeovim.initRc -> generated
init.lua composition. This aligns Nixvim with the upstream wrapper API
change without changing our current bootstrap behavior yet.
Also update CONTRIBUTING to point contributors at
wrapNeovimUnstable instead of the deprecated helper.
These have all been upstreamed into nvim-lspconfig. Going forward, we
should continue that trend.
If any nix-specific `cmd`s aren't accepted in nvim-lspconfig, they can
be patched in Nixpkgs instead.
Move the `let in` block defining `displayName` and `packageName` up so
it doesn't have to deal with the module arg `name` shadowing `args.name`.
This simplifies the implementation and reduces repetition.
The default for `lsp.servers.<name>.activate` used to be conditional on
whether `name == "*"`. This is leftover from before the * server was
moved to its own `global-server.nix` module and can now be removed.
Similar to the legacy "standalone wrapper" `makeNixvimWithModule`,
thread the configuration's `config` and `options` to the final package.
This allows using such a package as the input to functions like
`testNixvim`.
Instead of copying source files to the target, use a symlink.
This reduces nix store redundancy and enables using entire directories
as sources.
To support this, additional validation is done on file targets to
prevent unexpected conflicts.
Expose the platform wrapper modules as the Nixvim configuration options
`build.nixosModule`, `build.homeModule`, and `build.nixDarwinModule`.
This makes it possible to reuse a single Nixvim configuration across
NixOS, Home Manager, and nix-darwin without re-importing modules into
`programs.nixvim` manually.
Evaluating these wrapper modules requires a "bare" Nixvim configuration;
one that does not define `pkgs` or `nixpkgs.hostPlatform`. Such a
configuration would normally fail to evaluate, but disabling
`_module.check` provides a sufficiently lazy evaluation to access the
wrapper options.
To prevent the `_module.check = false` module from leaking into user
configs, it has a unique module key and gets disabled inside the wrapper
modules (`wrappers/_shared.nix`).
`lib.pipe` strictly evaluates intermediate steps using `foldl'`. As a
result, piping `(opts: opts.package.default or null)` →
`(package: (tryEval package).value)` is ineffective because
`opts.package.default` is evaluated before `tryEval` can catch exceptions.
Instead, inline `opts.package.default` directly into the `tryEval`
expression, ensuring missing package errors caught correctly.
Resolves errors when building NixOS or nix-darwin docs that include
Nixvim options.
Adds a regression test.
Inspired by `home.version` and `home.enableNixpkgsReleaseCheck` in Home
Manager. Print a warning when `lib` or `pkgs` are from a different
release to Nixvim.
Defining `extraFiles.*` as a string was deprecated in 24.05, and has
printed a warning since 2024-07-07.
We can now drop support entirely and simplify the implementation.
Currently, `types.either` has support for the new valueMeta attribute
added by v2 check and merge, while `types.nullOr` does not.
The `lua` option deprecation warning implemented in
`modules/keymaps.nix` requires `valueMeta`, so re-implement `nullOr`
using `types.either` as a workaround.
The deprecation warning for the keymap-submocule `lua` option relied on
`getSubOptions`, however this is fundamentally flawed because that
function returns uses a different module eval from the one that merges
submodule definitions.
Since definitions are not used by `getSubOptions`,
`options.lua.isDefined` will never be true.
Instead, we have two choices:
1. Add a `luaIsDefined` option to the keymap submodule
2. Use the new v2 merge's `valueMeta` to access the actual module eval
Simplify the `enableExceptInTests` attribute, removing the
`_nixvimTests` argument.
We now do a full re-eval of the nixvim configuration before building the
test, giving us a central place to implement `enableExceptInTests` and
its eventual replacement(s).
This extends support for `enableExceptInTests` to all methods of getting
a nixvim test derivation. Previously, it only worked when using `mkTestDerivationFromNixvimModule`.
In `tests/main.nix`, we avoid the re-eval by doing the initial eval with
a "test mode" lib from the start.
Instead of explicitly listing all renames and removals, we can check if
the plugin's lazyload option is visible and in the top-level option set.
This rules out cases where `plugins.foo` is itself a rename/removal
option, and cases where `plugins.foo.lazyload` is not visible.
Adds two internal per-server options: `packages.prefix` & `packages.suffix`.
These options allow the server module to install multiple packages, and
control which end up being prefixed or suffixed on the PATH.
This simplifies the propagating code in `modules/lsp/servers/default.nix`,
which can now zip up the enabled server `packages` attrs.
Adding a module in the following places will import the module into that
specific server's submodule.
This allows creating server-specific options.
Added a test case to ensure all custom modules correspond to an actual
server option to avoid accidental dead code.
