`combinePlugins` dropped the `runtimeDeps` of the combined plugins.
The neovim wrapper then lost those PATH entries when
`autowrapRuntimeDeps` was enabled.
Aggregate `runtimeDeps` from the combined plugins and pass them through the
plugin pack. nixpkgs reads the resulting `plugin.runtimeDeps` in
`plugin-submodule.nix`.
Current implementation has a problem: if the user is using a plugin from
a different nixpkgs set, vimGenDocHook isn't filtered out correctly,
because it doesn't match literally. In order to handle this, match
vimGenDocHook by name.
It may be cheaper to evaluate `(version-info.toml).nixpkgs_rev` instead
of `(nixpkgs.nix).rev` in some scenarios.
I've seen some reports of `builtins.fetchTree` _eagerly_ fetching the
FOD even without forcing `outPath`.
Nixpkgs config, for defining things like which licenses are
permitted, can either be an attrset or a function that is passed a
`pkgs` argument. Evaluating that `pkgs` argument requires computing the
Nixpkgs fixpoint, which requires checking whether the derivations used
in the Nixpkgs bootstrap have valid licenses. This works provided
nothing tries to use Nixpkgs functions to validate or merge anything
included in the configuration.
f5deefd4631e (config: add and document {allow,block}listedLicenses,
2025-08-31), in #437723, added type checking and merging to the lists of
permitted/forbidden licenses. That resulted in a recursion loop if a
list of licenses included, say, `pkgs.lib.licenses.bsd0`.
To allow licenses to be specified from Nixpkgs' library, pass `lib` as
well as `pkgs` to any config function. Computing `lib` doesn't require
working out the full Nixpkgs fixpoint. The change in #437723 will still
break things for some people, but it at least provides a sensible route
to getting the config working again.
Fixes https://github.com/NixOS/nixpkgs/issues/456994.
Cherry-picks https://github.com/NixOS/nixpkgs/commit/8e94561d62272983c93f6c635919874f8d19d8f9
Inspired by https://github.com/NixOS/nixpkgs/issues/197325 this adds a
new option `nixpkgs.allowUnfreePackages`, which merges additively and can
thus be defined in multiple modules close to where the unfree package is
installed.
I would have liked to name this option
`nixpkgs.config.allowUnfreePackages`, to define it closer to where the
`allowUnfree` and `allowUnfreePredicate` are defined, but I didn't see how
this could be achieved. I would welcome some guidance on how to do this.
Cherry-picks https://github.com/NixOS/nixpkgs/commit/a3c9221d642da4c0b22b9c9576bd2af8dcbb8263
Wrapped Nixvim configs previously passed the generated init.lua with -u. Neovim treats that startup path as an explicit user config and skips exrc processing, so project-local .nvim.lua files were not sourced even when users enabled the exrc option.
Load the generated config through a forced VIMINIT instead. This preserves the current wrapped-config precedence while allowing Neovim's normal exrc startup path to run for trusted project config files.
When impureRtp is disabled, clear XDG_CONFIG_DIRS and VIM from an early --cmd before sysinit is checked, then restore them before loading the generated config so runtime code and child processes see the original environment.
Keep the saved startup environment in a short-lived global Lua table shared between the --cmd and VIMINIT chunks, then clear it after restore.
Add a modules-output regression test that checks the wrapper args no longer include -u, verifies VIMINIT is set, confirms trusted .nvim.lua is sourced, blocks sysinit.vim, verifies XDG_CONFIG_DIRS and VIM are restored, and ensures the saved startup state is cleared.
Closes#3506
Currently, `nixpkgs.source` can be affected by flake input following.
Nixvim is sensitive to the pinned Nixpkgs revision and users often
follow inputs without thinking too much about it, so warn when this is
detected.
The build.extraFiles wrapper plugin is built via
`pkgs.runCommandLocal "nvim-config"`, which sets only the derivation
`name`, not `pname`. Recent nixpkgs (as of 2026-04) extended
`pkgs.vim-pack-dir` to map `plugin.pname` over the start/opt plugin
list when checking for an nvim-treesitter / nvim-treesitter-legacy
conflict, so building any standalone nixvim package against current
nixpkgs unstable fails with `attribute 'pname' missing`.
Setting `pname = "nvim-config"` on this derivation explicitly
restores the pre-2026-04 behavior without touching nixpkgs.
Repro:
nix build --impure --expr '
let
nixpkgs = builtins.getFlake "github:NixOS/nixpkgs/nixos-unstable";
nixvim = builtins.getFlake "github:nix-community/nixvim";
system = "x86_64-linux";
in
(nixvim.legacyPackages.${system}.makeNixvim { })
'
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.
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.
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.
Allow users to add packages to the end of `PATH` in the neovim wrapper.
This is useful for LSP versions that might need to be overriden based on
the environment, e.g. `haskell-language-server` versions provided by a
project's devshell.
Previously, specifying plugins as packages in the
`performance.combinePlugins.standalonePlugins` option did not work when
the `performance.byteCompileLua` option was also enabled. This issue was
due to several package transformations performed by the
`byteCompileLua` which broke package comparison.
There are at least three methods to fix the issue:
- Change transformation order: combine plugins first, then byte-compile
them.
- Compare every possible transformation when determining if plugins are
standalone.
- Get the name of the package and use it for comparison.
The first method did not work because the current `byteCompileLuaDrv`
implementation does not support symlinks to directories. The second
method appears too fragile. This commit implements the third method, as
it requires minimal code changes and is straightforward. The downside is
that it might exclude multiple packages with the same name, although
this should be rare.
Previously only extraLuaPackages themselves were byte-compiled, not
theirs dependencies. This commit fixes that by compiling lua packages
recursively. It uses byte-compile-lua-lib.nix shared file.
Also this commit uses the shared stub lua libraries for extraLuaPackages
byte-compiling test.
This commit replaces custom lua plugins in tests with shared stub
plugins from utils module.
After this change the test has started to fail. Debugging this issue
I found out that dependencies of plugins weren't processed.
This commit improves the test assertion to detect duplicated
dependencies in this case and fixes the underlying issue by also
processing dependencies.
Plugins from luarocks (e.g. telescope-nvim) have dependencies specified
in propagatedBuildInputs. These dependencies are not added as plugins in
Nvim runtime. They are added to LUA_PATH env var for wrapped neovim.
This commit collects all propagatedBuildInputs from input plugin list
and puts them in the combined plugin.
Note that such dependencies are never combined, because they are not
plugins.
Austin Horstman
Stanislav AsunkinandAustin Horstman
Matt Sturgeon
Adam DinwoodieandMatt Sturgeon
rekcäH nitraMandMatt Sturgeon
Wolfgang WaltherandMatt Sturgeon
Juha KestiandAustin Horstman
Oliver BreitwieserandGaétan Lepage
saygo-pngandMatt Sturgeon
Heitor AugustoandGaétan Lepage
Axel KarjalainenandMatt Sturgeon
Sandro JäckelandMatt Sturgeon
Gutyina GergőandMatt Sturgeon
sportsheadandMatt Sturgeon
