Андрей Хохлов

Для dev-окружения имеет смысл монтировать весь код, включая папку node_modules, как том. И выполнять npm i/composer install в нужный момент.
Та же команда выполняется при сборке образа, в результате все необходимые пакеты оказываются установлены при тестировании и на проде.
Да, такой подход оставляет вероятность расхождения данных между dev и prod версиями. Для моей ситуации эта вероятность достаточно незначительна, чтобы ею пренебречь. В другом же случае стоит воспользоваться вашим вариантом 2.5.
Варианты 1 и 2 не рекомендую по простым причинам:
1. Нарушает принцип единообразия окружения: если у разработчиков, на stage, test и prod окружениях окажутся разные версии nodejs, это может обернуться большими проблемами. Поэтому все операции необходимо производить с помощью программ, установленных в контейнере.
2. Можно напороться на ситуацию, когда удаленные сервера зависимостей не отвечают (перегружены, ddos, упали и пр) или одна из зависимостей с них удалена (я так уже попадал). Другими словами, все содержимое папки node_modules/vendor должно храниться в контейнере. Либо пусть ваш админ поднимает зеркало того же packagist и морочае ся с актуальностью пакетов на нем (в чем смысла мало, если можно хранить все в образе контейнера).

Подготовьте ему смету, куда включите все по пунктикам, что сделано: прототип - столько-то часов, столько-то денег, телефонные переговоры с таким-то и таким-то его кандидатом на роль крутого фотографа - столько-то часов, столько-то времени... Длинный список, итого - затрачено времени - стоимость. Ознакомьте клиента. Разберитесь кто что кому еще должен. Желательно держаться в рамках спокойного диалога, ну а там уж как получится.

О, мой любимый холиварчик! =))

Начнем с indent vs brackets. Код с отступами лаконичен, по-своему красив, но обладает фатальным недостатком — его нельзя просто так взять и скопипастить из одного места в другое. Отступы обязательно нарушатся, IDE не поймёт и всё развалится. Нужно вручную поправлять, чтобы все встало на свои места. Также в процессе рефакторинга нарушаются отступы и появляется геморр. Второй серьёзный недостаток — это несовместимость с native css. Нельзя взять кусок css кода из интернетов и вставить в свой файл, его нужно вручную (или онлайн конвертером) переформатировать под нужный синтаксис. Всё это лишние телодвижения, лишние сложности, трата времени. Поэтому только скобки. Благо скобочный синтаксис поддерживается во всех трех препроцессорах.

В пункте 3 вы ерунду написали. Никто в серьезном проекте не будет подключать браузерный компилятор стилей. Даже при использовании less стили все равно обрабатываются заранее и на продакшн выкладывается готовый css файл.
Так что это преимущество less не стоит брать во внимание от слова "вообще".

[Написанное в следующем абзаце, исключительно моё мнение, а не общепризнанные факты]
Почему же sass выигрывает? Во-первых, это достаточно мощный препроцессор, с огромным количеством возможностей. Во-вторых, и я думаю, это главное, он единственный, компилятор которого написан на "С" -> скорость работы. Другие два написаны на javascript. И в-третьих, исторически так сложилось. Стайлус крутой препроцессор, но он появился много позже остальных и возможно, еще не успел набрать популярность.

В свою очередь у scss есть свои серьёзные недостатки.
Первый — невозможно в scss/sass файл импортировать обычный css, он не будет включен файл, а будет заменен css-импортом. В других препроцессорах имеются специальные синтаксические конструкции для этого.
Второй — отсутствие резолвинга путей, что другими так же предоставляется "из коробки". Приходится извращаться с прописыванием путей к картинкам. Проблема нивелируется при использовании вэбпака, но ведь не всегда он используется.

Что касается меня, то я готов мирится с этими двумя недостатками sass. Остальные возможности их с лихвой перекрывают.
На чем вам остановиться,я советовать не буду. Я свободно работаю со всеми тремя инструментами, но новые проекты всегда начинаю с использованием scss.

Так, мой комент с матом удалили. Напишу без мата (хотя это очень сложно) - много удаленки потому что битрикс очень плохая система и никто не хочет с ней работать кроме ушлых разрабов которые берут за это басновсловные деньги. А распространена она так, потому что продавая лицензии студии и частники получают партнерские отчисления. Втюхивают и подсаживают на этот ад, заламывая цены, если отказываются платить - бросают и привет мытарства по фрилансу. Одна и та же доработка например формы обратной связи обойдется на битриксе в два-три-двадцать раз дороже чем на условном вордпрессе. Бесплатных плагинов и готовых решений очень мало. Отвратительная документация, архитектура, комьюнити. Я 15 лет в веб-разработке и единственное что могу посоветовать - никогда не связывайтесь с этим ужасом если вы клиент и хотите себе сайт. А вот если вы разраб и хотите хорошо заработать на несчастных - то вперед, битрикс самое то.

Win + Ctrl + C

https://www.nextofwindows.com/windows-10-color-filters

Как распознать говнокодера, практическое руководство

<...>

Признак #17. Неспособность разграничить язык и фреймворк. Отнесение незнакомых синтаксических конструкций языка к особенностям используемого фреймворка.

<...>

.main-menu {
    $this: &;
    display: none;
    &--open {
        display: block;
        #{$this}__link {  }
    }
}

Но я предпочитаю такой вариант:

.main-menu {
    display: none;
    &--open { display: block; }
    &--open &__link {  }
}

Если у вас нет активной разработки фронтенда - храните как есть
Если есть, то попросите фронтендера вам показать, как запускать перед collectstatic сборку фронта перед деплоем

Из перечисленных (через запятую - перечисление, через точку - вещественные числа) выражений в круглых скобках возвращается последнее.
Отсюда и (1, 5-1) === 4