Execution order of imports in deno is unclear/unexpected

[shivam-tripathi]

Is order of imports not guaranteed in deno?

I have a file called main.ts:

import "reflect-metadata";
import { Container } from 'inversify';
import Config from "/utils/config.ts";

export default function getContainer() {
	const container = new Container();
	container.bind('CONFIG').to(Config).inSingletonScope();
        return container;
}

const container = getContainer();
console.log(container.get<Config>('CONFIG'));

And corresponding config.ts

import { injectable } from 'inversify';

@injectable()
export default class Config {
	port: number = 8080;
}

When I run this, I keep running into

error: Uncaught TypeError: Reflect.hasOwnMetadata is not a function
    at https://cdn.esm.sh/v65/inversify@6.0.1/deno/inversify.js:8:43608
    at __decorate (file:///Users/shivamtripathi/code/apps/utils/config.ts:4:95)
    at file:///Users/shivamtripathi/code/apps/utils/config.ts:8:28

I was expecting reflect-metadata to get executed before all other modules (including dependencies imported from remote urls in this case inversify). Is this error expected?

import map:

{
	"imports": {
		"./": "./",
		"/": "./",
		"reflect-metadata": "https://cdn.esm.sh/reflect-metadata?deno",
		"inversify": "https://cdn.esm.sh/inversify?deno"
	}
}

  deno --version
deno 1.20.2 (release, x86_64-apple-darwin)
v8 10.0.139.6
typescript 4.6.2

[nayeemrmn]

It is intended, this occurs because import "reflect-metadata" has a dependency that uses top-level-await so it will complete after its synchronous siblings. You can confirm this by running:

import "data:application/javascript,import 'https://cdn.esm.sh/reflect-metadata?deno'; console.log(1)";
import "data:application/javascript,console.log(2)";

and observing that 2 is printed before 1 which it wouldn't be for a sync module. The TLA is probably somewhere in std/node.

The only way to ensure Reflect.hasOwnMetadata() is defined where it's needed is having import "reflect-metadata" at the top of config.ts and any other module which uses it at the top-level.

[shivam-tripathi]

Thanks @nayeemrmn, that makes sense. I do however feel that if std/node is indeed altering import behavior (than what is standard), it may lead to a number of cases where even with the compat mode libraries can start randomly failing. I think this definitely can be a big issue down the line.

[nayeemrmn]

@shivam-tripathi Should be fixed next std release