2

After dynamically loading a module, i.e. after the corresponding promise has been resolved, one can act with a function or lambda-expression on the result. I was surprised to find that the module-instance (provided by the promise) does not have a prototype:

import("./module.js").then(x => {
    console.log(typeof x); // yields 'object' as expected
    console.log(x instanceof Object); // yields false !!
    console.log(x.__proto__); // yields undefined !!
    console.log(Object.getPrototypeOf(x)); // yields null !!

    // but one can certainly access exported variables / functions
    x.exportedFunction();
})

Apparently, in spite of being an 'object', x does not seem to be an Object instance and does not seem to have any prototype at all. I wasn't aware that this is even possible. Firefox/Chrome and Safari all gave the same output (the one I spelled out in the code-comments). Is there an explanation? Is this specified anywhere? What kind of object is this module x?

Note: I'm not familiar with typescript, so I'm not sure if my question could be considered a duplicate of this one

Edit: I just realized that one obtains the same weird pseudo-object for statically imported modules into a namespace or module object via import * as x from "./module.js". Although MDN mentions these objects they don't elaborate on what they are.

Sebastian
  • 365
  • 3
  • 17
  • It seems that my confusion stems from my lack of understanding of the start of the prototype chain. I had assumed it starts with Object.prototype . But I've learned in the meantime, that there are more objects without prototype. In particular `Object.prototype.__proto__==null`and is therefore itself not an instance of `Object`. Also every Object created with `Object.create(null)` behaves the same as the module-object of my question. This is discussed in more length here: https://stackoverflow.com/questions/36692927/what-is-the-end-of-prototype-chain-in-javascript-null-or-object-prototype – Sebastian May 07 '22 at 22:03

1 Answers1

1

There is a whole range of so called exotic objects, which deviate from ordinary objects. The type of an imported ES6-Module instance is one of these, the Module Namespace Exotic Object:

An object is a module namespace exotic object if its [[GetPrototypeOf]], [[SetPrototypeOf]], [[IsExtensible]], [[PreventExtensions]], [[GetOwnProperty]], [[DefineOwnProperty]], [[HasProperty]], [[Get]], [[Set]], [[Delete]], and [[OwnPropertyKeys]] internal methods use the definitions in this section, and its other essential internal methods use the definitions found in 10.1. These methods are installed by ModuleNamespaceCreate.

Why do x instanceof Object, x.__proto__, Object.getPrototypeOf(x) behave so weird? Let's look at the object's internal method that is involved here:

GetPrototypeOf

The [[GetPrototypeOf]] internal method of a module namespace exotic object takes no arguments and returns a normal completion containing null. It performs the following steps when called:

1. Return null.

How are such objects created? There's a special method for that:

ModuleNamespaceCreate ( module, exports )

The abstract operation ModuleNamespaceCreate takes arguments module (a Module Record) and exports (a List of Strings) and returns a module namespace exotic object. It is used to specify the creation of new module namespace exotic objects. It performs the following steps when called:

1. Assert: module.[[Namespace]] is empty.
2. Let internalSlotsList be the internal slots listed in Table 35.
3. Let M be MakeBasicObject(internalSlotsList).
4. Set M's essential internal methods to the definitions specified in 10.4.6.
5. Set M.[[Module]] to module.
6. Let sortedExports be a List whose elements are the elements of exports ordered as if an Array of the same values had been sorted using %Array.prototype.sort% using undefined as comparefn.
7. Set M.[[Exports]] to sortedExports.
8. Create own properties of M corresponding to the definitions in 28.3.
9. Set module.[[Namespace]] to M.
10. Return M.
cachius
  • 1,743
  • 1
  • 8
  • 21
  • 1
    Thanks for your detailed, very helpful and fast answer! Just a tiny addendum: The specs you linked also contain another section about module-namespace https://tc39.es/ecma262/#sec-module-namespace-objects It mostly refers to the one you're citing, but also adds the following information: _The initial value of the @@toStringTag property is the String value "Module"._ So if my namespace is `x`, one has `x[Symbol.toStringTag]=="Module"`, which seems an easy way to test, if an object is a module namespace. – Sebastian May 08 '22 at 06:30