What are you trying to achieve?
Bun is a supported runtime for CodeceptJS 4 — the 4.0 release post says under Native ESM: "Your project needs "type": "module" and NodeJS 20 or Bun."
When running under Bun (bunx --bun codeceptjs run / info), I expect the environment report to tell me which runtime actually executed the process, and at which version — that is the whole point of the block, since codeceptjs info explicitly asks you to paste it into GitHub issues.
What do you get instead?
There is no bunInfo. The report only ever has nodeInfo, and under Bun it is wrong in one of two ways.
1. Not Found — on a perfectly working install.
Environment information:
codeceptVersion: "4.1.0"
nodeInfo: Not Found
osInfo: Linux 7.0 Ubuntu 24.04.4 LTS 24.04.4 LTS (Noble Numbat)
cpuInfo: (16) x64 AMD Ryzen 7 9700X 8-Core Processor
osBrowsers: "chrome: 151.0.7922.169, edge: /, firefox: 153.0.4, safari: N/A"
playwrightBrowsers: "chromium: 151.0.7922.34, firefox: 153.0, webkit: 26.5"
Same in the machine-info block printed by run / run-workers on failure:
nodeInfo: Not Found
osInfo: Linux 6.8 Ubuntu 24.04.4 LTS 24.04.4 LTS (Noble Numbat)
cpuInfo: (16) x64 AMD Ryzen 9 7940HS w/ Radeon 780M Graphics
2. A real but irrelevant version — which is worse, because it looks correct.
If a Node install happens to be on PATH, the report shows that Node's version even though Node executed nothing. On my machine, running under Bun 1.4.2:
runtime bun: 1.4.2
getNodeInfo: ["Node","24.18.0","/home/mirao/.nvm/versions/node/v24.18.0/bin/node"]
So an issue reported from a Bun project reads as "Node 24.18.0" and the Bun version — the thing that actually matters — is nowhere.
Cause
lib/command/info.js hardcodes envinfo.helpers.getNodeInfo() in both places, and envinfo answers by probing PATH, not by looking at the running process:
https://github.com/codeceptjs/CodeceptJS/blob/4.x/lib/command/info.js#L56
https://github.com/codeceptjs/CodeceptJS/blob/4.x/lib/command/info.js#L84
Not Found then has two independent triggers:
- No Node at all. Our CI image is Bun-only; there is no
node binary to probe.
$ env PATH=~/.bun/bin:/usr/bin:/bin bun --bun -e \
'console.log(await require("envinfo").helpers.getNodeInfo())'
[ "Node", "Not Found" ]
bunx --bun shadows node with its own shim. Bun prepends a temp dir containing a node that re-execs Bun, and that shim rejects --version:
PATH head: /tmp/bunx-1000-bun@latest/node_modules/.bin | /tmp/bun-node-744846f84 | ...
which node: /tmp/bun-node-744846f84/node
node --version: error: Missing script to execute. Pass --interactive to start the Node.js-compatible REPL.
getNodeInfo: ["Node","Not Found"]
getbunInfo: ["bun","1.4.2","/tmp/bun-node-744846f84/bun"]
Note the last line: envinfo already ships a Bun helper (getbunInfo, lowercase b), it is simply never called.
Minimal reproduction
package.json { "name": "bun-info-repro", "type": "module", "private": true }
codecept.conf.js (below)
// codecept.conf.js
export const config = {
tests: './*_test.js',
helpers: {},
name: 'bun-info-repro',
}
bun add --dev codeceptjs@4.1.0
bunx --bun codeceptjs info
→ nodeInfo: Not Found, no bunInfo.
Suggested fix
Report the runtime that is actually executing CodeceptJS. process.versions is authoritative and needs no subprocess; the PATH probe is only correct on Node.
--- a/lib/command/info.js
+++ b/lib/command/info.js
@@
+async function getRuntimeInfo() {
+ // Report the runtime actually executing CodeceptJS. `process.versions` is authoritative;
+ // envinfo's PATH probe is not: under `bunx --bun` the `node` first on PATH is a Bun shim
+ // that has no --version, so getNodeInfo() reports "Not Found" on a working install.
+ if (process.versions.bun) return { bunInfo: ['bun', process.versions.bun, process.execPath] }
+ return { nodeInfo: await envinfo.helpers.getNodeInfo() }
+}
+
export default async function (path) {
@@
info.codeceptVersion = Codecept.version()
- info.nodeInfo = await envinfo.helpers.getNodeInfo()
+ Object.assign(info, await getRuntimeInfo())
info.osInfo = await envinfo.helpers.getOSInfo()
@@
export const getMachineInfo = async () => {
const info = {
- nodeInfo: await envinfo.helpers.getNodeInfo(),
+ ...(await getRuntimeInfo()),
osInfo: await envinfo.helpers.getOSInfo(),
The 3-element array keeps the shape getNodeInfo() returns, so the existing Array.isArray(value) printer prints value[1] — the version — unchanged.
Applied against 4.1.0 and verified locally on Bun 1.4.2 / Node 24.18.0:
$ bunx --bun codeceptjs info
codeceptVersion: "4.1.0"
bunInfo: 1.4.2
osInfo: Linux 7.0 Ubuntu 24.04.4 LTS 24.04.4 LTS (Noble Numbat)
$ bun --bun -e 'const {getMachineInfo} = await import("codeceptjs/lib/command/info.js"); console.log(Object.keys(await getMachineInfo()))'
bunInfo: 1.4.2
[ "bunInfo", "osInfo", "cpuInfo", ... ]
$ node --input-type=module -e 'import {getMachineInfo} from "codeceptjs/lib/command/info.js"; console.log(Object.keys(await getMachineInfo()))'
nodeInfo: 24.18.0
[ "nodeInfo", "osInfo", "cpuInfo", ... ]
i.e. the Node output is byte-identical to today's, and Bun gains a correct bunInfo.
Two variations, if you prefer them:
- Emit
bunInfo in addition to nodeInfo rather than instead of it. I'd argue against it — the Node line is meaningless noise on a Bun run, and Not Found reads as a broken install to anyone triaging the issue.
- Use
envinfo.helpers.getbunInfo() instead of process.versions.bun. Also works, but it reports whichever bun is on PATH, which is not necessarily the one running the process — the same class of bug as the current code.
Happy to open a PR if the approach looks right.
Details
- CodeceptJS version: 4.1.0 (
4.x branch HEAD is identical at these lines)
- Bun: 1.4.2
- Node (present but unused): 24.18.0
- OS: Ubuntu 24.04.4 LTS
Created by AI agent (Claude Code)
What are you trying to achieve?
Bun is a supported runtime for CodeceptJS 4 — the 4.0 release post says under Native ESM: "Your project needs
"type": "module"and NodeJS 20 or Bun."When running under Bun (
bunx --bun codeceptjs run/info), I expect the environment report to tell me which runtime actually executed the process, and at which version — that is the whole point of the block, sincecodeceptjs infoexplicitly asks you to paste it into GitHub issues.What do you get instead?
There is no
bunInfo. The report only ever hasnodeInfo, and under Bun it is wrong in one of two ways.1.
Not Found— on a perfectly working install.Same in the machine-info block printed by
run/run-workerson failure:2. A real but irrelevant version — which is worse, because it looks correct.
If a Node install happens to be on
PATH, the report shows that Node's version even though Node executed nothing. On my machine, running under Bun 1.4.2:So an issue reported from a Bun project reads as "Node 24.18.0" and the Bun version — the thing that actually matters — is nowhere.
Cause
lib/command/info.jshardcodesenvinfo.helpers.getNodeInfo()in both places, andenvinfoanswers by probingPATH, not by looking at the running process:https://github.com/codeceptjs/CodeceptJS/blob/4.x/lib/command/info.js#L56
https://github.com/codeceptjs/CodeceptJS/blob/4.x/lib/command/info.js#L84
Not Foundthen has two independent triggers:nodebinary to probe.bunx --bunshadowsnodewith its own shim. Bun prepends a temp dir containing anodethat re-execs Bun, and that shim rejects--version:Note the last line:
envinfoalready ships a Bun helper (getbunInfo, lowercaseb), it is simply never called.Minimal reproduction
→
nodeInfo: Not Found, nobunInfo.Suggested fix
Report the runtime that is actually executing CodeceptJS.
process.versionsis authoritative and needs no subprocess; thePATHprobe is only correct on Node.The 3-element array keeps the shape
getNodeInfo()returns, so the existingArray.isArray(value)printer printsvalue[1]— the version — unchanged.Applied against 4.1.0 and verified locally on Bun 1.4.2 / Node 24.18.0:
i.e. the Node output is byte-identical to today's, and Bun gains a correct
bunInfo.Two variations, if you prefer them:
bunInfoin addition tonodeInforather than instead of it. I'd argue against it — the Node line is meaningless noise on a Bun run, andNot Foundreads as a broken install to anyone triaging the issue.envinfo.helpers.getbunInfo()instead ofprocess.versions.bun. Also works, but it reports whicheverbunis onPATH, which is not necessarily the one running the process — the same class of bug as the current code.Happy to open a PR if the approach looks right.
Details
4.xbranch HEAD is identical at these lines)Created by AI agent (Claude Code)