foster/denoland-deno
1
0
Fork 0
mirror of https://github.com/denoland/deno.git synced 2024-11-21 15:04:11 -05:00
Code Issues Packages 1 Wiki Activity
denoland-deno/ext/node
History
Nathan Whitaker 6d44952d4d
fix(ext/node): resolve exports even if parent module filename isn't present (#26553) 
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.
2024-10-31 10:02:31 -07:00
..
benchmarks fix(runtime): use more null proto objects again (#25040) 2024-09-06 12:52:59 +02:00
ops fix(ext/node): resolve exports even if parent module filename isn't present (#26553) 2024-10-31 10:02:31 -07:00
polyfills fix(ext/node): resolve exports even if parent module filename isn't present (#26553) 2024-10-31 10:02:31 -07:00
build.rs chore: update copyright to 2024 (#21753) 2024-01-01 19:58:21 +00:00
Cargo.toml chore: forward v2.0.4 release commit to main (#26636) 2024-10-30 13:46:31 +01:00
clippy.toml refactor(ext/fs): deno_fs::FileSystem - conditional Send + Sync (#18993) 2023-05-08 11:02:02 -04:00
global.rs feat(cli): give access to process global everywhere (#25291) 2024-09-04 11:04:06 +02:00
lib.rs refactor(ext/node): use concrete error types (#26419) 2024-10-24 10:45:17 -07:00
polyfill.rs fix(ext/node): register node:wasi built-in (#25134) 2024-08-22 09:03:52 +05:30
README.md chore(ext/node): correct publishing for ext/node (#15461) 2022-08-11 17:25:41 -04:00

README.md

deno_node

require and other node related functionality for Deno.