EditorConfig — Одни Настройки для всех Редакторов/IDE

от автора

EditorConfig это конфигурационный файл и набор расширений, к большому количеству редакторов кода и IDE (Далее просто IDE).

Его задача — создать единый формат настроек, и, раз и навсегда, решить вопросы вроде “табы или пробелы” для всех IDE и всех языков программирования.

Файлы .editorconfig можно найти в таких проектах, как jQuery, Ruby, WordPress, и многих других.

Плагины доступны для большого количество IDE


Давайте разберемся, как это работает.

Как выглядит файл EditorConfig?

Вот пример файла .editorconfig, который задает правила отступа для Python и JavaScript кода:

## Заранее извиняюсь за отсутствие нормальной подсветки синтаксиса в этом примере и далее. ## Хоть "ini" и содержится в списке форматов поддерживаемы Хабром, код красивым не становится. ## Если кто знает, как это починить - пожалуйста напишите в личку. # # Корневой файл EditorConfig root = true  # Для всех файлов используем unix-совместимые переносы строк [*] end_of_line = lf insert_final_newline = true  # отступы в 4 пробела [*.py] indent_style = space indent_size = 4  # Используем табы для отступов (Не указываем размер) [*.js] indent_style = tab  # Перезависываем настройку отступов для js файлов в папке lib [lib/**.js] indent_style = space indent_size = 2  # Только для файлов package.json or .travis.yml [{package.json,.travis.yml}] indent_style = space indent_size = 2 

Формат файла

Файлы EditorConfig используют слегка модифицированный INI формат.
Каждый .editorconfig должен быть в кодировке UTF-8, а в конце строк должно быть либо
CRLF либо LF.

В качестве имени секции выступает маска файлов, например [*.js] или [index.html].

В отличии от обычного .ini формата, в имени секции можно использовать [ и ], что позволяет указать список символов, один из которых должен находиться в указаной позиции. Например, допустимы конструкции вроде этой: [file[123].js]. Как это работает — читайте ниже.

Каждый комментарий должен быть на отдельной строке и начинаться с ; или #.

Как работает поиск файлов по маске

* - Любое количество символов кроме разделителя пути (/)

Пример: [*.js]
hello.js // Совпадение
hellojs // Нет совпадения
index.html // Нет совпадения
lib/source.js // Нет совпадения

** - Любое количество символов

Пример: [**.js]
hello.js // Совпадение
hellojs // Нет совпадения
index.html // Нет совпадения
lib/source.js // Совпадение

? - Один любой символ

Пример: [hell?.js]
hello.js // Совпадение
hell.js // Нет совпадения

[name] - Любой символ из символов содержащийся в “name”

Пример: [[abc].js]
a.js // Совпадение
b.js // Совпадение
abc.js // Нет совпадения

[!name] - Любой символ которого нету в “name”

Пример: [file[!2468].js]
file1.js // Совпадение
file2.js // Нет совпадения

{s1,s2,s3} - Любая из строк разделенных запятыми

Пример: [index.{js,html}]
index.js // Совпадение
index.html // Совпадение
package.json // Нет совпадения

\ - Экранирование служебных символов

Пример: [\[abc\].js]
a.js // Нет совпадения
<b>[abc]</b>.js // Совпадение

Настройки

Что можно настроить?

Editor config стремится быть независимым от языков и работать во всех IDE. К сожалению это не всегда возможно, поэтому некоторые из плагинов поддерживают не все настройки.

Все настройки нечувствительны к регистру.

indent_style

Значения: tab, space
Позволяет задать жесткую или мягкую табуляцию для отступов.

indent_size

Значения: Число
Позволяет задать ширину отступа использовании мягкой табуляции.

tab_width

Значения: Число
Позволяет задать ширину отступа использовании жесткой табуляции. Если не задано, возьмет значение из indent_size.

end_of_line

Значения: lf, cr, crlf
Позволяет выбрать, что использовать на концах строк.

charset

Значения: latin1, utf-8, utf-8-bom, utf-16be, utf-16le
Позволяет выбрать кодировку для файлов.
Использовать utf-8-bom не рекомендуется

trim_trailing_whitespace

Значения: true, false
Позволяет убрать пробелы из концов строк.

insert_final_newline

Значения: true, false
Позволяет убедиться, что в конце файла всегда будет новая строка.

root

Значения: true, false
Специальная настройка, которая должна быть на самом верху конфига. Если установлена в true, парсер не будет искать другие конфиги родительских папках (Подробности ниже).

Специальное значение Ignore

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

# Задаем форматирование для JS и CSS [*.{js,css}] indent_style = space indent_size = 2 # Но не переформатируем минифицированные JS и CSS файлы. [*.min.*] indent_style = ignore trim_trailing_whitespace = false insert_final_newline = ignore 

А почему так мало настроек?

Изначальная задача EditorConfig — создать минимальный набор свойств, который работал бы во всех основных IDE.

