Skip to content
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

refactor: remove PermissionsContainer in deno_runtime #24119

Merged
merged 2 commits into from
Jun 7, 2024

Conversation

dsherret
Copy link
Member

@dsherret dsherret commented Jun 6, 2024

Also removes permissions being passed in for node resolution. It was completely useless because we only checked it for reading package.json files, but Deno reading package.json files for resolution is perfectly fine.

My guess is this is also a perf improvement because Deno is doing less work.

let code_source = if let Some(result) = self
.shared
.npm_module_loader
.load_if_in_npm_package(specifier, maybe_referrer, permissions)
.load_if_in_npm_package(specifier, maybe_referrer)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The permissions were only used for cjs resolution for loading a package.json, which was kind of useless.

path: &Path,
api_name: Option<&str>,
) -> Result<(), AnyError>;
}

pub(crate) struct AllowAllNodePermissions;
pub struct AllowAllNodePermissions;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I exposed this because it's faster to use this trait than construct a new PermissionsContainer.

state.put(Rc::new(NodeResolver::new(
fs,
npm_resolver,
)))
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has an internal in_npm_package_cache that we can share across workers by passing the single instance into here.

@dsherret dsherret marked this pull request as ready for review June 6, 2024 18:21
Copy link
Member

@bartlomieju bartlomieju left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, but let's wait for a second pair of eyes from Divy

referrer,
DEFAULT_CONDITIONS,
mode,
permissions,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure these were only used for package.json? I thought we used them when probing for various file extensions

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It hasn't been from what I can tell, but even if it were I don't think we should bother permission checking that?

Copy link
Member

@littledivy littledivy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

Someday we'll start truly migrating perm checks to using deno_permissions :)

@dsherret dsherret merged commit 386d5c8 into denoland:main Jun 7, 2024
20 checks passed
@dsherret dsherret deleted the refactor_permissions_container branch June 7, 2024 03:37
nathanwhit pushed a commit that referenced this pull request Jun 13, 2024
Also removes permissions being passed in for node resolution. It was
completely useless because we only checked it for reading package.json
files, but Deno reading package.json files for resolution is perfectly
fine.

My guess is this is also a perf improvement because Deno is doing less
work.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants