Interface INestiaConfig

Whether to assert parameter types or not.

If true, HTTP path, query and body arguments are checked through typia.assert<T>() function. The connection, connection headers, WebSocket and MCP arguments are outside this option.

This option would make your SDK library compilation time a little bit slower, but would enahcne the type safety even in the runtime level.

Whether to clone DTO structures or not.

If enabled, named DTOs reachable from analyzed routes are emitted into structures, with anonymous forms written inline. HTTP and MCP DTOs use their wire metadata; supported WebSocket declarations are copied from local sources, while external or unsupported imports retain source links.

Target directory that SDK distribution files would be placed in.

If you configure this property and runs npx nestia sdk command, distribution environments for the SDK library would be generated.

After the SDK library generation, move to the distribute directory, and runs npm publish command, then you can share SDK library with other client (frontend) developers.

Recommend to use "packages/api" value.

Target directory that e2e test functions would be placed in.

If you configure this property and runs npx nestia e2e command, @nestia/sdk will analyze your NestJS backend server code, and generates e2e test functions for the analyzed HTTP endpoints. WebSocket and MCP operations have no generated HTTP test function.

If not configured, you can't run npx nestia e2e command.

Accessor of controller classes.

You can specify target controller classes within two ways.

• Asynchronous function returning INestApplication instance
• Specify the path or directory of controller class files

Generates specialized JSON serialization for JSON and encrypted request bodies.

When enabled, the SDK emits a typia.json.assertStringify function for the body type. With assert enabled, argument validation runs separately and serialization uses typia.json.stringify without repeating the assertion. Compilation and runtime costs depend on the body type and workload.

Groups HTTP and WebSocket SDK call arguments in one props object after the connection. MCP wrappers retain their client and arguments parameters.

Response directory that SDK would be placed in.

If not configured, you can't build the SDK library.

Whether to wrap DTO by primitive type.

Unless false, source DTO aliases use Primitive for JSON bodies and responses, and Resolved for query, headers and other resolved wire forms. Clone mode writes the analyzed metadata directly; multipart bodies use FormDataInput and binary responses use ReadableStream.

For refenrece, if a DTO type be capsuled by the Primitive type, all of methods in the DTO type would be automatically erased. Also, if the DTO has a toJSON() method, the DTO type would be automatically converted to return type of the toJSON() method.

Whether to use propagation mode or not.

If being configured, interaction functions of the SDK library would perform propagation mode. HTTP failure statuses are returned through the IPropagation typed instance, which can specify its body type through discriminated union determined by status code. Transport, decoding and configured assertion failures can still throw.

Allow simulation mode for HTTP SDK calls.

If you configure this property to be true, the SDK library would be contain simulation mode. In the simulation mode, the SDK library would not communicate with the real backend server, but just returns random mock-up data with requestion data validation.

For reference, random mock-up data would be generated by typia.random<T>() function.

Building swagger.json is also possible.

If not specified, you can't build the swagger.json.