Как грамотно настроить локальную среду разработки?

Question

[cryptotsar]

На днях ко мне приедет новый macbook pro, и я решил, что пора подумать над тем, как будет организована локальная среда разработки. Как начинающий, я обычно ставил все необходимые пакеты (node.js, postgresql и т. п.) стандартным для пользователя ubuntu способом, используя команду apt, тем самым, "захламляя" ОС, когда возникала необходимость попробовать разные версии того же node.js. В macOS, насколько я понял, есть своеобразный сторонний аналог apt — homebrew, который, грубо говоря, работает схожим образом и не избавляет от проблемы "захламления", поскольку придется держать зоопарк различных версий в системе.
Мои многочисленные усилия понять, как сделать сделать свое рабочее пространство лучше и "безопаснее" для ОС, привели меня к двум открытиям: vagrant и docker. Правда, я пока так и не смог избавиться от путаницы в голове, поэтому прошу старших коллег помочь мне понять, когда и что из этого использовать, и на правильно ли я пути.

Answer 1

[Антон Спирин]

node то зачем в docker? Если уж возникло желание использовать разные версии, можно использовать nvm. Если вы работаете преимущественно с JavaScript, то node, имхо, гораздо удобней использовать если он установлен в системе.
php, DB и подобное в docker
Стоит оговориться, что если работаете в проекте со специфичной версией node и docker контейнерами, то ей, конечно, в docker самое место.

Comments

[chupasaurus]

nvm пищит в переменные среды и всё так же захламляет диск. В официальных докерных образах node стоит yarn из коробки, можно кеш пакетов разных версий хранить локально (с npm это нереально).

гораздо удобней использовать если он установлен в системе

Два примера можно?)

[Антон Спирин]

chupasaurus, если вы испытываете постоянное чувство страха перед перспективой "захламить" диск, то это к врачу.
У меня yarn так же стоит локально, как и еще несколько любимых инструментов. "yarn из коробки" так себе аргумент.

Пример 1:

mkdir project;
cd project/;
npm init;
npm install ...;

Пример 2:

git clone project;
cd project/;
npm install;

Стоит оговориться, что если работаете в проекте со специфичной версией node и docker контейнерами, то, конечно, ей там самое место.

[chupasaurus]

Антон Спирин, Проект всё так же хранится на хосте, для всего остального есть docker build ./.
Dockerfile:

ADD . /project
WORKDIR /project
RUN npm init
RUN npm install

[Антон Спирин]

chupasaurus, какой проект? Вы о чем? Внимательно посмотрите на примеры.
Пример 3:
sudo npm i -g rekit

Если вы для любой вещи, которую клонируете с Github или пробуете, для любого проекта который заводите локально используете контейнеры, что ж удачи, ваш выбор. Живите как живете, только не навязывайте, этот ИМХО ананизм остальным, как объективную истину и единственный верный путь.

[chupasaurus]

Антон Спирин, https://github.com/gasp/oktorder
Т.е. для других людей у вас другие принципы, потому что к вашему ответу "не навязывайте, этот ИМХО ананизм остальным" не работает. На истину я и не претендую.

[Антон Спирин]

chupasaurus, я написал ответ: "Если вы работаете преимущественно с JavaScript, то node, имхо, гораздо удобней использовать если он установлен в системе."
Вы заходите в комментарии, цитируете и пишите что-то вроде: "Два примера можно?)"
Я вам продемотстрировал пару примеров, почему я считаю, что это так.
В первом, старт любой вещи от небольшого самописного компонента или плагина, до пробного использования любого инструмента с последующим удалением директории.
Во втором, клонирование любого опенсорс проекта с целью посмотреть и так же безвозвратно удалить.
Вы настаиваете на использовании docker.
Добавил третий с глобальной установкой полезной утилиты.
Объективных плюсов использовать docker для кейсов, которые я привел нет. Кроме сугубо субъективных вроде "не захламлять" систему последним yarn, npm, rekit и еще чем-нибудь, что может оказаться полезным и удобным.
И зачем мне ваш бойлерплейт в контейнере с кучей ненужных инструментов? Я сам при необходимости подобный создам, а решать использовать мне при этом docker или нет буду исходя из целей, стека или задач.
Docker - отличный инструмент для своих задач, для проектной работы в частности, но зачем его пихать абсолютно во все кейсы, где нет ни одной объективной причины для использования?

Answer 2

[Виктор Янышев]

Действительно лучшим вариантом будет это docker с учетом твоих требований которые как по мне хз что требуют. Тебе окружение нужно под фрот или под бэк?