​
Overview

The config.yml file is the source of truth for a given directory about how the CLI should fetch and store data from Ditto based on the specified properties. It includes information about which Ditto components the CLI should pull text from, the string file formats, and more. This is the default configuration file that is generated the first time that the CLI is run in a given directory: 
projects: []
variants: []
outputs:
	- format: json
		framework: i18next

​
Supported Properties

Listed below are each of the properties that you can specify in your CLI config.

​
projects: Array<{ id: DeveloperId }>

An array of developer ids of the projects to pull from. If no ids are provided, will pull from all beta projects in the workspace. See Text Items filter.projects for more details.

​
variants: Array<{ id: “all” | “base” | DeveloperId }>

An array of variants to return. By default, only base text will be returned. Provide “all” to return base and all variants. Or provide a list of the specific variant developer ids you wish to return, including in “base” in the list for the base text. See Text Items filter.variants for more details.

​
richText: “html” | false

Flag to determine if the pulled text is represented as plain text or rich text (in HTML format). Default is false.

​
outDir: string

The relative path from where the CLI is run to the directory the generated files should be created in. If the provided directory does not exist, it will be created automatically. If not provided, the default location is ./ditto.

​
outputs: Array<{ format: Format, framework: Framework, projects: Array<{ id”: DeveloperId }>, variants: Array<{ id: “all” | “base” | DeveloperId }>, outDir: string }>

An array of formats you wish to return the data in. Currently, we only support a single format, “json”. Additionally, a “framework” field can be provided to generate helper files to assist in integrating the output files into a specific framework. Right now, only “i18next” is supported for the “json” format. All top-level fields can also be defined within each provided output. Providing a value at the output level will override any fields defined at the global level. For example, if “outDir” is defined at the root of the config to be “./customPath1”, and is set to “./customPath2” within an output, the files generated by that specific output will be created within the “./customPath2” directory, while any other outputs will go to “./customPath1”. Here is a much more complex example: 
projects:
  - id: top-level
variants: []
richText: html
outDir: ./ditto/top
outputs:
  - format: json
  - format: json
    variants:
      - id: french
    outDir: ./ditto/french
  - format: json
    framework: i18next
    outDir: ./ditto/i18next
    type: module
    projects: []
    variants:
      - id: french
      - id: spanish
     - id: base
     richText: false
The config file above will work as follows:
  1. There are three outputs specified, so the query will run three times, each with different filters
  2. The first output has no special overrides, so it will create all the json files for the top-level query — just the base text from the project with developer ID “top-level”. These files will be saved to the directory ./ditto/top with rich text enabled.
  3. The second output contains some overrides. This will still filter to the “top-level” project, but will request the french variant and save its files to ./ditto/french with rich text enabled.
  4. The third output overrides all of the filters. It will query for the french, spanish and base variants from all beta projects and create the i18next driver file(s). All of these files will be saved to the ./ditto/i18next directory with rich text disabled.