-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(unstable): initial support for npm specifiers #15484
Conversation
… into npm_deno_run_support
…quire_resolve_exports
Excluding the testdata
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work @dsherret !
I'm concerned about the deno_graph slowness, it's going to be pretty apparent to users.
|
||
// add the builtin node modules to the graph data | ||
let node_std_graph = self | ||
.create_graph(vec![(compat::MODULE_ALL_URL.clone(), ModuleKind::Esm)]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The slowness is quite bad... it takes almost 2 seconds to load a very basic npm dependency that's already been downloaded.
) -> Result<(), AnyError> { | ||
let source_code = &format!( | ||
r#"(async function loadBuiltinNodeModules(moduleAllUrl) {{ | ||
const moduleAll = await import(moduleAllUrl); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's unfortunate that we have to load all of the node modules even if only some are used. Do you think in the future these could be loaded lazily?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unlikely, these modules have a lot of cross-imports, so they would be loaded anyway
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd push back on that assumption. I'm sure there are many npm modules that don't require, say, crypto.
/// For all discovered reexports the analysis will be performed recursively. | ||
/// | ||
/// If successful a source code for equivalent ES module is returned. | ||
pub fn translate_cjs_to_esm( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would be great to have a little unit test for this...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are integration tests that cover this API
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This adds initial very rough support for npm specifiers for
deno run
,deno eval
, anddeno test
.--reload
flag.setTimeout
implementation.deno run npm:mkdirp
, deno info, deno vendor, or lockfile support yet. These will land in separate PRs.Maybes before landing:
Co-authored-by: Bartek Iwańczuk [email protected]