Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.


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
module: add support for
node:‑prefixedrequire(…)calls #37246module: add support for
node:‑prefixedrequire(…)calls #37246Changes from all commits
069b5df95391feFile filter
Conversations
Jump to
richardlauMar 5, 2021
Member
This is a bit of an odd example as the non-prefixed
require('http')would be treated as a built in and bypass the require cache.bmeckMar 5, 2021
Member
currently builtin modules go through the cache if a matching entry exists, I don't understand the comment
richardlauMar 5, 2021
Member
If there is a cache it should always point to the built in HTTP module, shouldn't it? AFAIK it's not possible for Node.js to return anything other than the built in module for built in modules.
ExE-BossMar 5, 2021
Author
Contributor
Actually,
require("http")currently checksrequire.cache["http"]before callingloadNativeModule("http").Check failure on line 666 in doc/api/modules.md
doc/api/modules.md#L666
Check failure on line 666 in doc/api/modules.md
doc/api/modules.md#L666
Check failure on line 666 in doc/api/modules.md
doc/api/modules.md#L666
Check failure on line 666 in doc/api/modules.md
doc/api/modules.md#L666
guybedfordFeb 8, 2021
Contributor
What is the motivation for short-circuiting the cache here, something that has never been done previously for native modules?
I don't see why this scheme should be any different to any other in this regard.
bmeckMar 5, 2021
Member
On this topic, should we throw or defer to cache on unknown builtins?
guybedfordFeb 8, 2021
Contributor
This bifurcation will have implications for mocking, but I can appreciate the benefit too.
I'd still prefer a more convergent path here eg, to return
node:fsfor bothnode:fsandfsinputs, and then to still populate acache['fs']entry in thenode:fscase as the same object for backwards compatibility. Such a change would hopefully be mostly compatible but would probably need to be a separate major nontheless. Worth thinking about at least.ExE-BossFeb 8, 2021
Author
Contributor
Existing mocking tools (such as Jest) provide their own
require(…)implementation, since they need to be able to bypass the mocked module usingjest.requireActual(…).bmeckFeb 6, 2021
Member
this differs from other builtins, I love it, but want to be sure it is intentional.
ljharbFeb 6, 2021
Member
this actually seems like an issue - it means someone who replaces a builtin intentionally can’t replace one of these (altho presumably mutating a builtin would be visible in both). That could cause an issue where someone wants to use a package to instrument or lock down
fs(and thus, policies are not an ergonomic option, unless I’m misunderstanding how policies work), but accidentally leaves a gaping security hole when an attacker requiresnode:fs.bmeckFeb 6, 2021
Member
policies should intercept before any of the resolution helpers even get called
node/lib/internal/modules/cjs/helpers.js
Line 52 in 36cc0ee
module.requireand get here without some kind of opt-in to the behavior (likedependencies:true).benjamingrFeb 6, 2021
Member
At the very least this needs documentation and probably a strong indication people using policies + instrumenting fs now need to update the policy.
ljharbFeb 6, 2021
Member
My point was that policies aren’t currently required to ensure this for CJS - a package (not the app itself) can do it. Forcing policies to be the mechanism means packages are no longer capable of abstracting this for users.
bmeckFeb 6, 2021
Member
@ljharb ah, yes that is true. I just wanted to be clear that policies can prevent this intentionally and should not be considered to have support for such a workflow.
ljharbFeb 6, 2021
Member
Totally understood. Given that policies are the superior mechanism for app developers to lock things down, what's the benefit of adding special, inconsistent, cache-bypassing behavior for
requirewith anode:prefix?bmeckFeb 7, 2021
Member
@ljharb i have no strong opinion on if we should diverge, but cache first behavior of CJS isn't shared by ESM and isn't robust against things like core destructuring the original impls. My like is just that it isn't a confusing situation like with
fs/.ExE-BossFeb 8, 2021
•
edited
Author
Contributor
This is demonstrated by:
ljharbFeb 8, 2021
Member
indeed, but that doesn’t mean it’s a good idea to make CJS inconsistent with itself.
bmeckMar 5, 2021
Member
I don't think CJS is able to be claimed as consistent with itself since in general the natives don't normally populate the cache. I think it was just ad-hoc written together and the cache behavior is evolutionary not intentional or well understood (even by me).