Html5-boilerplate: RFC: переход на ESLint

Кто угодно? Я согласен оставить статус-кво. ESLint великолепен, но меня нужно убедить внести изменения (и тогда кто-то должен будет внести изменения в PR). Я оставлю это открытым еще на неделю и, если не будет никаких действий, закрою.

Я могу пиарить за это. ESLint, возможно, является одним из наиболее широко используемых инструментов в экосистеме javascript.

http://www.npmtrends.com/eslint-vs-jshint

@roblarsen Я полностью на стороне @amilajack ,
Я сделал краткое сравнение между ними с некоторыми данными, которые я собрал из Интернета, если вы хотите взглянуть.

Спасибо ребята. Это отличный материал. Кто-нибудь еще хочет вмешаться?

@amilajack спасибо за предложение по пиару. Это действительно ценится.

@roblarsen Добро пожаловать!
@amilajack Не стесняйтесь

@amilajack Ты все еще над этим работаешь?

@ryzokuken Есть открытый пиар, на который мне нужно взглянуть и смириться. # 1930

Я бы порекомендовал изучить Standard, который является дополнением к ESLint и довольно популярным. Честно говоря, это облегчение для использования, наконец, прекращения поддержки конфигураций ESLint ...

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

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

Более того, точки с запятой выигрывают по популярности, если взять в качестве примера руководство по стилю JavaScript Airbnb: один из самых популярных репозиториев на GitHub и большее количество загрузок на NPM. [1] [2] [3] [4]

Кроме того, нам нужно будет обновить все файлы JavaScript, поскольку все они уже используют точку с запятой. [5] [6]

Поэтому я не считаю, что этот предмет стоит того, чтобы отказываться от

Рекомендации:

[1] https://github.com/airbnb/javascript
[2] https://www.npmjs.com/package/eslint-config-airbnb-base
[3] https://www.npmjs.com/package/eslint-config-airbnb
[4] https://www.npmjs.com/package/eslint-config-standard
[5] https://github.com/h5bp/html5-boilerplate/blob/master/gulpfile.babel.js
[6] https://github.com/h5bp/html5-boilerplate/blob/master/src/js/plugins.js

В любом случае, это все сведется к спорам о кодестиле. Я просто предлагаю проверенную в боях альтернативу.

Между прочим, я должен подчеркнуть, что независимо от того, какой вариант будет использоваться (будь то ESLint с собственными правилами проекта, будь то популярная конфигурация ESLint, например, airbnb, или стандартная), он все равно заставит пользователей следовать чему-то. Так что это просто вопрос того, что именно будет выполняться.

На этом этапе я хочу переключиться на eslint с минимально возможным прерыванием. Это включает в себя отказ от существующих правил, которые у нас есть, без обсуждения, по крайней мере, того, какими должны быть новые правила (вот почему существующий PR для eslint - DOA).

Я, например, умру на холме точек с запятой.

В качестве примечания: фактические потребители набора правил ограничиваются сопровождающими и всеми, кто сознательно создает PR и фактически тестирует свой код. Мы не будем отправлять eslintrc в дальнее расстояние. Реальная выгода с точки зрения проекта в том, что мы делаем это и можем служить примером того, как должен выглядеть хороший веб-разработчик.

Я, например, умру на холме точек с запятой.

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

Мы не будем отправлять eslintrc в отдаленные районы. Реальная выгода с точки зрения проекта в том, что мы делаем это и можем служить примером того, как должен выглядеть хороший веб-разработчик.

Но вы отправляете JS-код, который будет включен в другие проекты, которые позже будут добавлены, и люди будут вынуждены либо редактировать его в соответствии со своими правилами, либо использовать правила HTML5Boilerplate. Вот почему JS должен быть как можно ближе к стандартам сообщества JS, и я думаю, что внесение некоторых необходимых изменений в правила и стиль кода неизбежно. И это не так уж и проблемно - Standard и ESLint с --fix автоматически исправят большую часть введенной ошибки правила.

Настоящая проблема в том, что считать стандартом сообщества в мире JS.

Хорошие моменты. Приятно напоминать о последствиях даже небольшого количества JS, которое мы поставляем.

И чтобы уточнить, я не против внесения изменений. Чего я не хочу делать, так это вносить массовые изменения без обсуждения (так что спасибо за участие в обсуждении 👍) Хотя я довольно отчаянно пытаюсь выпустить 6.0 прямо сейчас, я обычно не тороплюсь с внесением изменений здесь, если они не правильные изменения.

Один из вариантов - применить конфигурацию eslint:recommended которая сообщает об общих проблемах, но на самом деле не накладывает стилистических предпочтений. В этом случае ESLint будет просто служить для предотвращения ошибок и ошибок. Это действительно своего рода минимальная конфигурация, основанная на здравом смысле.

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

4 пробела

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

https://github.com/h5bp/html5-boilerplate/issues/1913#issuecomment -377298563 (eslint: рекомендовать) звучит хорошо, хотя я лично предпочитаю https://github.com/h5bp/html5-boilerplate/ issues / 1913 # issuecomment -318050971 (StandardJS).

В шутку: https://github.com/christophwitzko/semicolon-indent#semicolon -indent

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

Но справедливости ради стоит упомянуть и Prettier . Хотя мой голос по-прежнему за Стандарт.

Напоминание из ранее в обсуждении

Я, например, умру на холме точек с запятой.

Представьте, что это игра на выживание, и как будто мы живем в 2005 году, выбирая табуляцию или пробел.

Кстати, стоит упомянуть о Prettier - он должен сочетаться с хорошей конфигурацией ESLint, потому что в основном все, что Prettier поддерживает, - это стиль кода, в то время как конфигурации ESLint (и особенно стандартные) охватывают также множество нестилистических хороших или плохих практик.