Releases: dittowords/cli
v3.4.0
v3.0.0
This v3 release focuses around a number breaking changes intended to better align default CLI behavior with Ditto best practices.
Breaking changes
Commands
Running ditto-cli
without any commands will now default to pulling text data identically to the pull
command.
Configuration
Previously, projects
and components
were separate keys that could be specified at the top-level of config.yml
; now, they should be grouped together under a required top-level sources
property:
sources:
components:
enabled: true
projects:
- name: '[Demo] New User Flow'
id: 621e71bbb7a68700da355a10
Note that sources.components
is now an object with an enabled
property; see New Features at the bottom of this release for the other property that is now supported.
The deprecated way of specifying the component library, by including ditto_component_library
as a special element in the projects
array, is no longer supported.
The CLI now defaults to the following configuration:
- Pull text from the component library
- Include variant data
- Use the
flat
JSON format
In accordance with the above, here is what an autogenerated config.yml
now looks like:
sources:
components: true
variants: true
format: flat
The previous default format (referred to as the full
format) is deprecated and is no longer supported by the CLI. If you still need access to the full
format, please reach out to us so that we can discuss your use-case.
Output Files
All files created will adhere to the following template independent of CLI configuration:
{source_name}__{variant_name}.{extension}
source_name
: the name of a project orditto_component_library
for files containing component datavariant_name
: the ID of a variant orbase
for files generated for non-variant textextension
: the file extension that corresponds to your configured format
To help with keeping cross-platform behavior consistent, file names will be fully lowercase, have whitespace replaced with hyphens, and have non-word characters (with the exception of -
and _
) removed.
If a file (e.g. for a given variant) would otherwise hold an empty object or contain no data at all, it will not be written to disk.
Previously, the index.js
driver file was always generated each time text data was pulled. Now, index.js
will only be generated when the specified format
results in outputting JSON files (at the time of writing, this means either flat
or structured
).
New features
The components
source is now an object that optionally supports specifying an array of component folders to pull text from:
sources:
components:
enabled: true
folders:
- id: folder-1
name: Folder 1
- id: folder-2
name: Folder 2
If specified, pulled component data will be restricted to components in the specified folders. If not specified, defaults to pulling data for all components in the component library.
v2.8.0
v2.5.2
v2.5.1
v2.5.0
This release creates a CLI option to pass arbitrary metadata to Ditto's backend.
The new option is -m, --meta <data...>
. Currently, only -m githubActionRequest:true
is being processed by select Ditto endpoints. This is used when the CLI is run within a GitHub workflow.
v2.5.0 does not have any other feature changes and is irrelevant for current users of the CLI.
v2.4.0
v2.3.0
2.3.0 includes the following changes:
- Allows users to override the output directory via a new environment variable (
DITTO_TEXT_DIR
)DITTO_TEXT_DIR=myfolder
- When no projects are found in the
config.yml
file an additional help message displays about verifying that the projects have developer mode enabled
v2.2.0
This release adds support for an alternative method of passing a Ditto API key to the CLI.
The CLI will now attempt to read from an environment variable called DITTO_API_KEY
prior to reading from the file stored at ~/.config/ditto
.
Option 1
# ~/.config/ditto
api.dittowords.com:
- token: >-
xxx-xxx-xxx
# command
$ ditto-cli pull
Option 2
# command
$ DITTO_API_KEY="xxx-xxx-xxx" ditto-cli pull
Both approaches will be equally maintained moving forward, as the latter is often better suited for deploying in remote environments and CI pipelines, while the former is usually the best fit for using the CLI as part of a local development process.