Задача непростая, для примера давайте рассмотрим возможность добавления настройки, которая бы ограничила ширину строки: max_line_length
Чтобы добавить эту настройку, нужно решить несколько вопросов:

  • Убедиться, что все редакторы/IDE ее поддерживают
  • Решить, использовать ли жесткий или мягкий (когда строка физически остается длинной, но выглядит как две) перенос, или позволить пользователю выбрать это, добавив еще одну настройку (не все редакторы/IDE поддерживают оба вида переноса)
  • Если использовать жесткий перенос, то что делать с языками где жесткий перенос может сломать код? (например HAML)

На данный момент свойство max_line_length существует, но работает только в vim.

Расширение EditorConfig

Если или программа, использующая EditorConfig, встречает незнакомую настройку, она должна ее проигнорировать. Это позволяет сделать формат расширяемым и не ограничиваться стандартными настройками.

Здесь есть два направления для развития:

Настройки для отдельных редакторов/IDE

Некоторые редакторы/IDE имеют свои особенности, например в jEdit набор кодировок больше, поэтому существует настройка jedit_charset, которая работает только для jedit.

Настройки для отдельных языков/расширений

Сторонние программы и плагины могут расширять EditorConfig и добавлять настройки, которые будут работать только для определенных языков или расширений файлов.

Например npm модуль CodePainter, который использует EditorConfig в качестве конфигурационного файла, позволяет выбрать кавычки (одинарные или двойные), которые будут использована для строк (qoute_type), или расставить пробелы внутри скобок (spaces_in_brackets). Но все это будет работать только для JavaScript.

Так же у разработчиков есть в планах целый набор возможных настроек, которые возможно будут использованы в будущем, например:

curly_bracket_next_line

Задает перенос фигурной скобки на следующую строчку, для языков где она есть

java_class_path

Может быть использовано другими плагинами

language

Позволяет задать язык по расширению файла. Это может помочь, когда шаблонизаторы, например Jinja2, используют файлы с расширением .html

Полный список можно посмотреть тут (eng.)

Где хранятся эти файлы?

Каждый раз, когда плагин будет работать с файлом, содержащим код, он будет подниматься по файловому дереву, от директории с файлом до корня, и загружать настройки из каждого .editorconfig файла на пути.
Приоритет настроек в конфигах, более близких к файлу, выше.

Для файла, с таким путем: /Users/username/code/project/main.js, .editorconfig будет искаться в следющих местах:

/Users/username/code/project/.editorconfig /Users/username/code/.editorconfig /Users/username/.editorconfig /Users/.editorconfig /.editorconfig 

Поиск можно остановить, задав root=true в одном из конфигов на пути.

Такая структура позволяет, например, создать .editorconfig в пользовательской папке и таким образом получить настройки по умолчанию для все проектов, и, при необходимости, переписать эти настройки на несколько уровней выше.

Как вычисляется настройки внутри файла?

Когда парсер читает файл .editorconfig, он дает больший приоритет настройкам, которые находятся ниже.
Авторы создали небольшое демо, где можно поиграться с форматом и посмотреть результат

Форматирование существующего кода

Плагины EditorConfig созданы таким образом, что они меняют настройки IDE в зависимости от окрытого файла. Иногда приходится использовать недокументрированне или необычные возможности IDE. Из-за этого форматирование применяется только при сохранении файлов, и если вы хотите использовать EditorConfig с уже существующим кодом, придется использовать один из инструментов ниже.

editorconfig-tools [ github ]

Набор инструментов для проверки и переформатирования кода. Находится на ранней стадии разработки и не пока не очень стабилен.

ECLint [ github ]

Похож по функциональности на editorconfig-tools, но, в дополнение, умеет анализировать существующий код и генерировать .editorconfig файл. Также на стадии разработки.

CodePainter [ github, npm ]

Использует .editorconfig, но работает только с JavaScript кодом.
Имеет специальные настройки для JS кода.

Плагины, как они работают и как их создавать?

В помощь создателям плагинов создан набор основных компонентов (ядер), которые могут быть использованы в плагинах и берут на себя работу по поиску и парсингуконфигурационных файлов. На данный момент существуют версии на C, Java, Python, ведется работа над JavaScript версией.

Сами плагины стараются перезаписать соответствующие настройки IDE вместо того, чтобы заниматься форматированием самим.

К сожалению, все еще не существует плагинов для такие IDE как Eclipse или NetBeans, их архитектура не позволяет легко менять настройки.

Если среди читающих есть кто-то, готовый взяться за создание плагинов, здесь неплохо расписано, как начать (eng.)</ф>

Для пользователей Windows

Чтобы создать файл .editorconfig в Windows Explorer, вам нужно создать файл с именем .editorconfig. и Windows Explorer переименует его в <code>.editorconfig.

Ссылки и как в этом можно поучаствовать

Команда EditorConfig проделала отличную работу, но впереди еще много трудностей, интересных задач и решений:

  • Написание и поддержка плагинов для менее известных IDE.
  • Разработка ядер для плагинов на других языках и доработка текущих
  • Расширение функциональности и добавление новых настроек
  • Доработка существующих решений для трансформации кода

Если кому-то из читателей интересно было бы принять участвие в работе проекта, вот хорошие способы связаться с разработчиками (все на английском):

Я не в команде проекта, но использую .editorconfig сам и с удовольствием передам ваши предложения и пожелания — пишите в личную почту.

ссылка на оригинал статьи http://habrahabr.ru/post/220131/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *