Не сильно разбираюсь в дизайне, но, имхо, слишком много элементов в шапке, и в подвале бы выровнять все эти «блоки» элементов", в остальном — неплохо, но контраст свободного места (шапка-тело) выглядит жутко)
Давайте уже завязывайте вот это вот «const вместо let, если не присваиваете других значений», уже не смешно, это НЕ совет, и уж тем более не best practice, это (сюрприз) КОНЦЕПЦИЯ константы — постоянное, неизменяемое значения.
Это все классно, но не вредит ли подобный угол обзора зрению? Так можно получить весьма неплохое косоглазие. Есть ли какие-то общепринятые стандарты касательно угла обзора. Не из каких-то там учебников по информатике, естественно.
Вопрос распределения модулей / зависимостей по каталогам — вечен, и подход у каждого индивидуальный, все это конечно хорошо, но для стандартизации нужна инициатива не только сообщества, но и непосредственно разработчиков ОС, при чем только последние, увы, могут поставить жирную точку, иначе будут продолжать рождаться бесчисленные туториалы, в которых, например (неожиданно) — Github = Git (рекомендую к просмотру, отлично поднимает настроение. У автора, кстати, есть и платные курсы, которые хорошо продаются). По сути дела решения, предложенные автором, имхо, просто перенесут свалку из одного места в другое.
Ну и справедливости ради стоит упомянуть что все же есть какие-никакие альтернативы стандартному подходу хранения необходимых зависимостей в каталогах, например, npm-tink или yarn-pnp, но есть ряд условностей: первый является еще одной, пусть и независимой от npm, но все же зависимостью, а последний загружает модули из общего кеша пакетного менеджера (что по сути, все еще не отменяет хранение зависимостей в каталоге, хотя является, имхо, весьма достойной альтернативой).
Уверен, и в случае использования других пакетных менеджеров (нет) можно найти готовые решения, или написать свое, вопрос только в целесообразности их написания и костылей, необходимых для этого (с учетом всего вышесказанного).
Ну и справедливости ради стоит упомянуть что все же есть какие-никакие альтернативы стандартному подходу хранения необходимых зависимостей в каталогах, например, npm-tink или yarn-pnp, но есть ряд условностей: первый является еще одной, пусть и независимой от npm, но все же зависимостью, а последний загружает модули из общего кеша пакетного менеджера (что по сути, все еще не отменяет хранение зависимостей в каталоге, хотя является, имхо, весьма достойной альтернативой).
Уверен, и в случае использования других пакетных менеджеров (нет) можно найти готовые решения, или написать свое, вопрос только в целесообразности их написания и костылей, необходимых для этого (с учетом всего вышесказанного).