summaryrefslogtreecommitdiff
path: root/ext/node/polyfills/internal/fs/utils.mjs
AgeCommit message (Collapse)Author
2024-08-16fix(node/fs): Use correct offset and length in node:fs.read and write (#25049)Nathan Whitaker
My fix in #25030 was buggy, I forgot to pass the `byteOffset` and `byteLength`. Whoops. I also discovered that fs.read was not respecting the `offset` argument, and we were constructing a new `Buffer` for the callback instead of just passing the original one (which is what node does, and the @types/node definitions also indicate the callback should get the same type). Fixes #25028.
2024-08-14fix(node/fs): node:fs.read and write should accept typed arrays other than ↵Nathan Whitaker
Uint8Array (#25030) Part of #25028. Our underlying read/write operations in `io` assume the buffer is a Uint8Array, but we were passing in other typed arrays (in the case above it was `Int8Array`).
2024-08-12chore: update the copyright of c, mjs, and jsx (#25005)Kenta Moriuchi
2024-07-02fix(ext/node): Add `fs.lutimes` / `fs.lutimesSync` (#23172)Nathan Whitaker
Part of #18218 - Adds `fs.lutimes` and `fs.lutimesSync` to our node polyfills. To do this I added methods to the `FileSystem` trait + ops to expose the functionality to JS. - Exports `fs._toUnixTimestamp`. Node exposes an internal util `toUnixTimestamp` from the fs module to be used by unit tests (so we need it for the unit test to pass unmodified). It's weird because it's only supposed to be used internally but it's still publicly accessible - Matches up error handling and timestamp handling for fs.futimes and fs.utimes with node - Enables the node_compat utimes test - this exercises futimes, lutimes, and utimes.
2024-06-11chore: sync up Node.js test files for v20.11.1 (#24066)Bartek Iwańczuk
Co-authored-by: Yoshiya Hinosawa <stibium121@gmail.com>
2024-05-16fix(node): error when throwing `FS_EISDIR` (#23829)Marvin Hagemeister
The `EISDIR` error code is not available as a global variable, but must be accessed through the `osConstants.errno` object. Fixes https://github.com/denoland/deno/issues/23695
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-27chore(ext/node): disable prefer-primordials on a per-file basis (#19553)Kenta Moriuchi
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-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-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>