Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Node2nix fails to install with nodejs-15 and nodejs-16 #236

Closed
chaoflow opened this issue May 3, 2021 · 10 comments · Fixed by #302
Closed

Node2nix fails to install with nodejs-15 and nodejs-16 #236

chaoflow opened this issue May 3, 2021 · 10 comments · Fixed by #302

Comments

@chaoflow
Copy link

chaoflow commented May 3, 2021

shell.nix

with import <nixpkgs> {};

let
    nodejs = nodejs-14_x;  # STILL WORKS
    # nodejs = nodejs-15_x;  # FAILS
    # nodejs = nodejs-16_x;  # FAILS
    nodePackages = pkgs.nodePackages.override {
      inherit nodejs;
    };

in

stdenv.mkDerivation rec {
  name = baseNameOf (builtins.getEnv "PWD");
  buildInputs = [
    nodejs
    nodePackages.node2nix
  ];
}

Failure for nodesjs-15 and nodejs-16 is identical.

nix-shell
...
rebuilt dependencies successfully
npm ERR! code ENOTCACHEDlTree buildDeps1ms
npm ERR! request to https://registry.npmjs.org/jsdoc failed: cache mode is 'only-if-cached' but no cached response available.

npm ERR! A complete log of this run can be found in:
npm ERR!     /build/.npm/_logs/2021-05-03T17_01_25_614Z-debug.log

builder for '/nix/store/ymrcv3axb8rfmvi1pk3yf03wbjgk505b-node_node2nix-1.9.0.drv' failed with exit code 1
error: build of '/nix/store/ymrcv3axb8rfmvi1pk3yf03wbjgk505b-node_node2nix-1.9.0.drv' failed
@chaoflow
Copy link
Author

chaoflow commented May 3, 2021

npm install -g with nodejs-16.0.0 and npm-7.10.0 installs successfully. However there are no --nodejs-15 and --nodejs-16 switches yet. See also #232

@svanderburg
Copy link
Owner

node2nix --nodejs version options are simply aliases for command-line options that you can already use.

For example, without an alias you can also specify the Nix package name yourself, e.g.:

node2nix --pkg-name nodejs-16_x

For version newer than Node.js 10.x the standard options suffice, so there's no need to specify any additional options.

e73c616 adds a option for Node.js 16.x

@turboMaCk
Copy link

turboMaCk commented Dec 30, 2021

I'm getting the same errors even when passing old nodejs version. Practically everything in elmPackages that uses node2nix is broken because of this issue in master and unstable in nixpkgs. This is script we use to generate nix expressions https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/compilers/elm/packages/generate-node-packages.sh

Is this the known issue?

Full error
npm ERR! code ENOTCACHED
npm ERR! request to https://registry.npmjs.org/elm-review failed: cache mode is 'only-if-cached' but no cached response is available.

npm ERR! A complete log of this run can be found in:
npm ERR!     /build/.npm/_logs/2021-12-30T16_17_28_553Z-debug.log

error: builder for '/nix/store/sf6nk3pxrh7jb7h6k5dsaj1aakrav81c-elm-test-0.19.1-revision7.drv' failed with exit code 1;
       last 10 log lines:
       > npm WARN old lockfile     at async fetch (/nix/store/8acnc0m7m0m8jxcdhxdvyfqq8hav0a4f-nodejs-16.13.1/lib/node_modules/npm/node_modules/make-fetch-happen/lib/fetch.js:82:7)
       > npm WARN old lockfile     at async Array.<anonymous> (/nix/store/8acnc0m7m0m8jxcdhxdvyfqq8hav0a4f-nodejs-16.13.1/lib/node_modules/npm/node_modules/@npmcli/arborist/lib/arborist/build-ideal-tree.js:741:9) {
       > npm WARN old lockfile   code: 'ENOTCACHED'
       > npm WARN old lockfile }
       > npm ERR! code ENOTCACHED
       > npm ERR! request to https://registry.npmjs.org/elm-review failed: cache mode is 'only-if-cached' but no cached response is available.
       > 
       > npm ERR! A complete log of this run can be found in:
       > npm ERR!     /build/.npm/_logs/2021-12-30T16_17_28_553Z-debug.log
       > 
       For full logs, run 'nix log /nix/store/sf6nk3pxrh7jb7h6k5dsaj1aakrav81c-elm-test-0.19.1-revision7.drv'.

