Структура папок для проекта Node.js

346

Я заметил, что проекты Node.js часто включают в себя такие папки:

/ libs, / vendor, / support, / spec, / tests

Что именно это значит? В чем разница между ними, и где я должен включить ссылочный код?

node.js

— Гуйлинь 桂林
источник

439

Что касается папок, которые вы упомянули:

/libs обычно используется для пользовательских classes/functions/modules
/vendorили /supportсодержит сторонние библиотеки (добавляются как подмодуль git при использовании git в качестве исходного кода)
/spec содержит спецификации для тестов BDD.
/testsсодержит юнит-тесты для приложения (с использованием инфраструктуры тестирования, см. здесь )

ПРИМЕЧАНИЕ: оба /vendorи /supportустарели, так как NPM ввел чистое управление пакетами. Рекомендуется обрабатывать все сторонние зависимости, используя NPM и файл package.json.

При создании довольно большого приложения я рекомендую следующие дополнительные папки (особенно если вы используете какой-то MVC- / ORM-Framework, такой как express или mongoose ):

/modelsсодержит все ваши модели ORM (называемые Schemasв мангусте)
/views содержит ваши view-шаблоны (используя любой язык шаблонов, поддерживаемый в экспрессе)
/public содержит весь статический контент (изображения, таблицы стилей, клиентский JavaScript)
- /assets/images содержит файлы изображений
- /assets/pdf содержит статические файлы PDF
- /css содержит таблицы стилей (или скомпилированный вывод с помощью движка css)
- /js содержит клиентский JavaScript
/controllersсодержит все ваши экспресс-маршруты, разделенные модулем / областью вашего приложения (примечание: при использовании функции начальной загрузки экспресса эта папка вызывается /routes)

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

Обновление для приложений Express на основе CoffeeScript (с использованием connect-assets ):

/app содержит ваш скомпилированный JavaScript
/assets/ содержит все клиентские ресурсы, которые требуют компиляции
- /assets/js содержит ваши файлы CoffeeScript на стороне клиента
- /assets/css содержит все ваши таблицы стилей LESS / Stylus
/public/(js|css|img) содержит ваши статические файлы, которые не обрабатываются никакими компиляторами
/src содержит все ваши специфичные для сервера файлы CoffeeScript
/test содержит все скрипты модульного тестирования (реализованные с использованием тестовой платформы по вашему выбору)
/views содержит все ваши экспресс-взгляды (будь то Jade, EJS или любой другой шаблонизатор)

— schaermu
источник

5

где бы вы разместили свои клиентские js, css, изображения? Вы бы предложили подобную структуру папок в общей папке, например: public / assets public / assets / css public / assets / images public / assets / docs public / libs public / support public / tests public / models public / views public / controllers ?

— ezmilhouse

2

expressjs создает каталог ./routes, это то же самое, что и ./controllers в вашем примере?

— Чови

2

Почему бы вам не создать Йоменский генератор с этим предложением? Это может стать стандартом.

— Jayr Motta

+1 Исходя из ASP.NET MVC, называть «маршруты» папки «контроллеры» имеет для меня гораздо больше смысла.

— adam0101

Вопрос, разве структуры каталогов обычно не генерируются платформой (то есть Symfony для PHP)? Например, в Express нет правильной структуры каталогов? Разработчики должны вручную создавать и поддерживать MVC дизайн и маршруты? Я ценю любые отзывы, я новичок в Express

— AnchovyLegend

49

На GitHub обсуждается вопрос, похожий на этот: https://gist.github.com/1398757

Вы можете использовать другие проекты для руководства, поиск в GitHub для:

ThreeNodes.js - на мой взгляд, имеет определенную структуру, не подходящую для каждого проекта;
легче - более простая структура, но не хватает организации;

И, наконец, в книге ( http://shop.oreilly.com/product/0636920025344.do ) предлагается такая структура:

├── index.html
├── js/
│   ├── main.js
│   ├── models/
│   ├── views/
│   ├── collections/
│   ├── templates/
│   └── libs/
│       ├── backbone/
│       ├── underscore/
│       └── ...
├── css/
└── ...

— Пауло Оливейра
источник

Я создал модуль для динамического запроса файлов, позволяющий структурировать проект по функциям, а не по типу Модель, Представление, Контроллер. Надеюсь, что это кому-нибудь поможет: github.com/ssmereka/crave

— Скотт,

13

Еще пример из моей архитектуры проекта вы можете увидеть здесь:

├── Dockerfile
├── README.md
├── config
│   └── production.json
├── package.json
├── schema
│   ├── create-db.sh
│   ├── db.sql
├── scripts
│   └── deploy-production.sh 
├── src
│   ├── app -> Containes API routes
│   ├── db -> DB Models (ORM)
│   └── server.js -> the Server initlializer.
└── test

По сути, логическое приложение разделено на папки DB и APP внутри каталога SRC.

— Даниэль Черненков
источник

если ваше приложение также содержит приложение переднего плана, помещаете ли вы srcего в приложение или оно получает собственную папку (со своей собственной package.jsonи похожей структурой папок)?

— вали

2

@wal Я предпочитаю разделять фронтенд-проекты в другом репозитории, так как он более организован

— Даниэль Черненков

2

Это косвенный ответ, относительно самой структуры папок, очень связанный.

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

Теперь, выполнив несколько проектов, помимо объяснения во всех других ответах, о самой структуре папок, я настоятельно рекомендую следовать структуре самого Node.js, которую можно увидеть по адресу: https://github.com/ nodejs / узел . Здесь подробно рассказывается обо всем, скажем, о линтерах и других, о структуре файлов и папок и где они находятся. В некоторых папках есть README, которая объясняет, что находится в этой папке.

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

Надеюсь это поможет.

— Манохар Редди Поредди
источник

1

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

Я нахожу это разочаровывающим и огромным, но не менее важным. Это своего рода недооцененная версия (но более важная для IMO) проблемы руководства по стилю . Мне нравится указывать на это, потому что ответ один и тот же: не имеет значения, какую структуру вы используете, если она четко определена и последовательна .

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

Это не легко, особенно если вы новичок в этом! Ожидайте проводить часы, исследуя. Вы найдете большинство руководств, рекомендующих MVC-подобную структуру. Хотя несколько лет назад это могло быть солидным выбором, сегодня это не всегда так. Например, вот другой подход .

— thisismydesign
источник

1

Предположим, мы говорим о веб-приложениях и создании API:

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

Лучший способ проиллюстрировать это на примере:

Мы разрабатываем библиотечное приложение. В первой версии приложения пользователь может:

Ищите книги и смотрите метаданные книг
Ищите авторов и смотрите их книги

Во второй версии пользователи также могут:

Создать аккаунт и авторизоваться
Займы / брать книги

В третьей версии пользователи также могут:

Сохраните список книг, которые они хотят прочитать / отметить избранное

Сначала мы имеем следующую структуру:

books
  ├─ controllers
  │   ├─ booksController.js
  │   └─ authorsController.js
  │
  └─ entities
      ├─ book.js
      └─ author.js

Затем мы добавим функции пользователя и кредита:

user
  ├─ controllers
  │   └─ userController.js
  ├─ entities
  │   └─ user.js
  └─ middleware
       └─ authentication.js
loan
  ├─ controllers
  │   └─ loanController.js
  └─ entities
      └─ loan.js

И тогда любимый функционал:

favorites
  ├─ controllers
  │   └─ favoritesController.js
  └─ entities
      └─ favorite.js

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

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

— maxpaj
источник