-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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: exports check hasOwnProperty #31427
Conversation
This comment has been minimized.
This comment has been minimized.
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.
Tried this locally and it didn't fix the issue. I've run CITGM on bluebird
with 13.6.0 (which doesn't contain #31001) and NODE_OPTIONS=--experimental-conditional-exports
and it produces the same failure: https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker-nobuild/727/
@richardlau are you 100% sure this change didn’t fix the issue? The trySelf
function should definitely be returning the early false return unless the
package.json has an exports field. I really cannot see another way the
execution paths would differ flagged versus unflagged. And yes adding the
flag would replicate the issue as you have confirmed.
…On Mon, Jan 20, 2020 at 21:12 Richard Lau ***@***.***> wrote:
***@***.**** requested changes on this pull request.
Tried this locally and it didn't fix the issue. I've run CITGM on bluebird
with 13.6.0 (which doesn't contain #31001
<#31001>) and
NODE_OPTIONS=--experimental-conditional-exports and it produces the same
failure:
https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker-nobuild/727/
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#31427?email_source=notifications&email_token=AAESFSXG2VTZXOCYNQIW65TQ6XZQRA5CNFSM4KJIT5FKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCSL47FQ#pullrequestreview-345493398>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAESFSRI4UIKEXN4TNCEZ3LQ6XZQRANCNFSM4KJIT5FA>
.
|
Yes, I just double checked. CITGM (bluebird only on our fastest platform (s390x)): https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/2231/ |
@richardlau Do you mind please providing specific steps to reproduce? |
😅 I have git clones of
|
It may be possible to reduce what
So I'm guessing that it used to "work" by falling back to the version of |
Thanks @richardlau for the replication instructions there - I managed to finally track this down and have updated the PR with the fix. Basically, for some reason, all package.json files are being detected as containing an undefined "exports" field in these cases. So shifting the check to be based on "exports" not being undefined instead of being a property fixes the issue. Tracking down why "exports" is being set as an undefined property on the internally loaded package.json objects is likely a good idea - and entirely unrelated to this PR. I'm not sure if it's due to userland code or internal code. Either way we are good to land with this fix if we can get this fast tracked now. |
Assuming @richardlau can verify that this PR fixes the issue, I propose we fast-track. |
CITGM (bluebird only): https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/2232/ |
This comment has been minimized.
This comment has been minimized.
lib/internal/modules/cjs/loader.js
Outdated
@@ -435,7 +435,7 @@ function resolveBasePath(basePath, exts, isMain, trailingSlash, request) { | |||
|
|||
function trySelf(parentPath, isMain, request) { | |||
const { data: pkg, path: basePath } = readPackageScope(parentPath) || {}; | |||
if (!pkg || 'exports' in pkg === false) return false; | |||
if (!pkg || pkg.exports === undefined) return false; |
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.
this still would pass if an inherited exports
property existed.
if (!pkg || pkg.exports === undefined) return false; | |
if (!pkg || !HasOwnProperty(pkg, 'exports')) return false; |
(also bring in HasOwnProperty
from primordials
at the top)
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.
Isn't that similar to the first commit (d3f5674) which doesn't work (pkg.exports
does exist but has an undefined
value)?
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.
in that case you'd want both checks.
Can confirm locally that this appears to fix the issue (and the results so far in https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/2232/ are in agreement). For posterity I also came to a similar discovery about With the following hacky debug (on top of d3f5674): diff --git a/lib/internal/modules/cjs/loader.js b/lib/internal/modules/cjs/loader.js
index 01d96a4..7c256e0 100644
--- a/lib/internal/modules/cjs/loader.js
+++ b/lib/internal/modules/cjs/loader.js
@@ -435,9 +435,9 @@ function resolveBasePath(basePath, exts, isMain, trailingSlash, request) {
function trySelf(parentPath, isMain, request) {
const { data: pkg, path: basePath } = readPackageScope(parentPath) || {};
- if (!pkg || 'exports' in pkg === false) return false;
+ if (!pkg || !ObjectPrototypeHasOwnProperty(pkg, 'exports')) return false;
if (typeof pkg.name !== 'string') return false;
-
+ if (pkg.name === 'bluebird') console.warn(pkg);
let expansion;
if (request === pkg.name) {
expansion = ''; I got this out of the CITGM output: warn: | {
warn: | name: 'bluebird',
warn: | main: './js/release/bluebird.js',
warn: | exports: undefined,
warn: | type: undefined
warn: | } |
What is supposed to happen if someone does |
@guybedford the reason is that |
This comment has been minimized.
This comment has been minimized.
@ljharb PTAL - do you still think this needs both checks? i'm gonna land this in a bit otherwise :) |
@codebytere if the only reason for the bug was #31427 (comment) - and if |
Would be good to see a test added for this. |
I took the liberty of adding a test. Hope that's OK. Feel free to remote it or modify it or whatever. |
This comment has been minimized.
This comment has been minimized.
I support putting this in the release rather than taking out the unflagging. But I'm fine with pulling out the unflagging and waiting until the next semver minor if you or anyone else is concerned. If it causes widespread breakage, the burden will fall to the releasers to get out a quick fix, so I'll defer to you on what the best thing to do here is. But I'm +1 on getting this into the release. |
Unflagging conditional exports is very important for ESM adoption. Many package maintainers are waiting for conditional exports before they add ESM support to their packages, especially conditional exports in LTS; so I would err on the side of keeping the unflagging if it all possible. |
@Trott We can (should?) probably cut out a lot of stuff from the two |
Agreed, that should happen (and probably rename it from something other than "bluebird") and also someone should follow up on @ljharb's observation and see if the other check is necessary or not. |
This comment has been minimized.
This comment has been minimized.
https://ci.nodejs.org/job/node-test-pull-request/28525/ is green. Landing. |
Landed in 343ddff...dcba128 |
Refs: nodejs#31001 (comment) PR-URL: nodejs#31427 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Shelley Vohr <codebytere@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
Refs: #31001 (comment) PR-URL: #31427 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Shelley Vohr <codebytere@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
9cb334a
to
dcba128
Compare
Refs: #31001 (comment) PR-URL: #31427 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Shelley Vohr <codebytere@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
Refs: #31001 (comment) PR-URL: #31427 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Shelley Vohr <codebytere@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
Thanks all for the help getting this one sorted. |
Refs: #31001 (comment) PR-URL: #31427 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Shelley Vohr <codebytere@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
Refs: #31001 (comment) PR-URL: #31427 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Shelley Vohr <codebytere@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
Refs: nodejs#31001 (comment) PR-URL: nodejs#31427 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Shelley Vohr <codebytere@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
Refs: nodejs#31001 (comment) PR-URL: nodejs#31427 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Shelley Vohr <codebytere@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
Refs: #31001 (comment) PR-URL: #31427 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Shelley Vohr <codebytere@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
Refs: #31001 (comment) PR-URL: #31427 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Shelley Vohr <codebytere@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
Refs: #31001 (comment) PR-URL: #31427 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Shelley Vohr <codebytere@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
Refs: #31001 (comment) PR-URL: #31427 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Shelley Vohr <codebytere@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
This is a possible fix for the issues discussed in #31001 (comment), ensuring a strict property check.
I suspect the bug may be prototype pollution although I haven't been able to test this. I'm 80% sure this should resolve the issue though given the information.
I haven't included a test as this is more of a correctness feature... testing object pollution sounds more like something that could be covered by some kind of general JS pollution fuzz testing approach than something to be unit tested case-by-case.
I will be away for the next 8 hours, please feel free to merge if this works, or to revert the conditional exports unflagging PR if it doesn't.
//cc @Trott @richardlau @codebytere
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes