Looking for Node when I am using Bun

[robisadev]

• I have searched for similar issues
• I am using the latest version of npm-check-updates
• I am using node >= 14.14
• I am using bun 1.0

---

Steps to Reproduce

1. Attempt to run ncu or bun npm-check-updates

Current Behavior

Returns
/usr/bin/env: 'node': No such file or directory

Expected Behavior

npm-check-updates to run correctly using bun

[raineorshine]

Hi, thanks for reporting. There must must still be some node usage baked in. I will look into this.

[raineorshine]

@robisadev Do you have a stack trace? I removed node from my PATH to try to reproduce, but I'm not getting the same error.

I just implemented defaultPrefix in v16.14.1 to keep npm-check-updates from calling npm, but I doubt that will fix the issue.

[robisadev]

@robisadev Do you have a stack trace? I removed node from my PATH to try to reproduce, but I'm not getting the same error.

No, I don't have a stack trace at the moment. I could get one later. Should I? I should have noted that I am using WSL Debian without a node package.

[raineorshine]

I'm not sure which part of the codebase is calling node, so a stack trace would help to see where this error is coming from. I searched the codebase and could not find anything. ncu -p bun works on my machine even when I remove node from my PATH.

bun support is fairly experimental still. I'll add that to the release notes. I'll need steps to reproduce on other machines to be able to troubleshoot the issue further, or for someone like yourself who is able to reproduce to work on a PR.

[robisadev]

Ok, I will send later.

[robisadev]

Sorry this took so long IRL issues. I really have no idea how to get a stack trace. Help!

[raineorshine]

Often when npm-check-updates throws an error, it will output the stack trace along with the actual error message. If you're not seeing a stack trace in your terminal when you get this error then unfortunately there is no easy way to turn it on. It could be something in my code that is catching the error and logging the error message but neglecting to log the stack trace.

If the error were occurring on my machine, I would clone, build, and run npm-check-updates from source and add some console.logs to see where the error is coming from.

Please try the following and let me know the output:

bunx npm-check-updates --packageManager bun --verbose

[robisadev]

216 | Object.assign(this.options.headers, source.headers);
217 | }
218 | });
219 | this.on('newListener', event => {
220 | if (event === 'retry' && this.listenerCount('retry') > 0) {
221 | throw new Error('A retry listener has been attached already.');
^
error: A retry listener has been attached already.
at /tmp/npm-check-updates@latest--bunx/node_modules/got/dist/source/core/index.js:221:22
at makeRequest (/tmp/npm-check-updates@latest--bunx/node_modules/got/dist/source/as-promise/index.js:107:12)
at /tmp/npm-check-updates@latest--bunx/node_modules/got/dist/source/as-promise/index.js:125:8
at /tmp/npm-check-updates@latest--bunx/node_modules/p-cancelable/index.js:63:3
at new Promise (:1:20)
at new PCancelable (/tmp/npm-check-updates@latest--bunx/node_modules/p-cancelable/index.js:31:18)
at asPromise (/tmp/npm-check-updates@latest--bunx/node_modules/got/dist/source/as-promise/index.js:21:20)
at lastHandler (/tmp/npm-check-updates@latest--bunx/node_modules/got/dist/source/create.js:42:26)
at iterateHandlers (/tmp/npm-check-updates@latest--bunx/node_modules/got/dist/source/create.js:49:18)
44 | enumerable: true,
45 | configurable: true,
46 | writable: true,
47 | value: void 0
48 | });
49 | Error.captureStackTrace(this, this.constructor);
^
RequestError: Was there a typo in the url or port?
code: "FailedToOpenSocket"

  at new RequestError (/tmp/npm-check-updates@latest--bunx/node_modules/got/dist/source/core/errors.js:49:8)
  at /tmp/npm-check-updates@latest--bunx/node_modules/got/dist/source/core/index.js:790:106
  at node:http:868:30
  at processTicksAndRejections (:55:76)

610 | }
611 | get stdio() {
612 | return this.#stdioObject ??= this.#createStdioObject();
613 | }
614 |
615 | spawn(options) {
^
error: "pidfd_open(2)" system call is not supported by your Linux kernel
To fix this error, either:

• Upgrade your Linux kernel to a newer version (current: 4.4.0-wn frame descri)
• Ensure the seccomp filter allows "pidfd_open"
  at spawn (node:child_process:615:14)
  at node:child_process:2:40
  at check (/tmp/npm-check-updates@latest--bunx/node_modules/update-notifier/update-notifier.js:111:2)
  at updateNotifier (/tmp/npm-check-updates@latest--bunx/node_modules/update-notifier/index.js:5:1)
  at /tmp/npm-check-updates@latest--bunx/node_modules/npm-check-updates/build/src/bin/cli.js:57:21
  at processTicksAndRejections (:55:76)
  error: "npm-check-updates" exited with code 1 (SIGHUP)

[raineorshine]

Awesome, thanks.

It looks like there are two different errors occurring. The first is related to the got package which does not yet work with bun. The issue is being tracked here: oven-sh/bun#3150. I have run into this error before, and it is not always fatal.

The second error, "pidfd_open(2)" system call is not supported by your Linux kernel is probably the bigger problem. This is definitely a bug in bun. Assuming your OS is officially supported by bun, you can search for similar issues on their repo, and open a new issue if you don't find anything. Unfortunately bun is not quite drop-in ready, and there are a lot of low-level bugs still to be solved before it is stable.