Developer IDs in Ditto are unique, (typically) human-readable identifiers for various types of Ditto data, such as projects, text items, library components, folders and variants. Developer IDs serve as tve unique key for referencing each piece of Ditto data in development, as well as to retrieve desired data from the API and CLI.
Developer IDs are automatically generated for each entity during creation based on the source data at the time of creation. For instance, when a user creates a project, the project is automatically assigned a Developer ID based on the project’s name. This process is done according to the Developer ID Configuration for the workspace, which can be viewed and modified from the Developers Page in the Ditto web application.
Configuration rules
Users can control the following aspects of Developer ID generation and validation.
Allowed Characters
Users can specify exactly which characters are allowed in a Developer ID
We require that all English letters be allowed, but users can choose whether to support uppercase, lowercase or both
During generation, all accents and diacritics will be stripped from the source string, even if they are listed as allowed special characters
During generation, Non-Latin letters will be transliterated to their closest A-Z representation
This property is used for both generation and validation - manual edits containing invalid characters will be rejected
Character Replacements
Users can provide an ordered list of rules for replacing one substring with another. For example, a rule may specify that spaces should be replaced with underscores or that the word “workspace” be replaced by the abbreviation “ws”.
Each rule contains three properties: the ‘before’ value, the ‘after’ value, and a substitution method. When executing each rule, all complete matches to the ‘before’ value will be replaced with the ‘after’ value. For each rule, users can specify whether back-to-back matches are replaced one by one, or if these consecutive matches should be combined as a single substitution.
For example, for a rule that replaces periods with slashes, users can decide whether an ellipsis ... should be replaced with /// or combined into a single /. Regardless of substitution method, all periods in the string will be replaced with some number of slashes.
These rules will be applied in order during auto-generation; the second rule will be applied to the result of the first rule, and so on.
Example:
Before:
.after:!method:combineBefore:
(space)after:-method:combineBefore:
-after:_method:replace eachBefore:
developerafter:devmethod:replace each
Source: I use 10-15 developer tools every day… I am a developer.
Result: I_use_10_15_dev_tools_every_day!_I_am_a_dev!
Casing Adjustment
If a casing adjustment is specified, the source text will be modified accordingly during auto-generation. Users can choose between lowercase, UPPERCASE, camelCase, PascalCase or none. If no adjustment is specified, casing will be left alone.
Casing adjustment is only used during auto-generation, not validation. For example, if the config specifies camelCase, the string “My new project” will generate the Developer ID myNewProject but a user is free to manually change that to MYNEWPROJECT or myNEWproject.
The casing adjustment may not conflict with the allowed characters specification. Uppercase letters must be allowed in order to choose UPPERCASE, camelCase or PascalCase. Lowercase letters must be allowed in order to choose lowercase, camelCase or PascalCase.
Maximum Length
Users must specify the maximum length allowed for a Developer ID. This value will be used for both generation and validation. During auto-generation, after (almost) all other transformations have been completed, the result string will be truncated if necessary.
To ensure uniqueness, the system will automatically append a unique suffix to any potential Developer ID that would have caused a collision. This step occurs after truncation has already taken place, which means that it is possible for the final Developer ID value to be slightly longer than the maximum length.
💡 If you have a hard limit in your system, we recommend setting your config max length to 3+ characters below that limit to account for deduplication suffixes.
Generation vs. Validation
When new data is created, the system will automatically generate a Developer ID using all parts of the configuration. To preserve stable references between Ditto and your application, once a Developer ID value has been generated, Ditto will not automatically update it when the related data or config changes.
After initial creation, Developer IDs may be manually edited. Unlike generation, which includes various transformation steps, manual edits will be validated against parts of the spec and either accepted or rejected without modification.
💡 Only Allowed Characters, Maximum Length, and Uniqueness are used for validation. The rest of the config is only used for transformation during auto-generation. This allows users more fine-grained control over Developer ID values where automatic generation falls short.
Example: A team uses a naming convention such as namespace.feature.value. This team needs to allow periods in Developer IDs generally, but does not want punctuation from source text to be included in the auto-generated values. This team should include periods in Allowed Characters and then add a Character Replacement step that replaces periods with empty string. This will strip periods from all auto-generated Developer IDs while still allowing users to add period-separated prefixes to the Developer ID manually.