Структурированная конфигурация: меняйте значение, а не пунктуацию

Почему специальный инструмент иногда проще текстового редактора

Представьте большой конфигурационный файл, где нужно изменить только application.debug. В обычном редакторе вы ищете секцию, проверяете нужное совпадение, следите за пунктуацией и сохраняете весь файл. В структурированной команде достаточно назвать логический путь.

Это не попытка заменить редактирование исходника. Это выбор инструмента по намерению. Если задача состоит в изменении значения — обращайтесь к значению.

Один рабочий ритм для нескольких форматов

Форматные модули намеренно имеют похожую грамматику: открыть файл, прочитать ключ, найти значение, записать через :, удалить ключ, проверить через -c или получить сериализованный исходник через dump. Освоив один формат, остальные уже не выглядят чужими.

Открытый структурированный файл становится активным. Затем $ может заменять его путь, поэтому серия операций над одним файлом остаётся короткой и читаемой.

INI: секции и простые значения

INI часто встречается в конфигурации благодаря простой структуре: секции группируют пары ключ/значение. В lil-terminal точечный путь позволяет обратиться к нужному значению, не прокручивая весь файл.

Используйте INI там, где этот формат уже выбран программой или проектом. Наличие удобной команды не означает, что один формат должен заменить все остальные.

JSON: объекты, массивы и типизированные значения

Для упражнения откройте project/config/app.json через code -n, вставьте показанную ниже заготовку {}, сохраните файл и только после этого запускайте команды json. Структурный редактор работает с уже валидным JSON.

JSON хранит вложенные объекты и массивы и постоянно встречается в API, настройках приложений и метаданных. Его синтаксис строг, поэтому точечная правка по пути помогает не ошибиться в запятой или скобке.

Тип значения важен: число должно остаться числом, логическое значение — логическим, строка — строкой. После изменений -c выполняет явную проверку документа.

{}

YAML, TOML, XML, conf и properties

YAML строится вокруг отступов и часто используется в файлах развёртывания; TOML любит явные таблицы и типы; XML хранит элементы и атрибуты; семейства .conf и .properties часто встречаются в настройках серверов и приложений. Задачи похожи, но синтаксические традиции разные.

lil-terminal даёт единый повседневный интерфейс там, где структуру можно представить без потерь, но не делает вид, что все форматы одинаковы. Сложные конструкции YAML, необычный XML или специфический синтаксис конкретной программы иногда правильнее редактировать как исходный текст через code.

Проверяйте модель; `dump` используйте, когда нужен исходник

-c просит модуль проверить текущий документ. dump возвращает сериализованное представление исходника. Это разные вопросы: «валиден ли документ для обработчика?» и «какой текст получится из этих данных?».

После структурированной записи могут нормализоваться отступы, порядок или комментарии, потому что данные разбираются и сериализуются заново. Если точное оформление исходного файла является частью требования, используйте edit или code.

Понимайте, когда пора вернуться в `code`

Форматный модуль удобен для точечных значений, поиска и проверки. code нужен, когда важны комментарии, ручное форматирование, сложные возможности формата или более широкий рефакторинг. Ни один режим не является «старшим» — они отвечают на разные вопросы.

Хорошая привычка — переключаться без идеологии: структура, когда важен смысл; исходник, когда важен именно исходник.

Изменения конфигурации идеально подходят для сценариев

Проверенную последовательность настроек стоит сохранить как сценарий. Вместо заметки «не забыть включить режим отладки и поменять имя» оставьте команды, которые выполняют изменения и сразу проверяют результат.

Такой сценарий становится исполняемой документацией. На следующем проекте его можно прочитать, заменить нужные значения и воспроизвести знакомую среду без догадок.