Get at module export table in native code

[fatcerberus]

There doesn't seem to be a way to get at the exports of a module in native code. I'm trying to implement a system where my engine calls an export default function in the root module, but I haven't found a way of accessing the exports. JsModuleEvaluation(moduleRecord, &result); usually just returns undefined for the result.

[fatcerberus]

I note also that this limitation prevents me from having require() interoperate with ES modules.

[liminzhu]

There isn't a way to do that today. I'm curious what you intend to do for require.

[fatcerberus]

I'm in the process of migrating my miniSphere game engine from Duktape to ChakraCore. Natively, Duktape only fully supports ES5 with a very limited subset of ES6. Because I broadly support ES6 including modules, Babel was an integral part of my toolchain for some time. Unfortunately, Babel transpiles imports to requires, and this plays havoc now that I'm converting my standard library to real ES modules.

I would like to maintain backward compatibility with already-Babelized code if at all possible--without actually using Babel--which leaves me with two options:

• Leave my standard library in CommonJS format. This is not ideal, as I can't then use them via import. (CJS is dynamic, ESM is static)
• Come up with a way to allow require() to load the the standard library anyway despite being ESM.

I should note that I've already accomplished the latter by injecting the following shim when a require() requests an ES module: Rather than giving the CommonJS source directly to the module loader (which obviously wouldn't work) I instead send this...

import * as Module from "<specifier>"
global.___exports = Module;

Then I can simply return the value of ___exports from require(). A bit hacky, but it works. However, it would be better if the ChakraCore API could allow this directly and avoid the fake module shim.

[fatcerberus]

As far as natively module-based codebases go, without regard for require(): When I was using Babel I was able to have a "main class" exported from the root module that the engine could call on startup, similar to how C# calls Program.Main. Like so:

export default
class Game
{
    start() {
        // initialization
    }
}

With Babel that worked because the module was translated to a CommonJS module, where the class is readily available through the return value of require(). The only way I could maintain compatibility here was to use the above-mentioned shim.

[liminzhu]

+@digitalinfinity

This is very interesting. For us we need to think about how to implement ESM/CJS interop in NodeChakraCore so there will be some changes that can solve the problem you described.

[fatcerberus]

Yep, the module implementation will get lots of smoke testing from me because I went all-in with supporting them. :)

By the way does ChakraCore support import()?

[liminzhu]

Yep, dynamic import is in v1.6.0+.

[Oceanswave]

A little confused about this myself.

#3255 seems to have removed returns at the top level (throws on parse module), but at the same time JsModuleEvaluation seems to indicate that it should provide a return value.

However, the return value seems to always be undefined -- even with a export default as @fatcerberus indicates.

is there a mechanism to get a returned or exported value from the top level module?

[fatcerberus]

@Oceanswave A hardcoded return value of undefined is correct according to the current specification:
https://tc39.github.io/ecma262/#sec-moduleevaluation

So this would need a new API if such a feature is implemented. A workaround that will work right now is do what I do in miniSphere, instead of evaluating your top-level module directly, you evaluate a shim like this:

import * as Module from "<top-level specifier>"
let global = (new Function('return this;'))();
global.$EXPORTS = Module;

And then you can just read back $EXPORTS to see everything your main module exports.

[boingoing]

So looks like what we want here is a way to fetch the exports of a module from native-side, perhaps only the default export or module namespace object? Something like:

CHAKRA_API
JsGetModuleExport(
    _In_ JsModuleRecord requestModule,
    _In_ JsPropertyIdRef propertyId,
    _Outptr_result_maybenull_ JsValueRef* value);

or

CHAKRA_API
JsGetModuleNamespaceObject(
    _In_ JsModuleRecord requestModule,
    _Outptr_result_maybenull_ JsValueRef* value);

or

CHAKRA_API
JsGetModuleDefaultExport(
    _In_ JsModuleRecord requestModule,
    _Outptr_result_maybenull_ JsValueRef* value);

Does that sound right? Any preference among those options?

[Oceanswave]

@fatcerberus -- thanks for the pointer!

@boingoing -- would be an improvement to have the ability to do that rather than mutate the global object. I like the first option the most but a combo of the first and last would be fine too. Having access to the module namespace would potentially provide more flexibility, but personally not needing that right now.

[fatcerberus]

@boingoing My preference is for option 2, just for the sake of future-proofing. Option 3 would be nice to have too, but I’d consider that an auxiliary helper function rather than the primary API.

[rhuanjl]

@boingoing I’d be interested in making a PR to add one of those APIs if this would be appreciated, probably option 2 to be the most flexible, or a hybrid one that can do any of the 3 with an enumeration parameter thoughts?