Commands for the database, settings and translations

These commands change what sits beside your code: the database's migrations, your local settings, and the wording of your app in each language.

jadpo migrate

new writes the next migration, or finishes the latest once its decisions are written (Migrations). apply and status take the database's URL with --url, and --store when there are several. Otherwise they read it from the connection's setting, in the environment and then .env.local.

A missing purpose will be asked for at a prompt, as the CLI design language draws it, once prompts are built. Until then the command names a purpose to use.

jadpo config move

jadpo config move <constant> turns a constant into a setting: a config field of its name and type, with its value as default:. It deletes the constant and rewrites every read to config.<name> (Making a constant a setting).

Name the constant as code reads it (security.max_login_attempts), or after its domain. It lists what changed, file by file, then the setting and its variable. It refuses with configuration.move_type_unsupported, configuration.move_name_taken and configuration.move_read_unsupported, every reason at once, and changes nothing. A move whose result wouldn't check is undone. It takes --json.

jadpo config set and jadpo config check

check lists each setting as set, default, missing or invalid, with its variable, against the environment and then .env.local. It reports each problem as configuration.value_missing or configuration.value_invalid and never prints a value. It takes --json.

set asks for one value at a prompt, hidden for a secret, so the value never goes on the command line. It refuses --json and a missing terminal. It checks the value against the setting's type, then writes .env.local: only as an ordinary file, through a private temporary file, and only if the file hasn't changed since it was read. It adds .env.local to .gitignore.

jadpo translations

Each of these takes --json (Tooling for translations).

• missing [<locale>] lists, under the language file each is in, the wording a locale lacks and what a locale still in progress falls back on. It also lists translations made from wording that has since changed, and wording not yet accepted.
• unused lists the messages no code calls, and the app's wording of library packages' text that shows nothing.
• update records each translation's source in translations/sources.jadpo_record.
• accept <locale> accepts a locale's changed wording.

missing and unused succeed whatever they list. update and accept stop on syntax errors, write one status line for each record, and say still stale of a translation nobody redid. A misspelt action or locale is cli.translations_arguments, with the nearest name.

jadpo translations builtin lists Jadpo's own messages your app can show, by feature: their fields, the wording Jadpo ships and the locales that still need it. It lists only the messages of features your app has on, takes --json and succeeds whatever it lists. missing, update and accept take the root translations/ folder's wording of these messages in with the rest (Jadpo's and packages' text).

jadpo translations export [<locale>] and import <file> exchange messages, their descriptions and their wording with translation services, as XLIFF 2.0 or JSON. Each takes --json.

• export writes build/translations/<locale>.xlf for each translated locale, or the default locale's source file. --format json and --out <folder> change the format and the folder.
• import checks what comes back as jadpo check would. It writes the language files and the record, or nothing. It refuses with the language files' own rules, at the unit of the file, or with translation.exchange_unit_unknown or translation.exchange_file_invalid.

Library packages' text is exchanged under each package's folder name, and written back as the app's, in the root file.

Not built yet: jadpo seed <name>, which runs a seed and refuses production (Seeds).