Repository navigation
require fallthrough behavior #11675
Description
- Version: all
- Platform: all
- Subsystem: module
require() has the ability to "fall through" multiple directories while searching for files.
https://github.com/bmeck/node-require-fallthrough-example/blob/master/nested/index.js
Given a dir structure of:
root
\- node_modules/foo/package.json
\- node_modules/foo/root.js
\- child
\- node_modules/foo/package.json
\- node_modules/foo/child.js
\- dependent.js
dependent.js has a surprising behavior of
require.resolve('foo/child'); // root/child/node_modules/child.js
require.resolve('foo/root'); // root/node_modules/root.js
If any error in resolving the "main" of child occurs, the main of root is used.
EPERM on child also has fallthrough behavior.
This means that you can place directories in parent node_modules to intercept requests for resources within a package. This should be discussed WRT signing packages and if we can remove this behavior.
The main concern here is breakage vs falling through a potentially secure context into an unsigned context and vice versa.
Activity
Slayer95 commentedon Mar 4, 2017
This behavior is the actual premise of
npm@3andnpm dedupe...Prior discussion:
nodejs/node-v0.x-archive#8830
#176
richardlau commentedon Mar 4, 2017
Completely or just for signed packages?
bmeck commentedon Mar 4, 2017
@richardlau completely, but in particular this is an actual problem for signing.
@Slayer95 not exactly, this is about intentional injection of files within a package's namespace, not intercepting the name of a package. If you look at the example and my comment the focus here differs since it is essentially preventing injection of
package/${inner_file}from having a differentpackagewhen required/imported from the same file. My suggestion here is that node should ensure that when you makepackage:node_modulescan intercept loading operations that miss, and nopackagewill not see any loading operations that would be in the same namespace as a childnode_moduleThis is not like
npm depupeas the intention is wrt files within packages, not preventing packages with the same name.richardlau commentedon Mar 4, 2017
@bmeck Can you point to any information re. signing packages? I wrote the following but suspect I'm probably missing some context.
What is a package? As far as Node.js is concerned (https://nodejs.org/dist/latest-v7.x/docs/api/modules.html#modules_modules):
Which is to say that currently Node.js has no notion of namespaces. One might assume a package is defined by
package.json, but at the moment Node.js only reads the main field from it: https://nodejs.org/dist/latest-v7.x/docs/api/modules.html#modules_all_togetherbmeck commentedon Mar 4, 2017
@richardlau correct, currently this is a bit ambiguous in core; my use of the term mostly comes from
npmnot core here where a "package" is a directory containing apackage.json(technically not entirely true as you can sneakily create things in the registry without apackage.json)As per signing, I am looking at various approaches but am leaning heavily towards https://github.com/dimich-g/webpackage . This is what I will be tackling after ESM.
I bring up this issue now since it relates to the ESM import resolution algorithm.
Trott commentedon Jul 30, 2017
@bmeck This is still a thing that needs addressing and should remain open? Is there anything anyone who is not you could and should be doing on this at this time?
bmeck commentedon Jul 30, 2017
refack commentedon Jul 30, 2017
Maybe consider as a breaking change only WRT to signed packages, that is - signed packages will not resolve with fall through?
TimothyGu commentedon Jul 31, 2017
@refack Are signed packages a thing yet?
refack commentedon Jul 31, 2017
I believe they have been cooking In @bmeck brains for a while (but AFAIK only there).
TimothyGu commentedon Jul 31, 2017
Closing per @bmeck.