-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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(cli): allow bare specifier for builtin node module #20728
feat(cli): allow bare specifier for builtin node module #20728
Conversation
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.
Will the warning be printed for every occurence of import "fs"
or only the first one?
cli/resolver.rs
Outdated
@@ -291,6 +295,12 @@ impl NpmResolver for CliGraphResolver { | |||
} | |||
} | |||
|
|||
fn on_resolve_bare_builtin_node_module(&self, module_name: &str) { | |||
if !self.quiet { | |||
eprintln!("Warning: Resolving \"{module_name}\" as \"node:{module_name}\". If you want to use a built-in Node module, add a \"node:\" prefix.") |
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.
We can get rid of the quiet
property and just use the log::warn!
macro. The --quiet
flag will automatically work with log::warn!
|
889f830
to
f706dec
Compare
@@ -1,4 +1,4 @@ | |||
error: Uncaught (in promise) TypeError: Relative import path "unmapped" not prefixed with / or ./ or ../ and not in import map from "file://[WILDCARD]/092_import_map_unmapped_bare_specifier.ts" |
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 last part of this error message was lost because of this commit (We now ignore ImportMapError::UnmappedBareSpecifier
because that can't be handled by bare node specifier check implemented in deno_graph
.
I drafted a PR to handle ImportMapError::UnmappedBareSpecifier
in deno_graph
, but I'm not sure it's worth the complexity
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.
@bartlomieju asked for a feature flag that would allow us to land this disabled in a patch release. I don't see that in this patch?
@ry maybe we can just land it without a feature flag in a patch? denoland/deno_graph#295 (comment) |
Created an issue for feature flag system #20779 Let me check my understanding. Are we going to handle 3 inputs for checking whether the feature is enabled?
|
Yup, that sounds good to me. |
Just saw this comment. #20765 should unblock you for checking if the feature is enabled. I would suggest |
|
This branch now reads the feature flag from 3 inputs: |
I'd like to avoid implementing |
@kt3k you can now get an instance of |
I'm curious why this needs to use the feature checker. I feel like what's done here is fine since this is not an unstable runtime feature? What would the code look like? |
Now feature_checker is moved to CliFactory in #20797, and it's ready when we create the resolver. So I think it makes sense to pass flag to feature_checker, and we can follow the same pattern for all unstable flags. |
Now |
cli/args/mod.rs
Outdated
@@ -1216,6 +1216,13 @@ impl CliOptions { | |||
self.flags.unstable | |||
} | |||
|
|||
pub fn unstable_bare_node_builtlins(&self) -> bool { | |||
self.flags.unstable_bare_node_builtlins | |||
|| self.maybe_config_file().as_ref().map_or(false, |c| { |
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.
Personally I find map_or
to be confusing to read because it reads backwards instead of left to right or top to bottom. I opened #18212 to remove them in the past.
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.
Oh, we prefer map().unwrap_or()
. Ok. I'll update.
cli/factory.rs
Outdated
@@ -563,6 +566,9 @@ impl CliFactory { | |||
pub fn feature_checker(&self) -> &Arc<FeatureChecker> { | |||
self.services.feature_checker.get_or_init(|| { | |||
let mut checker = FeatureChecker::default(); | |||
if self.options.unstable_bare_node_builtlins() { | |||
checker.enable_feature("bare-node-builtins"); | |||
} |
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'm not sure it makes sense to pass this to the feature checker unless the feature is being used with the runtime code. For example, in this case we could just call self.options.unstable_bare_node_builtins()
above on line 380.
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.
Maybe this is just an overhead. Updated
We currently support the following 3. Do these look fine? (Especially I'm unconfident about the casing of
$ cat b.js
import path from "path"
console.log(path.resolve);
$ ./target/debug/deno run b.js
error: Relative import path "path" not prefixed with / or ./ or ../
If you want to use a built-in Node module, add a "node:" prefix (ex. "node:path").
at file:///Users/kt3k/denoland/deno/b.js:1:18
$ ./target/debug/deno run --unstable-bare-node-builtins b.js
Warning: Resolving "path" as "node:path" at file:///Users/kt3k/denoland/deno/b.js:1:18. If you want to use a built-in Node module, add a "node:" prefix.
[Function: resolve]
$ DENO_UNSTABLE_NODE_BUILTINS=1 ./target/debug/deno run b.js
Warning: Resolving "path" as "node:path" at file:///Users/kt3k/denoland/deno/b.js:1:18. If you want to use a built-in Node module, add a "node:" prefix.
[Function: resolve]
$ echo '{"unstable":["bare-node-builtins"]}' > deno.json
$ ./target/debug/deno run b.js
Warning: Resolving "path" as "node:path" at file:///Users/kt3k/denoland/deno/b.js:1:18. If you want to use a built-in Node module, add a "node:" prefix.
[Function: resolve] |
@kt3k looks good to me! |
@bartlomieju PTAL |
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 too!
This PR allows using bare specifiers for importing builtin node modules (ex. "fs" resolves to "node:fs"). When such resolution happens, the warnings like the below are shown.
This feature is implemented behind the unstable flag `--unstable-bare-node-builtins"
closes #20566