For an already-evaluated module, return the dependencies as module specifiers
This list is already sorted and uniqued.
For this code:
// /foo.js
import classNames from 'classnames';
import React from 'react';
import {createElement} from 'react';
This would return:
Loader.dependencyKeysIfEvaluated("/foo.js")
["bun:wrap", "/path/to/node_modules/classnames/index.js", "/path/to/node_modules/react/index.js"]
module specifier as it appears in transpiled source code
ESM module registry
This lets you implement live reload in Bun. If you delete a module specifier from this map, the next time it's imported, it will be re-transpiled and loaded again.
The keys are the module specifiers and the values are metadata about the module.
The keys are an implementation detail for Bun that will change between versions.
bun:
prefix or node:
prefix"/bun-vfs/"
. "buffer"
is an example of a JS polyfillnode_modules.bun
file, many modules will point to that fileVirtual modules and JS polyfills are embedded in bun's binary. They don't point to anywhere in your local filesystem.
The function JavaScriptCore internally calls when you use an import statement.
This may return a path to node_modules.server.bun
, which will be confusing.
Consider Bun.resolve or ImportMeta.resolve instead.
module specifier as it appears in transpiled source code
Synchronously resolve a module specifier
This may return a path to node_modules.server.bun
, which will be confusing.
Consider Bun.resolveSync instead.
Generated using TypeDoc
Low-level JavaScriptCore API for accessing the native ES Module loader (not a Bun API)
Before using this, be aware of a few things:
Using this incorrectly will crash your application.
This API may change any time JavaScriptCore is updated.
Bun may rewrite ESM import specifiers to point to bundled code. This will be confusing when using this API, as it will return a string like "/node_modules.server.bun".
Bun may inject additional imports into your code. This usually has a
bun:
prefix.