summaryrefslogtreecommitdiff
path: root/ext/node/polyfills/internal_binding
AgeCommit message (Collapse)Author
2024-01-29refactor: Use virtul ops module (#22175)Bartek Iwańczuk
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.
2024-01-29refactor: migrate 'ext/node' extension to virtual ops module (#22157)Bartek Iwańczuk
Follow up to https://github.com/denoland/deno/pull/22135
2024-01-26chore: upgrade deno_core (#22124)Bartek Iwańczuk
Co-authored-by: Matt Mastracci <matthew@mastracci.com>
2024-01-26fix(node): remove deprecation warnings (#22120)Bartek Iwańczuk
Closes https://github.com/denoland/deno/issues/22116
2024-01-10refactor: use `core.ensureFastOps()` (#21888)Kenta Moriuchi
2024-01-10fix: android support (#19437)cions
<!-- Before submitting a PR, please read https://deno.com/manual/contributing 1. Give the PR a descriptive title. Examples of good title: - fix(std/http): Fix race condition in server - docs(console): Update docstrings - feat(doc): Handle nested reexports Examples of bad title: - fix #7123 - update docs - fix bugs 2. Ensure there is a related issue and it is referenced in the PR text. 3. Ensure there are tests that cover the changes. 4. Ensure `cargo test` passes. 5. Ensure `./tools/format.js` passes without changing files. 6. Ensure `./tools/lint.js` passes. 7. Open as a draft PR if your work is still in progress. The CI won't run all steps, but you can add '[ci]' to a commit message to force it to. 8. If you would like to run the benchmarks on the CI, add the 'ci-bench' label. --> --------- Signed-off-by: Matt Mastracci <matthew@mastracci.com> Co-authored-by: Matt Mastracci <matthew@mastracci.com>
2024-01-05chore: update deno_lint for CI (#21802)Kenta Moriuchi
2024-01-04fix: strict type check for cross realms (#21669)Kenta Moriuchi
Deno v1.39 introduces `vm.runInNewContext`. This may cause problems when using `Object.prototype.isPrototypeOf` to check built-in types. ```js import vm from "node:vm"; const err = new Error(); const crossErr = vm.runInNewContext(`new Error()`); console.assert( !(crossErr instanceof Error) ); console.assert( Object.getPrototypeOf(err) !== Object.getPrototypeOf(crossErr) ); ``` This PR changes to check using internal slots solves them. --- current: ``` > import vm from "node:vm"; undefined > vm.runInNewContext(`new Error("message")`) Error {} > vm.runInNewContext(`new Date("2018-12-10T02:26:59.002Z")`) Date {} ``` this PR: ``` > import vm from "node:vm"; undefined > vm.runInNewContext(`new Error("message")`) Error: message at <anonymous>:1:1 > vm.runInNewContext(`new Date("2018-12-10T02:26:59.002Z")`) 2018-12-10T02:26:59.002Z ``` --------- Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
2024-01-04fix(ext/node): UdpSocket ref and unref (#21777)Divy Srivastava
2024-01-01chore: update copyright to 2024 (#21753)David Sherret
2023-12-28chore: update deno_core to 0.240.0 (#21726)Bartek Iwańczuk
2023-12-19fix(console): inspect for `{Set,Map}Iterator` and `Weak{Set,Map}` (#21554)Kenta Moriuchi
2023-12-07refactor: pull 'core', 'internals', 'primordials' from ES module (#21462)Bartek Iwańczuk
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.
2023-11-28Reland "fix(ext/console): fix inspecting iterators error. (#20720)" (#21370)Leo Kettmeir
2023-11-13Revert "fix(ext/console): fix inspecting iterators error. (#20720)" (#21191)Bartek Iwańczuk
This reverts commit 0209f7b46954d1b7bf923b4191e5a356ec09622c. Reverting because it causes failures on `main`: https://github.com/denoland/deno/pull/20720#issuecomment-1809166755
2023-11-13fix(ext/console): fix inspecting iterators error. (#20720)Chen Su
Fixes #19776 and #20676.
2023-10-30fix: implement node:tty (#20892)Divy Srivastava
Fixes #21012 Closes https://github.com/denoland/deno/issues/20855 Fixes https://github.com/denoland/deno/issues/20890 Fixes https://github.com/denoland/deno/issues/20611 Fixes https://github.com/denoland/deno/issues/20336 Fixes `create-svelte` from https://github.com/denoland/deno/issues/17248 Fixes more reports here: - https://github.com/denoland/deno/issues/6529#issuecomment-1432690559 - https://github.com/denoland/deno/issues/6529#issuecomment-1522059006 - https://github.com/denoland/deno/issues/6529#issuecomment-1695803570
2023-10-05fix(ext/node): implement uv.errname (#20785)Divy Srivastava
Fixes https://github.com/denoland/deno/issues/20617
2023-09-27fix(ext/node): fix TypeError in Buffer.from with base64url encoding. (#20705)Chen Su
For the following example, if I set the encoding to `base64url`, it'll throw an unexpected TypeError: ```ts import { Buffer } from "node:buffer"; Buffer.from("IntcImhlbGxvXCI6XCJoZGQvZStpXCJ9Ig", "base64url").toString(); // error: Uncaught TypeError: src.subarray is not a function // const buf = Buffer.from( // ^ // at blitBuffer (ext:deno_node/internal/buffer.mjs:1779:15) // at Uint8Array.base64urlWrite (ext:deno_node/internal/buffer.mjs:691:10) // at Object.write (ext:deno_node/internal/buffer.mjs:2195:11) // at Uint8Array.write (ext:deno_node/internal/buffer.mjs:794:14) // at fromString (ext:deno_node/internal/buffer.mjs:214:22) // at _from (ext:deno_node/internal/buffer.mjs:119:12) // at Function.from (ext:deno_node/internal/buffer.mjs:157:10) // at file:///Users/foodieats/temp/buffer1.ts:3:20 ``` The error caused by `base64urlWrite` function, it should call `forgivingBase64UrlDecode` not `forgivingBase64UrlEncode` Also fixed #20563 .
2023-09-11perf(node/net): optimize socket reads for 'npm:ws' package (#20449)Bartek Iwańczuk
Fixes performance regression introduced by https://github.com/denoland/deno/pull/20223 and https://github.com/denoland/deno/pull/20314. It's enough to have one "shared" buffer per socket and no locking mechanism is required.
2023-09-07perf(ext/node): Optimise Buffer string operations (#20158)Aapo Alasuutari
Extracted from https://github.com/denoland/deno/pull/17815 Optimise Buffer's string operations, most significantly when dealing with ASCII and UTF-16. Base64 and HEX encodings are affected to much lesser degrees. ## Performance ### String length 15 With very small strings we're at break-even or sometimes even lose a tad bit of performance from creating a `DataView` that ends up not paying for itself. **This PR:** ``` benchmark time (avg) iter/s (min … max) p75 p99 p995 -------------------------------------------------------------------------------------------------------------- ----------------------------- Buffer.from ascii string 1.15 µs/iter 871,388.6 (728.78 ns … 1.56 µs) 1.23 µs 1.56 µs 1.56 µs Buffer.from base64 string 1.63 µs/iter 612,790.9 (1.31 µs … 1.96 µs) 1.77 µs 1.96 µs 1.96 µs Buffer.from utf16 string 1.41 µs/iter 707,396.3 (915.24 ns … 1.93 µs) 1.61 µs 1.93 µs 1.93 µs Buffer.from hex string 1.87 µs/iter 535,357.9 (1.56 µs … 2.19 µs) 2 µs 2.19 µs 2.19 µs Buffer.toString ascii string 154.58 ns/iter 6,469,162.8 (149.69 ns … 198 ns) 154.51 ns 182.89 ns 191.91 ns Buffer.toString base64 string 161.65 ns/iter 6,186,189.6 (150.91 ns … 181.15 ns) 165.18 ns 171.87 ns 174.94 ns Buffer.toString utf16 string 292.74 ns/iter 3,415,959.8 (285.43 ns … 312.47 ns) 295.25 ns 310.47 ns 312.47 ns Buffer.toString hex string 89.61 ns/iter 11,159,315.6 (81.09 ns … 123.77 ns) 91.09 ns 113.62 ns 119.28 ns ``` **Main:** ``` benchmark time (avg) iter/s (min … max) p75 p99 p995 -------------------------------------------------------------------------------------------------------------- ----------------------------- Buffer.from ascii string 1.26 µs/iter 794,875.8 (1.07 µs … 1.46 µs) 1.31 µs 1.46 µs 1.46 µs Buffer.from base64 string 1.65 µs/iter 607,853.3 (1.38 µs … 2.01 µs) 1.69 µs 2.01 µs 2.01 µs Buffer.from utf16 string 1.34 µs/iter 744,894.6 (1.09 µs … 1.55 µs) 1.45 µs 1.55 µs 1.55 µs Buffer.from hex string 2.01 µs/iter 496,345.8 (1.54 µs … 2.6 µs) 2.26 µs 2.6 µs 2.6 µs Buffer.toString ascii string 150.16 ns/iter 6,659,630.5 (144.99 ns … 166.68 ns) 152.4 ns 157.26 ns 159.14 ns Buffer.toString base64 string 164.73 ns/iter 6,070,692.0 (158.77 ns … 185.63 ns) 168.48 ns 175.74 ns 176.68 ns Buffer.toString utf16 string 150.61 ns/iter 6,639,864.0 (148.2 ns … 168.29 ns) 150.93 ns 157.21 ns 168.15 ns Buffer.toString hex string 94.21 ns/iter 10,614,972.9 (86.21 ns … 98.75 ns) 95.43 ns 97.99 ns 98.21 ns ``` ### String length 1500 With moderate lengths we already see great upsides for `Buffer.from()` with ASCII and UTF-16. **This PR:** ``` benchmark time (avg) iter/s (min … max) p75 p99 p995 -------------------------------------------------------------------------------------------------------------- ----------------------------- Buffer.from ascii string 5.79 µs/iter 172,562.6 (4.72 µs … 4.71 ms) 5.04 µs 10.3 µs 11.67 µs Buffer.from base64 string 5.08 µs/iter 196,678.9 (4.97 µs … 5.76 µs) 5.08 µs 5.76 µs 5.76 µs Buffer.from utf16 string 9.68 µs/iter 103,316.5 (7.14 µs … 3.44 ms) 10.32 µs 13.42 µs 15.21 µs Buffer.from hex string 53.7 µs/iter 18,620.2 (49.37 µs … 2.2 ms) 54.74 µs 72.2 µs 81.07 µs Buffer.toString ascii string 6.63 µs/iter 150,761.3 (5.59 µs … 1.11 ms) 6.08 µs 15.68 µs 24.77 µs Buffer.toString base64 string 460.57 ns/iter 2,171,224.4 (448.33 ns … 511.73 ns) 465.05 ns 495.54 ns 511.73 ns Buffer.toString utf16 string 6.52 µs/iter 153,287.0 (6.47 µs … 6.66 µs) 6.53 µs 6.66 µs 6.66 µs Buffer.toString hex string 3.68 µs/iter 271,965.4 (3.64 µs … 3.82 µs) 3.68 µs 3.82 µs 3.82 µs ``` **Main:** ``` benchmark time (avg) iter/s (min … max) p75 p99 p995 -------------------------------------------------------------------------------------------------------------- ----------------------------- Buffer.from ascii string 11.46 µs/iter 87,298.1 (8.53 µs … 834.1 µs) 9.61 µs 83.31 µs 87.3 µs Buffer.from base64 string 5.4 µs/iter 185,027.8 (5.07 µs … 7.49 µs) 5.44 µs 7.49 µs 7.49 µs Buffer.from utf16 string 20.3 µs/iter 49,270.8 (13.55 µs … 649.11 µs) 18.8 µs 113.93 µs 125.17 µs Buffer.from hex string 52.03 µs/iter 19,218.9 (48.74 µs … 2.59 ms) 52.84 µs 67.05 µs 73.56 µs Buffer.toString ascii string 6.46 µs/iter 154,822.5 (6.32 µs … 6.69 µs) 6.52 µs 6.69 µs 6.69 µs Buffer.toString base64 string 440.19 ns/iter 2,271,764.6 (427 ns … 490.77 ns) 444.74 ns 484.64 ns 490.77 ns Buffer.toString utf16 string 6.89 µs/iter 145,106.7 (6.81 µs … 7.24 µs) 6.91 µs 7.24 µs 7.24 µs Buffer.toString hex string 3.66 µs/iter 273,456.5 (3.6 µs … 4.02 µs) 3.64 µs 4.02 µs 4.02 µs ``` ### String length 2^20 With massive lengths we the difference in ASCII and UTF-16 parsing performance is enormous. **This PR:** ``` benchmark time (avg) iter/s (min … max) p75 p99 p995 -------------------------------------------------------------------------------------------------------------------- ----------------------------- Buffer.from ascii string 4.1 ms/iter 243.7 (2.64 ms … 6.74 ms) 4.43 ms 6.26 ms 6.74 ms Buffer.from base64 string 3.74 ms/iter 267.6 (2.91 ms … 4.92 ms) 3.96 ms 4.31 ms 4.92 ms Buffer.from utf16 string 7.72 ms/iter 129.5 (5.91 ms … 11.03 ms) 7.97 ms 11.03 ms 11.03 ms Buffer.from hex string 35.72 ms/iter 28.0 (34.71 ms … 38.42 ms) 35.93 ms 38.42 ms 38.42 ms Buffer.toString ascii string 78.92 ms/iter 12.7 (42.72 ms … 94.13 ms) 91.64 ms 94.13 ms 94.13 ms Buffer.toString base64 string 833.62 µs/iter 1,199.6 (638.05 µs … 5.97 ms) 826.86 µs 2.45 ms 2.48 ms Buffer.toString utf16 string 79.35 ms/iter 12.6 (69.72 ms … 88.9 ms) 86.66 ms 88.9 ms 88.9 ms Buffer.toString hex string 31.04 ms/iter 32.2 (4.3 ms … 46.9 ms) 37.21 ms 46.9 ms 46.9 ms ``` **Main:** ``` benchmark time (avg) iter/s (min … max) p75 p99 p995 -------------------------------------------------------------------------------------------------------------------- ----------------------------- Buffer.from ascii string 18.66 ms/iter 53.6 (15.61 ms … 23.26 ms) 20.62 ms 23.26 ms 23.26 ms Buffer.from base64 string 4.7 ms/iter 212.9 (2.94 ms … 9.07 ms) 4.65 ms 9.06 ms 9.07 ms Buffer.from utf16 string 33.49 ms/iter 29.9 (31.24 ms … 35.67 ms) 34.08 ms 35.67 ms 35.67 ms Buffer.from hex string 39.38 ms/iter 25.4 (38.66 ms … 42.36 ms) 39.58 ms 42.36 ms 42.36 ms Buffer.toString ascii string 77.68 ms/iter 12.9 (67.46 ms … 95.68 ms) 84.71 ms 95.68 ms 95.68 ms Buffer.toString base64 string 825.53 µs/iter 1,211.3 (655.38 µs … 6.69 ms) 816.62 µs 3.07 ms 3.13 ms Buffer.toString utf16 string 76.54 ms/iter 13.1 (66.9 ms … 85.26 ms) 83.63 ms 85.26 ms 85.26 ms Buffer.toString hex string 38.56 ms/iter 25.9 (33.83 ms … 46.56 ms) 45.33 ms 46.56 ms 46.56 ms ```
2023-09-07feat: support import attributes (#20342)David Sherret
2023-08-28fix(ext/node): shared global buffer unlock correctness fix (#20314)Matt Mastracci
The fix for #20188 was not entirely correct -- we were unlocking the global buffer incorrectly. This PR introduces a lock state that ensures we only unlock a lock we have taken out.
2023-08-22fix(ext/node): simultaneous reads can leak into each other (#20223)Matt Mastracci
Reported in #20188 This was caused by re-use of a global buffer `BUF` during simultaneous async reads.
2023-08-11fix(node): implement TLSSocket._start (#20120)Divy Srivastava
Closes https://github.com/denoland/deno/issues/19983 Closes https://github.com/denoland/deno/issues/18303 Closes https://github.com/denoland/deno/issues/16681 Closes https://github.com/denoland/deno/issues/19978
2023-07-18fix(ext/node): check if resource can be used with write_vectored (#19868)Divy Srivastava
Fixes https://github.com/denoland/deno/issues/19766 Fixes https://github.com/denoland/deno/issues/19846
2023-07-07perf(ext/node): native vectored write for server streams (#19752)Divy Srivastava
``` # main $ ./load_test 10 0.0.0.0 8080 0 0 Using message size of 20 bytes Running benchmark now... Msg/sec: 106182.250000 Msg/sec: 110279.750000 ^C # this PR $ ./load_test 10 0.0.0.0 8080 0 0 Using message size of 20 bytes Running benchmark now... Msg/sec: 131632.250000 Msg/sec: 134754.250000 ^C ```
2023-07-05perf(ext/node): optimize net streams (#19678)Divy Srivastava
~4.5x improvement in `npm:ws` echo benchmark: ``` $ ./load_test 10 0.0.0.0 8080 0 0 Using message size of 20 bytes Running benchmark now... Msg/sec: 101083.750000 Msg/sec: 103606.000000 ^C $ ./load_test 10 0.0.0.0 8080 0 0 Using message size of 20 bytes Running benchmark now... Msg/sec: 24906.750000 Msg/sec: 28478.000000 ^C ```
2023-07-02refactor: rename built-in node modules from ext:deno_node/ to node: (#19680)Bartek Iwańczuk
Closes https://github.com/denoland/deno/issues/19510
2023-06-27fix: lint on main branch (#19622)Bartek Iwańczuk
2023-06-27chore(ext/node): disable prefer-primordials on a per-file basis (#19553)Kenta Moriuchi
2023-06-26chore: fix typos (#19572)Martin Fischer
2023-06-12feat: Adaptations to support OpenBSD port (#19153)VlkrS
2023-05-26refactor(node): use internal io and fs APIs (#19267)Bartek Iwańczuk
2023-04-20refactor(ext/node): remove polyfills/_core.ts (#18766)Yoshiya Hinosawa
2023-03-28Reland "refactor: remove Deno[Deno.internal].nodeUnstable namespace" (#18475)Bartek Iwańczuk
This reverts commit 357bcfcf79fee92195e37bb3f05e247908f207c5.
2023-03-27Revert "refactor: remove Deno[Deno.internal].nodeUnstable namespace (… ↵Bartek Iwańczuk
(#18458) …#18449)" This reverts commit d1a9c4cd7ce0c19ddf9c7c52c0d35d6124a7677d. Appears this made CI very flaky on macOS, but I can't repeat it locally yet
2023-03-27refactor: remove Deno[Deno.internal].nodeUnstable namespace (#18449)Bartek Iwańczuk
Since we can preserve ops in the snapshot these days, we no longer need to have "Deno[Deno.internal].nodeUnstable" namespace. Instead, various built-in Node.js modules can use appropriate APIs directly.
2023-03-08refactor: rename InternalModuleLoader to ExtModuleLoader, use ext: scheme ↵Bartek Iwańczuk
for snapshotted modules (#18041) This commit renames "deno_core::InternalModuleLoader" to "ExtModuleLoader" and changes the specifiers used by the modules loaded from this loader to "ext:". "internal:" scheme was really ambiguous and it's more characters than "ext:", which should result in slightly smaller snapshot size. Closes https://github.com/denoland/deno/issues/18020
2023-03-05chore(ext/node): cleanup empty internal_bindings (#18032)Divy Srivastava
2023-03-05refactor(core): include_js_files! 'dir' option doesn't change specifiers ↵Bartek Iwańczuk
(#18019) This commit changes "include_js_files!" macro from "deno_core" in a way that "dir" option doesn't cause specifiers to be rewritten to include it. Example: ``` include_js_files! { dir "js", "hello.js", } ``` The above definition required embedders to use: `import ... from "internal:<ext_name>/js/hello.js"`. But with this change, the "js" directory in which the files are stored is an implementation detail, which for embedders results in: `import ... from "internal:<ext_name>/hello.js"`. The directory the files are stored in, is an implementation detail and in some cases might result in a significant size difference for the snapshot. As an example, in "deno_node" extension, we store the source code in "polyfills" directory; which resulted in each specifier to look like "internal:deno_node/polyfills/<module_name>", but with this change it's "internal:deno_node/<module_name>". Given that "deno_node" has over 100 files, many of them having several import specifiers to the same extension, this change removes 10 characters from each import specifier.
2023-02-26fix(ext/node): util.types.isSharedArrayBuffer (#17836)Yoshiya Hinosawa
2023-02-16perf(ext/node): move winerror binding to rust (#17792)Divy Srivastava
16873 lines of JS removed from the snapshot.
2023-02-14feat(ext/node): embed std/node into the snapshot (#17724)Bartek Iwańczuk
This commit moves "deno_std/node" in "ext/node" crate. The code is transpiled and snapshotted during the build process. During the first pass a minimal amount of work was done to create the snapshot, a lot of code in "ext/node" depends on presence of "Deno" global. This code will be gradually fixed in the follow up PRs to migrate it to import relevant APIs from "internal:" modules. Currently the code from snapshot is not used in any way, and all Node/npm compatibility still uses code from "https://deno.land/std/node" (or from the location specified by "DENO_NODE_COMPAT_URL"). This will also be handled in a follow up PRs. --------- Co-authored-by: crowlkats <crowlkats@toaxl.com> Co-authored-by: Divy Srivastava <dj.srivastava23@gmail.com> Co-authored-by: Yoshiya Hinosawa <stibium121@gmail.com>
generated by cgit v1.2.3 (git 2.25.1) at 2025-07-27 04:18:10 +0000