[RichardHoekstra]

Problem

Importing @webhare/wrd eagerly loads YAML validation and its generator dependency graph even when no YAML import is performed. Fresh native CallAsync runners also pay this startup cost.

Change

Load TrackedYAML inside the asynchronous importIntoWRDSchema helper through the existing CommonJS module-alias resolver. The public API stays unchanged.

Validation

• wrd.nodejs.test_wrd_startup: fails before, passes after. Checks the import graph and valid/invalid YAML handling.
• Existing WRD import/export tests, TypeScript compilation and unchanged ESLint checks pass.

Validated on the official 6.2 image for GitHub main a91a7a28, with the candidate sources installed. Full upstream CI has not been run.

[unilynx]

I'd rather not going down this route, before we know it hundreds of static imports have been rewritten to dynamic requires.

CallAsync is just very slow - I've measured nodejs process creation and basics imports itself already easily at 500ms, and even that 500ms is already unacceptable for a lot of situations. You're not going to get it to eg. 50ms where it's slowly getting reasonable to use in eg a dynamic page rendering. And even after startup things are slower than any other route, as you're not sharing any caches, whmanager or database connections which any other code.

I wouldn't use CallAsync/ImportJS anywhere a 500ms wait is not acceptable, so that basically leaves only background jobs and as a 'sidecar' to a Tollium application - where you just importjs once and reuse it running process for a long time. (and even there - switch to engine=wasm as soon as it's stable enough)

CallJS and backendServices have the advantage of using an already existing process. Don't use CallAsync where performance matters. Preferably don't use it anymore at all :-)