module: ESM main top-level load handling #16147

guybedford · 2017-10-11T14:34:19Z

This is an update to the top-level loading for ES module loading based on the latest master, including the fix and test (working async version) from #15736 by @targos.

Firstly we ensure that all resolver errors of code ENOENT are reported as MODULE_NOT_FOUND errors, and secondly, we can now delegate entirely to the ES module loader for resolution as it will internally delegate to the CommonJS loader based on extension rules so we can simplify the top-level logic quite nicely.

Checklist

make -j4 test (UNIX), or vcbuild test (Windows) passes
tests and/or benchmarks are included
commit message follows commit guidelines

Affected core subsystem(s)

esmodules

hiroppy · 2017-10-11T15:04:09Z

lib/module.js

  }
+
+  var filename = Module._resolveFilename(request, parent, isMain);


Why do you use var?

To match the code beneath it goes with - this is just moving the existing line from https://github.com/nodejs/node/pull/16147/files#diff-d1234a869b3d648ebfcdce5a76747d71L424. Although it could be refactored in the process certainly.

Jessidhia · 2017-10-12T01:15:36Z

lib/internal/loader/ModuleRequest.js

+  try {
+    if (!preserveSymlinks) {
+      let real;
+      real = realpathSync(internalURLModule.getPathFromURL(url), {


Why did this change to let real instead of staying const real? It's still only assigned once during its lifetime.

Jessidhia · 2017-10-12T01:18:59Z

lib/internal/loader/ModuleRequest.js

+  catch (e) {
+    if (e && e.code === 'ENOENT') {
+      e = new Error(`Cannot find module '${specifier}'`);
+      e.code = 'MODULE_NOT_FOUND';


Is Error the correct class, or is there a more precise subclass with a code?

I've adjusted this to amend the code to the error thrown from C++. If there is a better way to throw the error with the right code in C++ let me know, but I wasn't able to find existing examples for this pattern.

cjihrig · 2017-10-15T19:18:54Z

test/parallel/test-module-main-fail.js

+const assert = require('assert');
+const child_process = require('child_process');
+const { promisify } = require('util');
+const execFile = promisify(child_process.execFile);


Can you just use execFileSync() if it gets the job done. I think it would simplify the test.

cjihrig · 2017-10-15T19:19:18Z

test/parallel/test-module-main-preserve-symlinks-fail.js

+const assert = require('assert');
+const child_process = require('child_process');
+const { promisify } = require('util');
+const execFile = promisify(child_process.execFile);


Same comment here.

guybedford · 2017-10-16T11:10:07Z

@cjihrig thanks for review - that update is just pending merge of #16060 it seems. As soon as that is in I will update this PR.

This simplifies the top-level load when ES modules are enabled as we can entirely delegate the module resolver, which will hand over to CommonJS where appropriate. All not found errors are made consistent to throw during resolve and have the MODULE_NOT_FOUND code. Includes the test case from nodejs#15736

guybedford · 2017-10-18T10:49:43Z

I've updated this PR to use the sync tests, while working around the issue in #16060.

Would be nice to get these fixes into the current release cycle if possible, but I understand if the timeline for that has passed already.

targos · 2017-10-21T06:21:02Z

CI: https://ci.nodejs.org/job/node-test-pull-request/10885/

targos · 2017-10-21T17:41:00Z

I'm fixing the linting errors and landing.

This simplifies the top-level load when ES modules are enabled as we can entirely delegate the module resolver, which will hand over to CommonJS where appropriate. All not found errors are made consistent to throw during resolve and have the MODULE_NOT_FOUND code. Includes the test case from #15736. Fixes: #15732 PR-URL: #16147 Reviewed-By: Franziska Hinkelmann <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Colin Ihrig <[email protected]>

targos · 2017-10-21T17:57:05Z

Landed in fe4675b

This simplifies the top-level load when ES modules are enabled as we can entirely delegate the module resolver, which will hand over to CommonJS where appropriate. All not found errors are made consistent to throw during resolve and have the MODULE_NOT_FOUND code. Includes the test case from #15736. Fixes: #15732 PR-URL: #16147 Reviewed-By: Franziska Hinkelmann <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Colin Ihrig <[email protected]>

This simplifies the top-level load when ES modules are enabled as we can entirely delegate the module resolver, which will hand over to CommonJS where appropriate. All not found errors are made consistent to throw during resolve and have the MODULE_NOT_FOUND code. Includes the test case from nodejs/node#15736. Fixes: nodejs/node#15732 PR-URL: nodejs/node#16147 Reviewed-By: Franziska Hinkelmann <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Colin Ihrig <[email protected]>

nodejs-github-bot added the module Issues and PRs related to the module subsystem. label Oct 11, 2017

guybedford changed the title ~~module: ESM main handling~~ module: ESM main top-level load handling Oct 11, 2017

guybedford force-pushed the esm-main-handling branch from 8a243eb to 4e3bae0 Compare October 11, 2017 14:50

hiroppy reviewed Oct 11, 2017

View reviewed changes

mscdex added the esm Issues and PRs related to the ECMAScript Modules implementation. label Oct 11, 2017

Jessidhia reviewed Oct 12, 2017

View reviewed changes

guybedford force-pushed the esm-main-handling branch 2 times, most recently from 7b40f86 to 3c36790 Compare October 12, 2017 12:00

fhinkel approved these changes Oct 12, 2017

View reviewed changes

cjihrig reviewed Oct 15, 2017

View reviewed changes

cjihrig mentioned this pull request Oct 15, 2017

module: fix regression in main ESM loading #15736

Closed

3 tasks

jasnell approved these changes Oct 15, 2017

View reviewed changes

guybedford force-pushed the esm-main-handling branch from 3c36790 to 23381c7 Compare October 18, 2017 10:49

targos approved these changes Oct 21, 2017

View reviewed changes

cjihrig approved these changes Oct 21, 2017

View reviewed changes

targos closed this Oct 21, 2017

MylesBorins added the dont-land-on-v6.x label Nov 16, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

module: ESM main top-level load handling #16147

module: ESM main top-level load handling #16147

guybedford commented Oct 11, 2017 •

edited

Loading

hiroppy Oct 11, 2017

guybedford Oct 11, 2017

Jessidhia Oct 12, 2017

Jessidhia Oct 12, 2017

guybedford Oct 12, 2017

cjihrig Oct 15, 2017

cjihrig Oct 15, 2017

guybedford commented Oct 16, 2017

guybedford commented Oct 18, 2017

targos commented Oct 21, 2017

targos commented Oct 21, 2017

targos commented Oct 21, 2017

		}

		var filename = Module._resolveFilename(request, parent, isMain);

module: ESM main top-level load handling #16147

module: ESM main top-level load handling #16147

Conversation

guybedford commented Oct 11, 2017 • edited Loading

Checklist

Affected core subsystem(s)

hiroppy Oct 11, 2017

Choose a reason for hiding this comment

guybedford Oct 11, 2017

Choose a reason for hiding this comment

Jessidhia Oct 12, 2017

Choose a reason for hiding this comment

Jessidhia Oct 12, 2017

Choose a reason for hiding this comment

guybedford Oct 12, 2017

Choose a reason for hiding this comment

cjihrig Oct 15, 2017

Choose a reason for hiding this comment

cjihrig Oct 15, 2017

Choose a reason for hiding this comment

guybedford commented Oct 16, 2017

guybedford commented Oct 18, 2017

targos commented Oct 21, 2017

targos commented Oct 21, 2017

targos commented Oct 21, 2017

guybedford commented Oct 11, 2017 •

edited

Loading