This removes the additional arguments on the function returned by
`Module.wrap`.
Allow libraries that overwrite this behavior (like `v8-code-cache`) to
work correctly.
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
This commit changes how "performance" global is handled -
instead of having separate "performance" globals for user and npm
code, we now have a single implementation.
This implementation is a de facto Node.js implementation - ie. it
contains additional properties compared to the "Web" implementation.
The two global can be compared using these docs sites:
- Web - https://developer.mozilla.org/en-US/docs/Web/API/Performance
- Node.js https://nodejs.org/api/perf_hooks.html
The benefit of this change is that when you use `performance.now()` in a
tight loop, the actual runtime of the code significantly improves - this
is because the `performance` global doesn't have to be "looked up" and
decided which is to be used, the "Web" or the "Node.js" version.
Ref https://github.com/denoland/deno/issues/28836
This PR replaces the _stream.mjs bundle with a file-by-file port instead. A codemod transpiles Node.js internals to ESM. The codemod performs three tasks: translating CJS to ESM, remapping internal dependencies, and hoisting lazy requires as imports.
The process is fully automated through the `update_node_stream.ts` script, simplifying future internal updates. The script checks out Node.js from a specific tag defined in the `tests/node_compat/runner`.
Additionally, the update enables new tests in our Node test runner and adds features (like compose()) that were missing from the outdated bundle.
## Performance
There is a 140KB+ binary size increase on aarch64-apple-darwin and nop startup time stays the same.
This commit makes `process` global always available in Node context.
`process` global was previously available explicitly in `deno_node`, but then
got removed in #25291 and made globally available regardless of whether it's in
Deno or Node context, so this commit does not have any effect on Deno CLI.
However, for users who want to use `deno_node` ext only, it makes sense to have
`process` available to simulate the Node environment individually.
This change may bring some negative performance impact. To measure how large the
impact would be, a very simple benchmark was performed whose results can be
found at https://github.com/magurotuna/process_global_bench.
Support for Wasm modules.
Note this implements the standard where the default export is the
instance (not the module). The module will come later with source phase
imports.
```ts
import { add } from "./math.wasm";
console.log(add(1, 2));
```
This will respect `"type": "commonjs"` in a package.json to determine if
`.js`/`.jsx`/`.ts`/.tsx` files are CJS or ESM. If the file is found to
be ESM it will be loaded as ESM though.
* cts support
* better cjs/cts type checking
* deno compile cjs/cts support
* More efficient detect cjs (going towards stabilization)
* Determination of whether .js, .ts, .jsx, or .tsx is cjs or esm is only
done after loading
* Support `import x = require(...);`
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Fixes https://github.com/denoland/deno/issues/26505
I'm not exactly sure how this case comes about (I tried to write tests
for it but couldn't manage to reproduce it), but what happens is the
parent filename ends up null, and we bail out of resolving the specifier
in package exports.
I've checked, and in node the parent filename is also null (so that's
not a bug on our part), but node continues to resolve even in that case.
So this PR should match node's behavior more closely than we currently
do.
implement require(esm) using `op_import_sync` from deno_core.
possible future changes:
- cts and mts
- replace Deno.core.evalContext to optimize esm syntax detection
Fixes: https://github.com/denoland/deno/issues/25487
To ensure consistency across the codebase, this commit refactors the
code in the `ext` folder to use `throw new Error`` instead of `throw`
for throwing errors.
Fixes https://github.com/denoland/deno/issues/25270
Turns out we only virtualized it so one could have a `Console` property,
and the other one not. We can just make this `console.Console` available
everywhere.
For some reason we didn't register the `node:inspector` module, which
lead to a panic when trying to import it. This PR registers it.
Related: https://github.com/denoland/deno/issues/25004
This is commonly used to register loading non standard file types. But
some libs also register TS loaders which Deno supports natively, like
the npm `payload` package. This PR unblocks those.
Fixes https://github.com/denoland/deno/issues/24902
- upgrade to v8 12.8
- optimizes DataView bigint methods
- fixes global interceptors
- includes CPED methods for ALS
- fix global resolution
- makes global resolution consistent using host_defined_options.
originally a separate patch but due to the global interceptor bug it
needs to be included in this pr for all tests to pass.
This stubs `findSourceMap` in `node:module` by always returning
`undefined` as if it never found a source map. This unblocks the `ava`
test runner.
Fixes https://github.com/denoland/deno/issues/18666
Part of #22607 (probably closes it, but I haven't done thorough testing)
Makes it so that `require.resolve` with `paths` specified will fallback
to using the global cache when the paths can't be found when using a
global cache (not when using a node_modules folder)
Follow up to #22157.
This leaves us with 4 usages of `ensureFastOps()` in `deno` itself.
There's also about 150 usages of `Deno.core.ops.<op_name>` left as well.
This commit refactors how we access "core", "internals" and
"primordials" objects coming from `deno_core`, in our internal JavaScript code.
Instead of capturing them from "globalThis.__bootstrap" namespace, we
import them from recently added "ext:core/mod.js" file.
