Я работаю с Node.js с 2012 года и потратил много времени на различные проекты с открытым исходным кодом и частные проекты. И мне очень нравится моя работа. Также работаю фрилансером и время от времени присоединяюсь к уже существующим проектам. И каждый раз, когда я открываю новый проект, я смотрю на его структуру. И, честно говоря, все, что я хочу видеть, это простые вещи:

  1. .editorconfig файл.
  2. Линтер-файл или конфигурация.
  3. Актуальный и актуальный .gitignore файл.
  4. Правильный и актуальный package.json файл.
  5. Хоть что-то в README.md файле.

Теперь я мог бы дать вам больше информации о каждом из этих пунктов.

1. editorconfig файл

Каждый разработчик индивидуален. Каждый предпочитает свой собственный набор конфигураций и правил среды. И каждый разработчик может возразить, почему его/ее IDE/редактор/что-то еще — лучший инструмент на свете.

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

Вот пример конфигурации, которую мы используем в команде Trails.js:

root = true

[*]
indent_style = space
indent_size = 2
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true

[*.md]
trim_trailing_whitespace = false

Вы можете найти гораздо больше информации и правил здесь: http://editorconfig.org/

2. ЛИНТЕР-файл или конфигурация.

В JavaScript нет внутреннего инструмента для стилизации кода, такого как Golang. В результате в компаниях и проектах существует множество разных стилей кода. И я почти уверен, что у вас есть свой собственный. Так что стало очевидным добавить эти правила в свой проект.

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

В большинстве случаев люди используют jshint или eslint. Я предпочитаю eslint из-за лучшей поддержки и гибкости.

Вам не нужно постоянно копировать/вставлять все свои конфиги из проекта в проект. Просто создайте конфигурацию как модуль npm и опубликуйте ее. Затем просто скажите, что проект использует эти правила:

Как часть вашего файла package.json:

"eslintConfig": {  "extends": "trails"  }

Или в файле .eslintrc

{
  "extends": "trails"
}

3. Актуальный и актуальный .gitignore файл.

Это также одна из самых очевидных вещей, которые должен знать каждый разработчик. Но на самом деле довольно часто я вижу в репозиториях файлы типа .idea или npm-debug.log.

Просто подумайте, что вам нужно, чтобы начать проект с нуля и добавить все остальное в свой .gitignore

  1. Файлы журналов
  2. Данные о времени выполнения *.pid *.seed
  3. Заблокировать файлы *.lock
  4. Файлы отладки и ошибок npm-debug.log yarn-debug.log yarn-error.log
  5. Файлы окружения .env
  6. В большинстве случаев архивы и резервные копии *.zip *.tgz
  7. И конечно не давите node_modules!!! Никогда !!!

Еще один момент. Если вы работаете в определенной ОС редактора, он создает список определенных файлов. Просто добавьте все эти файлы в ~/.gitignore_global

Например, я работаю в OSXvimи первые строки моего ~/.gitignore_global:

*.sw*
*.DS_Store
.AppleDouble
.LSOverride

Эти файлы никогда не должны быть переданы в репозиторий git.

4. Правильный и актуальный файл package.json.

Каждый разработчик Node.js знает, что package.json является основным файлом в вашем проекте. Но многих разработчиков это волнует только тогда, когда они создают новый проект и игнорируют его в дальнейшем.

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

  1. Заполните поле author актуальными данными и отслеживайте там адрес электронной почты. Если есть список людей, работающих над модулем, используйте поле `contributors`
  2. Лицензия. Это действительно помогает, когда вы выбираете правильный license в своем package.json и, конечно, если вы решили изменить его, замените его
  3. Разделите свои зависимости между dependencies и devDependencies . mocha никогда не должно быть в производствеdependencies правильно?
  4. Поле engines должно определять список версий узлов, с которыми работает ваш модуль. Это очень полезно, когда вы ищете новый модуль для старого проекта ;)
  5. scripts хотя бы определите start и test скрипты (конечно, если ваш модуль просто библиотека — start скрипт вам не нужен)

Еще несколько слов о секции scripts. Это действительно полезно, если вы будете определять команды, используя связанные пути. Например, выполнение тестов с mocha . можно заменить на ./node_modules/mocha/bin/mocha ., и люди, у которых не установлено глобально mocha, смогут запускать тесты.

Запустите линтер перед тестами! Что-то типа:

"test": "./node_modules/eslint/bin/eslint.js . && NODE_ENV=testing ./node_modules/mocha/bin/mocha"

Никто не сможет протолкнуть уродливый код, потому что тесты не пройдут.

5. Хоть что-то в README.md файле.

Неважно, планируете ли вы открыть проект или это проект только для вас. Напишите что-нибудь в файле README.md.

Через несколько месяцев вам нужно будет открыть код, и вы столкнетесь с совершенно новым для вас кодом. Вы не помните, как это работает. У вас будут проблемы с запуском и настройкой его снова.

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

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