Tracing Bun.resolve

[vjpr]

Is there a way to debug how Bun is resolving something?

I am working in a pnpm monorepo.

TypeError: supportsColor.supportsColor is not a function. (In 'supportsColor.supportsColor(stream)', 'supportsColor.supportsColor' is an instance of Object)

  at /root/node_modules/.pnpm/[email protected]/node_modules/supports-hyperlinks/index.js
  ...

It seems that supports-color is resolving to a newer version where the supportsColor export was removed.

I logged the resolved path like so:

const supportsColor = require('supports-color');
console.log(require('supports-color/package.json').version)

const file = Bun.resolveSync('supports-color', import.meta.dir)
console.log(file)

And I get this:

7.2.0
/bun-vfs/node_modules/supports-color/index.js

7.2.0 is the correct package version. But when I try to modify the exports from the path on disk, they are not being changed.

Here is the output:

const supportsColor = require('supports-color');
console.log(supportsColor)
console.log(supportsColor.supportsColor)

{
  __esModule: true,
  default: [Getter],
  stderr: [Getter],
  stdout: [Getter],
  supportsColor: [Getter],
  [Symbol(CommonJSTransformed)]: true
}
{
  stdout: {
    level: 2,
    hasBasic: true,
    has256: true,
    has16m: false
  },
  stderr: {
    level: 2,
    hasBasic: true,
    has256: true,
    has16m: false
  }
}

---

1. Is there a way to show the resolution trace?
2. Can this be written to disk to be inspected in finder/bash?
3. How does the resolution algorithm work?

[vjpr]

This gives me the results I desire:

console.log(require('supports-color/index.js').supportsColor)
console.log(Bun.resolveSync('supports-color/index.js', import.meta.dir))

/xxx/node_modules/.pnpm/[email protected]/node_modules/supports-color/index.js

But this doesn't:

console.log(Bun.resolveSync('supports-color', import.meta.dir))
console.log(require('supports-color').supportsColor)

/bun-vfs/node_modules/supports-color/index.js

Seems like an issue to do with naked imports.

---

I think the bug is related to something going on here:

https://bun.sh/docs/runtime/modules#importing-commonjs-from-commonjs

module, exports, and require are very much like the module, exports, and require in Node.js. These are assigned via a with scope in C++. An internal Map stores the exports object to handle cyclical require calls before the module is fully loaded.

Once the CommonJS module is successfully evaluated, a Synthetic Module Record is created with the default ES Module export set to module.exports and keys of the module.exports object are re-exported as named exports (if the module.exports object is an object).

[vjpr]

Looks like its being detected as a "node-fallback", but its actually not a node built-in.

There is also @vercel/fetch in that list so maybe it is a hack to get it to work.

bun/src/node_fallbacks.zig

Line 31 in 557aac6

const supports_color_code: string = @embedFile("./node-fallbacks/out/supports-color.js");

[vjpr]

See: #2040 (comment)

[egnor]

(I am not a Bun developer) To sort-of answer the original question for anyone else who finds this, the only tracing I've found for import resolution involves making a debug Bun binary.

• clone the bun repo
• follow the directions in CONTRIBUTING.md to build bun-debug
• set environment variables to control debug logging:
  • BUN_DEBUG_QUIET_LOGS=1 (otherwise output will be VERY noisy)
  • BUN_DEBUG_Bundle=1
  • BUN_DEBUG_Transpiler=1
• run your thing using the bun-debug binary you built

Expect it to run slowly and to be moderately chatty. Also expect a lot of memory debugging after the script finishes (and a delay). The debug logging from the bundler is not exactly written for muggles like you or me, but combined with skimming the code may give you an inkling of what's going on.