DynamicExecutor runs every (or some filtered) prefixed functions in a
specific directory.
For reference, it's useful for test program development of a backend server.
Just write test functions under a directory, and just specify it.
Furthermore, if you compose e2e test programs to utilize the @nestia/sdk
generated API functions, you can take advantage of DynamicBenchmarker
at the same time.
When you want to see some utilization cases, see the below example links.
Native boundary: Discovery lists directories with readdir and stat and
joins children with path.resolve; symbolic links are followed, and each
directory is entered once by its filesystem real path so aliases and ancestor
cycles do not repeat discovery. The extension is matched as a file-name
suffix and the prefix with startsWith, both case-sensitively as spelled, so
name case is judged by the caller's spelling and not by the volume. A file is
imported through a specifier: the path relative to this module in / form
when path.relative can express one, and where it cannot, as on Windows
between drive roots, the absolute path for a CommonJS build, whose require
rejects a URL, or a file: URL from pathToFileURL for native ESM, which
rejects a Windows path.
Processing cost: Discovery visits each real directory once and performs one
metadata lookup per listed entry. A monotone queue index dispatches each
admitted module once without shifting the remaining queue; execution walks
module exports once. Storage grows with discovered directories, modules and
execution records; concurrency allocates the requested number of workers.
Reuse: Discovery and module loading are shared by the tests of one run. New
runs rediscover files; Node owns module caching, so editing an already
imported module does not promise reload in the same process.
Resource ownership: One run owns the discovered module queue, visited
directory set and report. At most the requested number of module tasks are
active, all are awaited before success or strict rejection, and returned
records transfer to the caller. Listener failure also settles workers;
cancellation and unloading Node cached modules are not provided.
contracts/common.md#principled-implementation The executor walks the location recursively, admits a file only when its basename ends with the extension and starts with the prefix and the filter accepts it, imports the admitted files, and runs every exported function whose name starts with the prefix, with at most simultaneous runs in flight; the file gate runs before the import so an excluded file is never loaded.
Evidence
contracts/common.md#clear-and-simple-design Two public entry points share one private pipeline: discovery (iterate), the import specifier (specifier), and execution (execute) are separate helpers, and the two modes differ by one flag.
Evidence
contracts/common.md#prohibited-implementation-shortcuts Selection is by prefix, extension, and the caller's filter, with no known file names; the import specifier logic distinguishes the module system in use rather than special-casing a platform.
Evidence
contracts/common.md#meaningful-documentation The namespace prose says what it runs and why, with links to example repositories, and the members document their options.
Dynamic Executor running prefixed functions.
DynamicExecutorruns every (or some filtered) prefixed functions in a specific directory.For reference, it's useful for test program development of a backend server. Just write test functions under a directory, and just specify it. Furthermore, if you compose e2e test programs to utilize the
@nestia/sdkgenerated API functions, you can take advantage of DynamicBenchmarker at the same time.When you want to see some utilization cases, see the below example links.
Native boundary: Discovery lists directories with
readdirandstatand joins children withpath.resolve; symbolic links are followed, and each directory is entered once by its filesystem real path so aliases and ancestor cycles do not repeat discovery. The extension is matched as a file-name suffix and the prefix withstartsWith, both case-sensitively as spelled, so name case is judged by the caller's spelling and not by the volume. A file is imported through a specifier: the path relative to this module in/form whenpath.relativecan express one, and where it cannot, as on Windows between drive roots, the absolute path for a CommonJS build, whoserequirerejects a URL, or afile:URL frompathToFileURLfor native ESM, which rejects a Windows path.Processing cost: Discovery visits each real directory once and performs one metadata lookup per listed entry. A monotone queue index dispatches each admitted module once without shifting the remaining queue; execution walks module exports once. Storage grows with discovered directories, modules and execution records; concurrency allocates the requested number of workers.
Reuse: Discovery and module loading are shared by the tests of one run. New runs rediscover files; Node owns module caching, so editing an already imported module does not promise reload in the same process.
Resource ownership: One run owns the discovered module queue, visited directory set and report. At most the requested number of module tasks are active, all are awaited before success or strict rejection, and returned records transfer to the caller. Listener failure also settles workers; cancellation and unloading Node cached modules are not provided.
Author
Jeongho Nam - https://github.com/samchon
Example
Example
Evidence
contracts/common.md#principled-implementation The executor walks the location recursively, admits a file only when its basename ends with the extension and starts with the prefix and the filter accepts it, imports the admitted files, and runs every exported function whose name starts with the prefix, with at most
simultaneousruns in flight; the file gate runs before the import so an excluded file is never loaded.Evidence
contracts/common.md#clear-and-simple-design Two public entry points share one private pipeline: discovery (
iterate), the import specifier (specifier), and execution (execute) are separate helpers, and the two modes differ by one flag.Evidence
contracts/common.md#prohibited-implementation-shortcuts Selection is by prefix, extension, and the caller's filter, with no known file names; the import specifier logic distinguishes the module system in use rather than special-casing a platform.
Evidence
contracts/common.md#meaningful-documentation The namespace prose says what it runs and why, with links to example repositories, and the members document their options.