Possible fix for #15374 #15389
Possible fix for #15374 #15389
Conversation
nodejs-github-bot
added
the
module
guybedford
force-pushed
the
15374
branch
2 times, most recently
from
0119097
to
cc05513
Compare
|
Thanks for the fix! If you are able to write a test for it, we can run it on CI and we'll see if it works on the Windows machines. /cc @bmeck |
|
This looks correct to me
…On Sep 13, 2017 7:04 AM, "Michaël Zasso" ***@***.***> wrote:
Thanks for the fix! If you are able to write a test for it, we can run it
on CI and we'll see if it works on the Windows machines.
/cc @bmeck <https://github.com/bmeck>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#15389 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAOUo88XjVp5xIR2c9esTbfjMGzx5PYnks5sh8S3gaJpZM4PV_g3>
.
|
mscdex
added
the
esm
|
Wrt to the tests, I'm not that knowledgable on how they actually get executed at a top level to know what the exact entry point is here, and as to why they weren't failing already on windows. Any end-to-end modules test should capture this - I don't think it's a specific test case. |
|
@guybedford you are right. I just realized that es-module tests don't run on CI yet: #15276 |
|
Since this has been manually verified to work should we land once 48 hours has passed? I don't think we should block on fixing the CI for this. |
|
Landed in dce72c2 |
| @@ -435,7 +435,7 @@ Module._load = function(request, parent, isMain) { | |||
| if (experimentalModules) { | |||
| if (filename === null || /\.mjs$/.test(filename)) { | |||
There was a problem hiding this comment.
Is there a reason why regex is used here instead of filename.endsWith('.mjs')?
There was a problem hiding this comment.
Habits from before that existed. Technically we could/should not be using prototype functions since they could be tainted by preloading via --require.
There was a problem hiding this comment.
Technically we could/should not be using prototype functions since they could be tainted by preloading
There's a lot to tweak then because there's heavy use of apply, call, charAt, concat, pop, push, slice, test, and on and on. It'd be neat to see if some of this could be solved with a new context to avoid plucking all these methods off.
There was a problem hiding this comment.
@jdalton Contexts are expensive w/o snapshots to create and we would need a frozen one to avoid mutations which would mean making that custom Snapshot, we couldn't use vm.createContext due to the funky sandbox bridge it creates leaking : #6283 . I'd be open to using one if we had a snapshot, but it would still be ~10ms on my benchmarks to create a full one.
Fixes: nodejs/node#15374 PR-URL: nodejs/node#15389 Reviewed-By: Bradley Farias <bradley.meck@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com> Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com>
Fixes: nodejs/node#15374 PR-URL: nodejs/node#15389 Reviewed-By: Bradley Farias <bradley.meck@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com> Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com>
This should fix the Windows path bug with drive letters being detected as the protocol, getting modules to work on Windows properly.
I still need to actually test this out on a Windows machine (won't have access again till tomorrow) but I'm 99% sure it'll work out.
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passesAffected core subsystem(s)
esmodules