vovk.config.{js,cjs,mjs}
The config file is used to define options for the CLI, update template definitions, and customize some other settings. At some cases itβs optional, since the CLI can use default options or flags, but for more advanced usage itβs recommended to create a config file.
Valid config file names
The config can be implemented either as a CJS module or as a ESM module. It supports the following extensions: .js, .cjs, .mjs and can be stored at the root of the project as well as at .configβ folder. In other words, the following paths are valid:
- vovk.config.js
- vovk.config.cjs
- vovk.config.mjs
- .config/vovk.config.js
- .config/vovk.config.cjs
- .config/vovk.config.mjs
When vovk init is executed, in order to create proper file name, it checks if the project is a module and, and if the .config folder exists.
Config Options
The config options extend VovkConfig
type from vovk
package and can be used to define the following options:
emitConfig: boolean | string[]
Indicates whether the config options should be emitted as .vovk-schema/_meta.json file. If set to true
, it will emit all options. If set to an array of strings, it will emit only the specified options. Default is ["libs"]
.
clientTemplateDefs: object
Extends the template definitions with the custom definitions that can be used as fromTemplates
field in the composed client or segmented client.
imports: object
Allows to redefine imports used by the generated client, such as fetcher, validateOnClient, and createRPC. The values are paths to the files that export the corresponding functions. Relative paths are resolved from the root of the project, package paths, such as my-lib/fetcher
, are rendered as is.
composedClient: object
Redefines config options for the composed client, such as outDir, fromTemplates, excludeSegments, etc.
segmentedClient: object
Redefines config options for the segmented client, such as outDir, fromTemplates, excludeSegments, etc.
Redefines config options for the segmented client, such as outDir, fromTemplates, excludeSegments, etc.
bundle: object
Redefines config options for the bundle, such as excludeSegments, tsdown build optionsβ, etc.
modulesDir = 'src/modules'
Indicates the directory where the module files are located. Used to generate modules with vovk new command and to watch for changes in the modules when vovk dev is running.
schemaOutDir = '.vovk-schema'
The directory where the schema is going to be generated. Defaults to .vovk-schema
.
origin = ''
The origin for the client, used to generate the client with proper URLs. Defaults to ''
, meaning that the client will use relative URLs. If you want to use absolute URLs, set it to your domain, e.g. https://example.com
.
rootEntry = 'api'
The root entry point for the API routes. By default itβs api
, meaning that the API routes will be served from /api
path and the segments (route.ts
files) are located in the ./src/app/api
folder (src/
dir is optional). If you want to serve the API from the root of the domain, set it to an empty string ''
. In this case the segments will be located in the ./src/app
folder.
rootSegmentModulesDirName = ''
Used exclusively by the vovk new command when multiple segments are used. If set to a non-empty string, the root segment modules will be created in the folder with this name. For example, if itβs set to "root"
, then when vovk new controller user
is executed, the controller will be created at src/modules/root/user/UserController.ts instead of src/modules/user/UserController.ts (the root of the modulesDir)
logLevel = 'info'
Defines the log levelβ for the CLI. The values are "debug"
, "info"
, "warn"
, "error"
. By default itβs "info"
. Set it to "debug"
to see underlying operations, such as file watching information.
prettifyClient = false
Wether the generated client code needs to be prettified. Defaults to false
. If set to true
, the client code will be formatted with Prettierβ using your local configuration. It slightly increases the compilation time.
devHttps = false
Progressive Web Appsβ require HTTPS protocol to be used both in development and production. In order to enable HTTPS in development you can use --experimental-https
flag with next dev
command and enable HTTPS mode for vovk dev by setting devHttps
to true
or providing --https
flag to the command.
const config = {
// ...
devHttps: true,
};
export default config;
If you donβt want to set the HTTPS mode enabled by default, you can create another NPM script that includes the flags:
"scripts": {
"dev-https": "vovk dev --https --next-dev -- --experimental-https",
"dev": "vovk dev --next-dev",
}
moduleTemplates: object
Record of module template names and their paths. Used by vovk new command to define the templates for the service, controller or any other kind of module. When you have configuration of state
template like this:
/** @type {import('vovk').VovkConfig} */
const config = {
// ...
moduleTemplates: {
state: './module-templates/State.js.ejs',
// you can add your own templates here
},
};
You can create a new module at modulesDir with vovk new state thing
command.
npx vovk new state thing # creates src/modules/thing/ThingState.ts file
npx vovk new state segment/thing # creates src/modules/segment/thing/ThingState.ts file
libs: object
The libs
object is a conventional way to define configuration for libraries used by the client or any other configuration that you want to expose to the client. For example, it can be used to define localization for vovk ajv.
/** @type {import('vovk').VovkConfig} */
const config = {
// ...
libs: {
/** @type {import('vovk-ajv').VovkAjvConfig} */
ajv: {
options: {
strict: false,
},
localize: 'en',
},
},
};
export default config;
If "libs"
is present at emitConfig, it will be emitted to the .vovk-schema/_meta.json
file and can be accessed multiple ways.
import { schema, UserRPC } from 'vovk-client';
console.log(schema.meta.config.libs.ajv.options.strict); // false
console.log(UserRPC.updateUser.fullSchema.meta.config.libs.ajv.localize); // 'en'
segmentConfig: object
To be documented.
openApiMixins: object
Configures OpenAPI Mixins for the client. It allows to define additional OpenAPI operations that can be used in the client. See the OpenAPI Mixins docs for more info.