-
-
Notifications
You must be signed in to change notification settings - Fork 22
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
Get ImportProvider working with mutability and provided methods. #147
Get ImportProvider working with mutability and provided methods. #147
Conversation
src/module_loader.rs
Outdated
let maybe_referrer = maybe_referrer.clone(); | ||
let requested_module_type = requested_module_type.clone(); |
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.
You're cloning these twice
Not sure you need to clone at all? This block should be able to take ownership no?
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.
When I remove those two lines, I got errors. Will get more info on this later.
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.
Specifically, if I remove the first clones, I get "lifetime may not live long enough" and if I don't do the second clone, I get a "can't move out of captured variable" which occurs because Option<Url> doesn't have Copy. I left both clones in there with the intention of fixing it when I could understand what's going on there better.
…error when feature not enabled)
Sorry for the delay here. That test isn't written yet and a couple parts maybe could be a bit cleaner, but I think these changes are a bit more like what you were looking for. Feel free to suggest more changes. |
Nvm figured it out, see commit. |
And that's the test done. Feedback is appreciated. |
I have not forgotten about this, btw |
Of course, don't worry about it. I will take care of any merge work that will be necessary. |
@rscarson There's a handful of "unused variable" and "variable is never read" warnings which only appear when the feature gate is disabled. Is it preferable to silence these with underscores or |
Where are the warnings? |
It is mostly regarding parameters that only get used inside feature-gated bits of their scope. |
Ah I see, then yeah probably safe to ignore |
Whoops, messed up the merge on the test section. Will get that in a bit. |
@rscarson I made sure to more thoroughly feature-gate every instance where ImportProvider is used, even in function parameters. I've just been adding to module_loader.rs thus far, so gating the whole file wouldn't make much sense at the current moment, but if you'd prefer I can split this feature off into its own file. Now that everything's working as expected, I am aiming to finalize this PR to be merged. I can also try to improve the doc comments and simplify the examples if needed. |
|
||
[[example]] | ||
name = "async_javascript" | ||
required-features = ["web_stub"] |
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.
Ah good catch on this
src/inner_runtime.rs
Outdated
@@ -131,7 +137,11 @@ pub struct InnerRuntime { | |||
} | |||
impl InnerRuntime { | |||
pub fn new(options: RuntimeOptions) -> Result<Self, Error> { | |||
let loader = Rc::new(RustyLoader::new(options.module_cache)); | |||
let loader = Rc::new(RustyLoader::new( |
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 might move these into a LoaderOptions or something eventually but that's not public facing so not a big deal
LGTM! I'll merge this in Monday! Thanks for all your hard work! |
I had to make a few changes, but the new trait is now integrated and working |
@@ -126,10 +158,21 @@ impl ModuleLoader for RustyLoader { | |||
&self, | |||
specifier: &str, | |||
referrer: &str, | |||
_kind: deno_core::ResolutionKind, | |||
kind: deno_core::ResolutionKind, | |||
) -> Result<ModuleSpecifier, anyhow::Error> { | |||
// Resolve the module specifier to an absolute URL | |||
let url = deno_core::resolve_import(specifier, referrer)?; |
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.
Is it possible to create a custom url resolver for a module specifier?
I want to make imports look like ... from 'my-module'
to be compatible with Node.js. However, I'm encountering an error from here:
Relative import path "my-module" not prefixed with / or ./ or ../ from "file:///<...>/index.js"
This new branch has ImportProvider working with mutability for struct members, allowing for the dynamic importing functionality I initially described. Without the custom_import feature enabled, permissions checking remains same. Imports that use
file
orhttp
/https
are not able to be overridden by ImportProvider, but I don't think that's a huge loss.Permissions checking in RustyLoader's resolve method occurs after the ImportProvider's (or deno's) resolve method is called. This means that if the user makes a custom specifier resolve to an
http
orhttps
url whileurl_import
is disabled, the resolution will fail as web imports are not allowed, even though the specifier doesn't contain http or https on the javascript side.I also added two separate examples, which I think demonstrate why I think ImportProvider's import and resolve should be provided methods; they have separate use cases and should be able to be used conveniently without both methods implemented. The exact implementations provided by the trait may not be final.
EDIT: There's also a couple formatting anomalies. I will clean this up later today.