Unexpected early exit (code 13) when trying to import {} from a dynamic import() #44601

Activity

1. VoltrexKeyva

   added

   loadersIssues and PRs related to ES module loaders.Issues and PRs related to ES module loaders.

   on Sep 11, 2022
2. aduh95 commented on Sep 12, 2022

   

   aduh95

   on Sep 12, 2022

   Contributor

   More actions

   // server.js
   
   import * as path from "path";
   import * as url from "url";
   
   const __filename = url.fileURLToPath(import.meta.url);
   const __dirname = path.dirname(__filename);
   
   export const BASE_URL = new URL("http://localhost:8080");
   
   const exports = await import(url.pathToFileURL(path.join(__dirname, "index.js")).toString());
   
   console.log(exports); // <-- we never get here

   FWIW this can be simplified to:

   // server.js
   
   export const BASE_URL = new URL("http://localhost:8080");
   
   const exports = await import(new URL("./index.js", import.meta.url));
   
   console.log(exports); // <-- we never get here

   What is the expected behavior?

   The BASE_URL gets console.logd.

   What do you see instead?

   Unexpected early exit (code 13) on the dynamic import().

   To me that seems like the expected behavior, code 13 means unfinished top-level await (see https://nodejs.org/api/process.html#exit-codes). Because index.js depends on server.js and server.js execution is "blocked" by the top-level await, you end up in a soft lock and the import() promise never settles. See https://tc39.es/ecma262/#sec-example-cyclic-module-record-graphs for more information on this, but AFAIU Node.js follows the ECMAScript spec here.
3. climba03003 commented on Sep 14, 2022

   

   climba03003

   on Sep 14, 2022

   Contributor

   More actions

   I see your original issue.

   I believe the code won't works because you are trying to transit from CJS to ESM in TypeScript?
   The same code will works in CJS but not ESM.
4. Jamesernator commented on Sep 20, 2022

   

   Jamesernator

   on Sep 20, 2022

   Last edited by Jamesernator

   More actions

   Because index.js depends on server.js and server.js execution is "blocked" by the top-level await, you end up in a soft lock and the import() promise never settles.

   Yes, if you have a cycle you shouldn't use dynamic import at the top level to load the other module. In general you can just use a top-level import and things won't deadlock:

   // index.js
   import { BASE_URL } from "./server.js";
   
   // ...etc

   // server.js
   import * as path from "path";
   import * as url from "url";
   import * as exports from "./index.js";
   
   // ...etc

   The reason static import works (and CJS equivalent for that matter) is that static import is allowed to return a namespace that isn't fully evaluated. i.e. You can get exports BEFORE the module you're importing from has evaluated:

   // a.js
   import * as modB from "./b.js";
   
   console.log("Executing a.js");
   console.log(modB);
   
   export const a = "a";

   // b.js
   import { a } from "./a.js";
   
   console.log("Executing b.js");
   console.log(modA);
   
   export const b = "b";

   And so if you run it, this happens:

   > node a.js
   Executing b.js
   [Module: null prototype] { a: <uninitialized> }
   Executing a.js
   [Module: null prototype] { b: 'b' }
   

   Notice that modA has a being <uninitialized>, that's because a.js hasn't run yet so const a = "a"; hasn't set a to a value yet.

   Dynamic import is different from static import in that it only ever returns fully initialized modules, so it can't return early with a partially initialized module. i.e. This isn't allowed to print [Module ...] { a: <uninitialized> } because import() always returns fully initialized modules.

   const modA = await import("./a.js");
   console.log(modA);

   In principle dynamic import() could have returned partially initialized modules, however the TC39 decided against it as it would mean import() would behave differently in some circumstances, and static import already exists to allow partially initialized circular modules anyway.

   👍React with 👍3Reacted by Brian Jenkins, zhibirc and Bryan Lee
5. dario-piotrowicz commented on Feb 2, 2025

   

   dario-piotrowicz

   on Feb 2, 2025

   Member

   More actions

   Based on @aduh95 and @Jamesernator comments I agree that this looks like the correct behavior

   Based on that, is this issue still relevant? or should it be closed? (I don't think there's any actionable item here?)
6. joyeecheung commented on Feb 4, 2025

   

   joyeecheung

   on Feb 4, 2025

   Last edited by joyeecheung

   Member

   More actions

   As explained already, top-level await on a dynamic import that involves circular dependency would lead to deadlock in the JS execution, and in Node.js since the process is only kept alive by I/O (or, active handles in the event loop), not by pending tasks, a deadlock purely on the JS side would just leave the event loop clear of any active handles, therefore Node.js would just exit without executing any code following the problematic top-level await (in browsers, where there is not a concept of "exit on completion", the deadlock would just prevent any code below the problematic top-level await from ever executing, until it's signaled to exit when you e.g. close the tab, and still won't execute those code). This is exactly why the exit code 13 was invented to warn about this case. So it's not a bug but a known limitation.

   👍React with 👍1Reacted by Dario Piotrowicz
7. joyeecheung

   closed this as not plannedon Feb 4, 2025