Я работаю с Node.js с 2012 года и потратил много времени на различные проекты с открытым исходным кодом и частные проекты. И мне очень нравится моя работа. Также работаю фрилансером и время от времени присоединяюсь к уже существующим проектам. И каждый раз, когда я открываю новый проект, я смотрю на его структуру. И, честно говоря, все, что я хочу видеть, это простые вещи:
.editorconfig
файл.- Линтер-файл или конфигурация.
- Актуальный и актуальный
.gitignore
файл. - Правильный и актуальный
package.json
файл. - Хоть что-то в
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
- Файлы журналов
- Данные о времени выполнения
*.pid
*.seed
- Заблокировать файлы
*.lock
- Файлы отладки и ошибок
npm-debug.log
yarn-debug.log
yarn-error.log
- Файлы окружения
.env
- В большинстве случаев архивы и резервные копии
*.zip
*.tgz
- И конечно не давите
node_modules
!!! Никогда !!!
Еще один момент. Если вы работаете в определенной ОС редактора, он создает список определенных файлов. Просто добавьте все эти файлы в ~/.gitignore_global
Например, я работаю в OSXvim
и первые строки моего ~/.gitignore_global
:
*.sw* *.DS_Store .AppleDouble .LSOverride
Эти файлы никогда не должны быть переданы в репозиторий git.
4. Правильный и актуальный файл package.json
.
Каждый разработчик Node.js знает, что package.json
является основным файлом в вашем проекте. Но многих разработчиков это волнует только тогда, когда они создают новый проект и игнорируют его в дальнейшем.
Статья уже очень большая, поэтому я просто перечислю вам моменты, которые вы должны учитывать при работе над проектом.
- Заполните поле
author
актуальными данными и отслеживайте там адрес электронной почты. Если есть список людей, работающих над модулем, используйте поле `contributors` - Лицензия. Это действительно помогает, когда вы выбираете правильный
license
в своемpackage.json
и, конечно, если вы решили изменить его, замените его - Разделите свои зависимости между
dependencies
иdevDependencies
.mocha
никогда не должно быть в производствеdependencies
правильно? - Поле
engines
должно определять список версий узлов, с которыми работает ваш модуль. Это очень полезно, когда вы ищете новый модуль для старого проекта ;) 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
вы потратите много времени на то, чтобы это выяснить.
Если вы дочитали до этого места, значит, вас действительно интересует чистый код и работающий проект! Поздравляем!