stonyx 0.2.3-alpha.55 → 0.2.3-alpha.56
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -47,10 +47,13 @@ export type InconclusiveReporter = (message: string) => void;
|
|
|
47
47
|
* mode rather than screening for it — nothing here reads the environment, so
|
|
48
48
|
* there is no list to get the screen wrong on.
|
|
49
49
|
*
|
|
50
|
-
* TOO NARROW, and this one was a SILENT MISS.
|
|
51
|
-
*
|
|
52
|
-
*
|
|
53
|
-
*
|
|
50
|
+
* TOO NARROW, and this one was a SILENT MISS. WHICH CJS ENUMERATION IS MEANT
|
|
51
|
+
* IS PART OF THE CLAIM, because the two are not the same set: the walk PROPER
|
|
52
|
+
* is `Module._nodeModulePaths`, and `require.resolve.paths` is that walk
|
|
53
|
+
* FOLLOWED BY the global folders of the paragraph above. It is the walk proper
|
|
54
|
+
* that never descends into a directory already named `node_modules`. **ESM's
|
|
55
|
+
* PACKAGE_RESOLVE has no such skip.** Measured with no `NODE_PATH` at all,
|
|
56
|
+
* from a module at `<app>/node_modules/@stonyx/x`:
|
|
54
57
|
*
|
|
55
58
|
* import.meta.resolve('stonyx') -> <app>/node_modules/node_modules/stonyx/main.js
|
|
56
59
|
* await import('stonyx') -> that copy
|
|
@@ -64,6 +67,18 @@ export type InconclusiveReporter = (message: string) => void;
|
|
|
64
67
|
* written to catch it. Isolating control, moving nothing but the directory: the
|
|
65
68
|
* same core at `<app>/node_modules/@stonyx/x/node_modules/stonyx` was REFUSED.
|
|
66
69
|
*
|
|
70
|
+
* THE SET DELTA, both directions and named per enumeration — node v24.13.0,
|
|
71
|
+
* from that same module dir. Against the WALK PROPER the difference is one
|
|
72
|
+
* directory and it is one-sided: `esm \ Module._nodeModulePaths` = exactly
|
|
73
|
+
* `<app>/node_modules/node_modules` (the miss above), and
|
|
74
|
+
* `Module._nodeModulePaths \ esm` = `[]`. Against `require.resolve.paths` the
|
|
75
|
+
* second direction is NOT empty and never was: `require.resolve.paths \ esm` =
|
|
76
|
+
* the three global folders (measured here: `~/.node_modules`,
|
|
77
|
+
* `~/.node_libraries` and the node prefix, all three absent on disk) PLUS one
|
|
78
|
+
* entry per `NODE_PATH` component, four more as this workspace exports it. That tail IS the "too wide" defect above, measured rather than
|
|
79
|
+
* argued, and it is why an unqualified "the CJS candidates are the same" is
|
|
80
|
+
* true of one enumeration and false of the other.
|
|
81
|
+
*
|
|
67
82
|
* BOUNDED BY ANCESTRY, not by a rule. `<app>/node_modules/node_modules` is a
|
|
68
83
|
* candidate because `<app>/node_modules` is an ancestor of the module dir; two
|
|
69
84
|
* levels of nesting is not a candidate, because
|
|
@@ -56,10 +56,13 @@ const IGNORE = () => { };
|
|
|
56
56
|
* mode rather than screening for it — nothing here reads the environment, so
|
|
57
57
|
* there is no list to get the screen wrong on.
|
|
58
58
|
*
|
|
59
|
-
* TOO NARROW, and this one was a SILENT MISS.
|
|
60
|
-
*
|
|
61
|
-
*
|
|
62
|
-
*
|
|
59
|
+
* TOO NARROW, and this one was a SILENT MISS. WHICH CJS ENUMERATION IS MEANT
|
|
60
|
+
* IS PART OF THE CLAIM, because the two are not the same set: the walk PROPER
|
|
61
|
+
* is `Module._nodeModulePaths`, and `require.resolve.paths` is that walk
|
|
62
|
+
* FOLLOWED BY the global folders of the paragraph above. It is the walk proper
|
|
63
|
+
* that never descends into a directory already named `node_modules`. **ESM's
|
|
64
|
+
* PACKAGE_RESOLVE has no such skip.** Measured with no `NODE_PATH` at all,
|
|
65
|
+
* from a module at `<app>/node_modules/@stonyx/x`:
|
|
63
66
|
*
|
|
64
67
|
* import.meta.resolve('stonyx') -> <app>/node_modules/node_modules/stonyx/main.js
|
|
65
68
|
* await import('stonyx') -> that copy
|
|
@@ -73,6 +76,18 @@ const IGNORE = () => { };
|
|
|
73
76
|
* written to catch it. Isolating control, moving nothing but the directory: the
|
|
74
77
|
* same core at `<app>/node_modules/@stonyx/x/node_modules/stonyx` was REFUSED.
|
|
75
78
|
*
|
|
79
|
+
* THE SET DELTA, both directions and named per enumeration — node v24.13.0,
|
|
80
|
+
* from that same module dir. Against the WALK PROPER the difference is one
|
|
81
|
+
* directory and it is one-sided: `esm \ Module._nodeModulePaths` = exactly
|
|
82
|
+
* `<app>/node_modules/node_modules` (the miss above), and
|
|
83
|
+
* `Module._nodeModulePaths \ esm` = `[]`. Against `require.resolve.paths` the
|
|
84
|
+
* second direction is NOT empty and never was: `require.resolve.paths \ esm` =
|
|
85
|
+
* the three global folders (measured here: `~/.node_modules`,
|
|
86
|
+
* `~/.node_libraries` and the node prefix, all three absent on disk) PLUS one
|
|
87
|
+
* entry per `NODE_PATH` component, four more as this workspace exports it. That tail IS the "too wide" defect above, measured rather than
|
|
88
|
+
* argued, and it is why an unqualified "the CJS candidates are the same" is
|
|
89
|
+
* true of one enumeration and false of the other.
|
|
90
|
+
*
|
|
76
91
|
* BOUNDED BY ANCESTRY, not by a rule. `<app>/node_modules/node_modules` is a
|
|
77
92
|
* candidate because `<app>/node_modules` is an ancestor of the module dir; two
|
|
78
93
|
* levels of nesting is not a candidate, because
|