Support for ES Modules

[thebuilder]

Hi, and thanks for a really awesome library - Really helps bridge the gap between Node and .NET.

Is it possible to add support for ES Modules/.mjs files?

Currently, trying to execute code in .mjs files fail, with:

Error [ERR_REQUIRE_ESM]: require() of ES Module .../server/entry-server.mjs not supported.

It's executed using:

await _nodeJsService.InvokeFromFileAsync<string>("../server/entry-server.mjs", "renderHead");

The whole Node system is slowly moving toward ES modules as the standard. In our case we're using Vite to bundle our server code, and it will by default output an .mjs file.

[JeremyTCD]

Apologies for the slow response. I've added support for .mjs files when using InvokeFromFileAsync/InvokeFromFileAsync<T>.

Word of caution - use of .mjs files is flaky with older versions of Node.js (tried with 18.12.1 and 18.13.0). These Node.js versions randomly crash when the dynamic import is attempted (import(<mjs path>)), without throwing any errors. No issues with 19.4.0 though.

I will be releasing a version of the library with the addition some time this week.

Edit: crashing is not an issue if you are consuming this library as a Nuget package. See #151 (comment).

[thebuilder]

Amazing! Have you also experienced that crash issue when pointing to the .mjs file in the InvokeFromFileAsync call? Or is it if one .mjs imports another?

[JeremyTCD]

TL;DR

The crashing was occurring for InvokeFromFileAsync calls.

After some investigation, it turns out the crashing is not an issue if you are consuming this library as a Nuget package!

Details

Some background on how this library works - it starts a HTTP server in Node.js (server logic). It uses HTTP requests to send JS invocations to the Node.js process. When you call InvokeFromFileAsync, it tells the Node.js server to use a dynamic import to load your file (line here).

This library uses webpack to create a single server logic file. The crashing only occurs when the server logic is web-packed in development mode. In that mode, webpack uses eval to execute the server logic. Turns out there is a Node.js issue of segmentation faults (pre 19.0.0) when using dynamic imports in evaluated code.

The server logic is web-packed in development mode when the library is built in Debug mode. So if you clone this library and run tests in Debug mode (which is what I was doing), tests invoking from .mjs files will randomly fail.

When the server logic is web-packed in production mode, eval is not used and so the crashing does not occur. For end-users consuming this library as a Nuget package, crashing is not an issue because the server logic is web-packed in production mode for the Nuget package.