`importNpmLock.buildNodeModules` returns a derivation with a pre-built `node_modules` directory, as imported by `importNpmLock`.
This is to be used together with `importNpmLock.hooks.linkNodeModulesHook` to facilitate `nix-shell`/`nix develop` based development workflows:
```nix
pkgs.mkShell {
packages = [
importNpmLock.hooks.linkNodeModulesHook
nodejs
];
npmDeps = importNpmLock.buildNodeModules {
npmRoot = ./.;
inherit nodejs;
};
}
```
will create a development shell where a `node_modules` directory is created & packages symlinked to the Nix store when activated.
This code is adapted from https://github.com/adisbladis/buildNodeModules
This patch moves the code snippet which is shown as equivalent to the
example into the actual example block.
Visually, it was not easy to parse that the "equivalent" code piece
belonged to the code snippet that was hidden in the example (which is
collapsed by default).
By moving it into the example block, the "equivalent" piece is hidden by
default as well.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
* vimPlugins: introduce passthru.initLua for some plugins
as described in https://github.com/NixOS/nixpkgs/issues/172538, some vim
plugins need some configuration to be able to work at all.
We choose not to patch those plugins and instead expose the necessary
configuration to make them work in `PLUGIN.passthru.initLua`.
For now the user can check if plugins have a `PLUGIN.passthru.initLua`
and if yes, prepend it to their own init.lua.
Maybe later we can revisit this to either patch them in a way that is
clear that it's a nixpkgs patch or by having the neovim wrapper pick
those snippets and autoadd them to init.lua ?
* Update doc/languages-frameworks/vim.section.md
Co-authored-by: Marc Jakobi <mrcjkb89@outlook.com>
---------
Co-authored-by: Marc Jakobi <mrcjkb89@outlook.com>
We haven't been good at managing expectations about this, so let's
tell people what level of support they can expect. I think the place
people are most likely to see it is the place where they learn about
overriding in the first place, so I've added it here.
Co-authored-by: Valentin Gagarin <valentin@gagarin.work>
Fix overriding of vendorHash and various attributes via the fixed point
attribute support of stdenv.mkDerivation.
Pass as derivation attributes
goModules, modRoot, vendorHash, deleteVendor, and proxyVendor.
Move goModules and vendorHash out of passthru.
Co-authored-by: Doron Behar <doron.behar@gmail.com>
`lib.trivial.revisionWithDefault` will change with every Git commit, which causes the manual to be rebuilt on every since PR.
Using `nixpkgs.rev` (or the dummy value "master" if it's not present) means that the manual will contain the revision if built on Hydra, but will not otherwise.
Why?
1. https://hydra.nixos.org/jobset/nixos/trunk-combined#tabs-configuration shows that `pkgs/top-level/release.nix` is passed the `nixpkgs` attrset, which is a "Git checkout".
2. Git checkouts come from [`builtins.fetchGit`](https://nix.dev/manual/nix/2.18/language/builtins#builtins-fetchGit) and include the `rev` attribute.
3. The `rev` attribute is what `lib.trivial.revisionWithDefault` would have returned.
So, using `nixpkgs.rev or "master"` exclusively will cause the rebuilds on every commit to cease, but will allow "official" nixpkgs manual built on Hydra to continue to reference a specific commit.
