e511022c74
Code run within Deno-mode and Node-mode should have access to a slightly different set of globals. Previously this was done through a compile time code-transform for Node-mode, but this is not ideal and has many edge cases, for example Node's globalThis having a different identity than Deno's globalThis. This commit makes the `globalThis` of the entire runtime a semi-proxy. This proxy returns a different set of globals depending on the caller's mode. This is not a full proxy, because it is shadowed by "real" properties on globalThis. This is done to avoid the overhead of a full proxy for all globalThis operations. The globals between Deno-mode and Node-mode are now properly segregated. This means that code running in Deno-mode will not have access to Node's globals, and vice versa. Deleting a managed global in Deno-mode will NOT delete the corresponding global in Node-mode, and vice versa. --------- Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com> Co-authored-by: Aapo Alasuutari <aapo.alasuutari@gmail.com> |
||
---|---|---|
.. | ||
_fs | ||
_process | ||
_util | ||
assert | ||
dns | ||
fs | ||
internal | ||
internal_binding | ||
path | ||
readline | ||
stream | ||
timers | ||
util | ||
00_globals.js | ||
01_require.js | ||
02_init.js | ||
_brotli.js | ||
_events.d.ts | ||
_events.mjs | ||
_global.d.ts | ||
_http_agent.mjs | ||
_http_common.ts | ||
_http_outgoing.ts | ||
_next_tick.ts | ||
_readline.d.ts | ||
_readline.mjs | ||
_readline_shared_types.d.ts | ||
_stream.d.ts | ||
_stream.mjs | ||
_tls_common.ts | ||
_tls_wrap.ts | ||
_utils.ts | ||
_zlib.mjs | ||
_zlib_binding.mjs | ||
assert.ts | ||
assertion_error.ts | ||
async_hooks.ts | ||
buffer.ts | ||
child_process.ts | ||
cluster.ts | ||
console.ts | ||
constants.ts | ||
crypto.ts | ||
dgram.ts | ||
diagnostics_channel.ts | ||
dns.ts | ||
domain.ts | ||
events.ts | ||
fs.ts | ||
http.ts | ||
http2.ts | ||
https.ts | ||
inspector.ts | ||
net.ts | ||
os.ts | ||
path.ts | ||
perf_hooks.ts | ||
process.ts | ||
punycode.ts | ||
querystring.ts | ||
readline.ts | ||
README.md | ||
repl.ts | ||
stream.ts | ||
string_decoder.ts | ||
sys.ts | ||
timers.ts | ||
tls.ts | ||
tty.ts | ||
url.ts | ||
util.ts | ||
v8.ts | ||
vm.ts | ||
wasi.ts | ||
worker_threads.ts | ||
zlib.ts |
Deno Node.js compatibility
This module is meant to have a compatibility layer for the Node.js standard library.
Warning: Any function of this module should not be referred anywhere in the Deno standard library as it's a compatibility module.
Supported modules
- assert
- assert/strict partly
- async_hooks partly
- buffer
- child_process partly
- cluster partly
- console partly
- constants partly
- crypto partly
- dgram partly
- diagnostics_channel partly
- dns partly
- events
- fs partly
- fs/promises partly
- http partly
- http2
- https partly
- inspector partly
- module
- net
- os partly
- path
- path/posix
- path/win32
- perf_hooks
- process partly
- punycode
- querystring
- readline
- repl partly
- stream
- stream/promises
- stream/web partly
- string_decoder
- sys
- timers
- timers/promises
- tls
- trace_events
- tty partly
- url
- util partly
- util/types partly
- v8
- vm partly
- wasi
- webcrypto
- worker_threads
- zlib
- node globals partly
Deprecated
These modules are deprecated in Node.js and will probably not be polyfilled:
- domain
- freelist
Experimental
These modules are experimental in Node.js and will not be polyfilled until they are stable:
- diagnostics_channel
- async_hooks
- policies
- trace_events
- wasi
- webcrypto
CommonJS modules loading
createRequire(...)
is provided to create a require
function for loading CJS
modules. It also sets supported globals.
import { createRequire } from "https://deno.land/std@$STD_VERSION/node/module.ts";
const require = createRequire(import.meta.url);
// Loads native module polyfill.
const path = require("path");
// Loads extensionless module.
const cjsModule = require("./my_mod");
// Visits node_modules.
const leftPad = require("left-pad");
Contributing
Setting up the test runner and running tests
See tools/node_compat/README.md.
Best practices
When converting from promise-based to callback-based APIs, the most obvious way is like this:
promise.then((value) => callback(null, value)).catch(callback);
This has a subtle bug - if the callback throws an error, the catch statement will also catch that error, and the callback will be called twice. The correct way to do it is like this:
promise.then((value) => callback(null, value), callback);
The second parameter of then
can also be used to catch errors, but only errors
from the existing promise, not the new one created by the callback.
If the Deno equivalent is actually synchronous, there's a similar problem with try/catch statements:
try {
const value = process();
callback(null, value);
} catch (err) {
callback(err);
}
Since the callback is called within the try
block, any errors from it will be
caught and call the callback again.
The correct way to do it is like this:
let err, value;
try {
value = process();
} catch (e) {
err = e;
}
if (err) {
callback(err); // Make sure arguments.length === 1
} else {
callback(null, value);
}
It's not as clean, but prevents the callback being called twice.
Remaining Tests
Node compatibility can be measured by how many native Node tests pass. If you'd like to know what you can work on, check out the list of Node tests remaining here.