@turboMaCk
Copy link

update: got fix for elmPackages - NixOS/nixpkgs#152764 we were overriding nodejs by what ever we get passed in as nodejs attribute from nixpkgs - that was the reason for build failing.

@toastal
Copy link

toastal commented Dec 31, 2021

However, Node 14.x won't be LTS forever. This will remain an issue, especially as newcomers are looking to use the latest LTS or newer.

@svanderburg
Copy link
Owner

The current release supports newer versions. However, Nixpkgs is still referring to the previous release.

I'm still in the process of updating Nixpkgs, which is quite a bit of work: #274

If you want to help, try repeating the process. So start with a node2nix installed without the script, then update the packages, then try to update all packages that are not in node-packages.json. This is actually the most tedious part.

@andersk
Copy link
Contributor

andersk commented Apr 23, 2022

The current release still doesn’t work with newer Node.js. node2nix reconstructs a package-lock.json file with lockFileVersion: 1; the newer npm tries to convert it to lockFileVersion: 2, and fails for lack of network access in the Nix sandbox. This is the error message originally reported in this issue.

$ echo '["chalk"]' > node-packages.json

$ npx node2nix@1.11.0 --version
node2nix 1.11.0

$ npx node2nix@1.11.0 --nodejs-16 --input node-packages.json
info attempt registry request try #1 at 6:09:03 PM
http request GET https://registry.npmjs.org/chalk
http 200 https://registry.npmjs.org/chalk

$ nix-build -A chalk
this derivation will be built:
  /nix/store/vxhbcl0nbz57yb2h8nasd95cryxglxaq-chalk-5.0.1.drv
building '/nix/store/vxhbcl0nbz57yb2h8nasd95cryxglxaq-chalk-5.0.1.drv'...
unpacking sources
patching sources
configuring
no configure script, doing nothing
building
installing
unpacking source archive /nix/store/dld45vw4jhv1scs7j6mz448ljwf41b1p-chalk-5.0.1.tgz
pinpointing versions of dependencies...
patching script interpreter paths in .
No package-lock.json file found, reconstructing...
rebuilt dependencies successfully
npm WARN old lockfile marborist:ctor Completed in 0ms
npm WARN old lockfile The package-lock.json file was created with an old version of npm,
npm WARN old lockfile so supplemental metadata must be fetched from the registry.
npm WARN old lockfile 
npm WARN old lockfile This is a one-time fix-up, please be patient...
npm WARN old lockfile 
npm ERR! code ENOTCACHED
npm ERR! request to https://registry.npmjs.org/@types%2fnode failed: cache mode is 'only-if-cached' but no cached response is available.

npm ERR! A complete log of this run can be found in:
npm ERR!     /build/.npm/_logs/2022-04-23T01_09_41_970Z-debug-0.log

error: builder for '/nix/store/vxhbcl0nbz57yb2h8nasd95cryxglxaq-chalk-5.0.1.drv' failed with exit code 1;
       last 10 log lines:
       > npm WARN old lockfile so supplemental metadata must be fetched from the registry.
       > npm WARN old lockfile
       > npm WARN old lockfile This is a one-time fix-up, please be patient...
       > npm WARN old lockfile
       > npm ERR! code ENOTCACHED
       > npm ERR! request to https://registry.npmjs.org/@types%2fnode failed: cache mode is 'only-if-cached' but no cached response is available.
       > 
       > npm ERR! A complete log of this run can be found in:
       > npm ERR!     /build/.npm/_logs/2022-04-23T01_09_41_970Z-debug-0.log
       > 
       For full logs, run 'nix log /nix/store/vxhbcl0nbz57yb2h8nasd95cryxglxaq-chalk-5.0.1.drv'.

@dotlambda

This comment was marked as off-topic.

@snawaz
Copy link

snawaz commented Jun 18, 2022

Any update on this?

I'm facing exactly the same issue. With nodejs-14_x, I dont get this error (though I see some other issue) but with nodejs-16_x; I see the same npm WARN old lockfile The package-lock.json file was created with an old version of npm issue.

@snawaz
Copy link

snawaz commented Jun 18, 2022

@chaoflow

Which version/commit of nixpkgs did you use btw?

lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 13, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 13, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 18, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 21, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 21, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 22, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 22, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 22, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 22, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 22, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 22, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 22, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 22, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 27, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 27, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 27, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 27, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 27, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants