Closed nicolo-ribaudo closed 2 years ago
Few clarifications needed:
importMetaHook
an ordinary object created by the engine, empty at first, and passed into the hook?__proto__
of the importMeta
object argument?null
, which is what is already happening with the host hook (so that by default import.meta
objects have a null prototype): step 4.a of https://tc39.es/ecma262/#sec-meta-properties-runtime-semantics-evaluationimport.meta
is evaluated the first time.I'm fine with this proposal.
ECMA-262 exposes two host hooks to initialize
import.meta
: HostGetImportMetaProperties and HostFinalizeImportMeta.HostGetImportMetaProperties
doesn't receives any parameter and returns a list of properties, that ECMA-262 will copy on theimport.meta
objectHostFinalizeImportMeta
receives theimport.meta
object, and can modify it as it wantsThe second host hook is enough to cover all the use cases of the first hook, but not the other way around.
This proposal currently implements
HostGetImportMetaProperties
: theimportMeta
parameter of theModule
constructor is equivalent to the list of properties returned by the hook. However, this is not enough to replicate the behavior of the various hosts:import.meta
object (source: "XS is freezing import.meta today" in https://github.com/tc39/notes/blob/167155eeb708d84e1758d99c88b15670f9b81f75/meetings/2020-03/march-31.md#importmeta-for-stage-4)import.meta
(source: runconsole.log(Object.getPrototypeOf(import.meta));
in Bun)With
importMetaHook
, both behaviors would be possible:This has the same serializability implications of
importHook
: modules with a non-defaultimportMetaHook
would not be serializable.