Automatic lazy loading of JS type definition modules from frontend

[benStre]

Currently, when a DATEX value with a corresponding JS module (e.g. containing a @sync class) ist sent from the backend to the frontend, the JS module url is automatically appended to the DATEX request so that the JS type class is initialized on the frontend.

This does currently not work when a DATEX value that requires a JS sync class module is sent from the frontend to the backend.

If we have a module like this on the backend, and MySyncClass is not used anywhere else in the backend, it will never be initialized at runtime because it is only regarded as a TypeScript type definition:

// file: backend/do-something.ts
import { MySyncClass } from "common/sync-class.ts";

export function doSomething(syncClass: MySyncClass) {
    // ...
}

When the function is now called from the frontend with an instance of MySyncClass, we get a warning on the backend:

Cannot find type definition for \<MySyncClass>

This can only be prevented if the frontend also sends the corresponding JS module URL to the backend together with the instance. This is currently explicitly disabled for the following reasons:

• The module URL cannot be a full URL, e.g. http://localhost/@uix/src/common/sync-class.ts, because the backend itself does not import modules from http, but as local files. Instead of a module URL, we would need to provide an import identifier, e.g. common/sync-class.ts. This is possible in theory, but we have to assume that the backend endpoint has a matching import map that can resolve the import identifier. This is true for normal UIX backends, but not for endpoints in general.
• Severe security issues: By allowing arbitrary JS modules to be loaded on the backend when a frontend endpoint sends a DATEX request, we provide the possibility for arbitrary remote code execution (see https://github.com/unyt-org/datex-core-js-legacy/issues/27). We cannot add all frontend endpoints as trusted endpoints in the backend, but rather need to decide for each module if it can be imported on the backend: Only modules that are located in a common repository should be allowed to be loaded. This is still not perfect because a frontend endpoint can force the initialization of any common module on the backend endpoint that might have unintended side effects.

[benStre]

Current workaround:

import { MySyncClass } from "common/sync-class.ts";
import "common/sync-class.ts"; // <- add this import