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

Я заметил, что проекты Node.js часто содержат такие папки:

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

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

Источник

7 ответов

Решение

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

  • /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 или любой другой шаблонизатор)
Источник

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

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

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

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

  • index.html
  • JS /
    • main.js
    • модели /
    • Просмотры/
    • коллекции /
    • шаблоны /
    • ЛИЭС /
      • магистральная /
      • нижнее подчеркивание/
      • ...
  • CSS /
  • ...
Источник

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

├── 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.

Источник

Предполагая, что мы говорим о веб-приложениях и создании 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

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

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

Источник

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

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

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

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

Источник

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

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

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

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

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

Источник

Просто клонируйте репо с GitHub

https://github.com/abhinavkallungal/Express-Folder-Structure

это базовая структура проекта node.js express.js с уже настроенной MongoDB в качестве базы данных, hbs в качестве механизма просмотра, nodemon также, поэтому вы можете легко настроить проект node js express

шаг 1: загрузите или клонируйте репозиторий шаг 2: откройте в любом редакторе кода шаг 3: откройте терминал по пути к папке шаг 4: запустите комментарий в терминале npm start шаг 5: начать кодирование

счастливого кодирования

Источник
Другие вопросы по тегам