Modules and application composition

Two different module concepts exist in the repository. Only the public DI metadata decorator is a runtime API from the root entry point.

Public module metadata

import 'reflect-metadata';
import assert from 'node:assert/strict';
import {
  Container, Injectable, Module, getModuleMetadata,
} from '@tagna/udiot';

@Injectable()
class MessageService {
  message() { return 'ready'; }
}
@Module({ providers: [MessageService], exports: [MessageService] })
class MessageModule {}

const metadata = getModuleMetadata(MessageModule);
assert.equal(metadata?.providers?.[0], MessageService);
const container = new Container();
container.registerMany(metadata?.providers ?? []);
assert.equal(container.resolve<MessageService>(MessageService).message(), 'ready');

Options are imports, providers, controllers, components and exports. The decorator stores metadata; applications must decide how to register providers, mount controllers and manage lifecycle. It does not accept the internal registry's name, version or dependencies fields as a public bootstrap contract.

Internal module runtime

ModuleRegistry, ModuleLoader, getModuleRegistry, getModuleLoader and related root declarations are type-only exports. Do not call them or expect automatic graph loading from an npm root import. Historical framework-development plans describe internal module machinery, not an additional consumer runtime entry point.

For application HTTP composition use server adapters or web apps; for DI use providers.