Как организовать структуру проекта на Node.js правильно?

Question

[Станислав Гордиенко]

Привет, есть проект на Node.js (webpack, yarn, typescript, react и т.д.) Его структура выглядит следующим образом:

Мне надо проработать две стадии: CI (запуск юнит тестов, сборку, линты) и CD (деплоймент на сервер).

Меня смущает здесь несколько моментов:

1. Структура проекта. Когда я запустил webpack, yarn то собранный проект собрался в папке dist. Собираю я проект на CI сервере, но потом мне надо его деплоить на другой сервер. Не нравится идея копировать dist и все вложенные папки - сердце подсказывает, что оно сделано очень ugly. Аргументировать не могу, так как это не мой родной стек. Разработчики объясняют это тем, что они используют TypeScript, и он находится в папке src, поэтому вот так все собирается;
   
2. node_modules разработчики советуют включить в архив для последующего деплоймента и разворачивания на сервере. То есть, будет копироваться папка dist и node_modules. Не рекомендуют запускать npm install заново на сервере, так как по их мнению могут подтянуться совсем другие версии (как Django разработчик не понимаю как такое реально).
   

Что хочу я:

1. Простая и понятная структура папок для проекта;
   
2. Минимальный размер архива с проектом для деплоймента;
   
3. Использовать docker. Но даже и в нем когда я соберу и установлю, структура папок будет монструозной.
   

Что вы посоветуете? Спасибо.

Comments

[Максим Федоров]

node_modules разработчики советуют включить в архив

Не рекомендуют запускать npm install заново на сервере,

по их мнению

:)

орлы работают :)
хоть не советуют через Гугл-докс деплоить все и ФТП :)

[Максим Федоров]

а как они предлагают архив транпсортировать?

[Станислав Гордиенко]

Для .Net стека я использую Octopus Deploy. Думал для Node.js использовать docker и управлять Octopus'ом. Но эти самые орлы против докера :-)

Answer 1

[Александр Таратин]

по их мнению могут подтянуться совсем другие версии

Данную проблему решает https://docs.npmjs.com/files/package-lock.json

Comments

[Максим Федоров]

есть мнение, что они что-то намутили руками в node_modules

[Станислав Гордиенко]

Максим Федоров, в проекте? Или по ссылке?

[Максим Федоров]

Станислав Гордиенко, в проекте
по ссылке правильное решение для фиксации версий в преокте,
также например в пакетном менеджере Composer для языка PHP (composer.lock),
в PHP тоже куча умников в папку vendor руками лезут

[Станислав Гордиенко]

Максим Федоров, спасибо. Понял.

А как быть со структурой? Тогда получается, что мне надо в архив добавлять папку dist + packages.json и на сервере, когда я все это выложу, мне надо будет запустить npm install. Не нравится вложенной папок dist/build/... Я ожидал что-то наподобие public, src, conf. В public - client скрипты и другие асеты. В src - бэкенд сервер (typescript -> javascript).

[Максим Федоров]

Станислав Гордиенко, ну да, так все везде и делают...
ну судя по схеме папок,
dist/build/client/public — это и есть public :)

Просто кто-то не мог в окружения и наплодили несколько папок для прода и локала

мне надо в архив добавлять папку...

кстати! А где GIT?

[Станислав Гордиенко]

Git на CI сервере, я забираю последние изменения, собираю, тестирую. И добавляю в архив для деплоймента штуки. Сейчас настрою чтобы этот архив транспортировался посредством Октопуса. На сервере я запускаю все под iisnode, так как менеджмент еще не решил какую систему юзать.

[Максим Федоров]

Станислав Гордиенко, подождите,
ваши сервера CI/CD отличаются от продакшена?
Или вам нужно забрать проект и он ваш?

НЕ понимаю, почему сейчас проект не под гитом? С этого нужно сперва начать

[Станислав Гордиенко]

Максим Федоров, проект под Git'ом. TeamCity забирает его, билдит, паблишит. Создает архив и аплоадит его в Octopus. Дальше мы его деплоим на тестовый сервер. CI/CD сервер отличается - да.

Answer 2

[Станислав Макаров]

Разработчики объясняют это тем, что они используют TypeScript, и он находится в папке src, поэтому вот так все собирается

Логично, нормальное решение.

Не нравится идея копировать dist и все вложенные папки

А в чём проблема? В dist не должно быть лишнего хлама, .git и прочего добра, по сути это готовая сборка приложения для деплоя, почему бы её не скопировать?

Не рекомендуют запускать npm install заново на сервере, так как по их мнению могут подтянуться совсем другие версии

А нехрен позволять npm-у ставить нефриженную версию в package.json. Нам вот уже настохорошело что проект ломается сам по себе из-за выхода новых версий библиотек, и мы зафризили все пакеты. Это нормальная ситуация, если у вас не библиотека, а конечное приложение. package-lock.json пытались использовать, но потом отказались - в версиях NPM 5.0-5.2 он работал отвратительно, сейчас уже может получше, не знаю.

Comments

[Станислав Гордиенко]

Мне не нравится, что на сервере финальная структура проекта будет вида:
/dist/build/client
/dist/build/server
/node_modules

[Станислав Макаров]

Станислав Гордиенко мне кажется что нет нужды собирать клиент и сервер вместе. Более того, возможно даже нет нужды держать их в одной репе.

Я не знаю что у вас за архитектура (SPA или нет), но вполне может быть что все ваши сомнения из-за того, что клиент и сервер разрабаюыватся в одном репозитории, что вовсе необязательно, и даже нежелательно. Если у вас сервер это по сути API (что вероятно, раз вы его на ноде писали), то тогда разрабатываться и деполиться они могут отдельно (так кстати будет намного лучше, т.к. это заставит вас задумываться о совместимости API и вы возможно не захотите ломать работу клиентов, которые давно не нажимали F5, например у нас это критично, люди неделями сидят не обновляя страничку).

И ещё непонятно что за build и local, это зачем в dist-е?

[Станислав Гордиенко]

Станислав Макаров, я не знаю зачем в dist две папки. Спрошу у них )