Комментарии 20
А вот если бы у вас в памяти всплыли эти статьи, то сего поста бы и не появилось:
Всегда брал, и тащил какую-нибудь большую крутую универсальную библиотеку, даже если оттуда мне нужна только одна функция.
А может дело не в связях, а в оформлении и хранении ранее написанного кода?
Я решаю это довольно просто: создаю репозиторий (публичный или приватный разницы нет) и оттуда все написанное добро подтягиваю.
Можно и в публичный npm публиковать свои ведосипеды. Так даже лучше, я думаю, так как социальная ответственность возникает, что ли. Приходится документировать код, писать тесты. И как начинаю новый проект, делаю npm install личных библиотек, и не приходится заново писать эти функции. Лишнее все тришейкаю через esbuild или иные утилиты. ES-модули рулят, короче.
Этот вариант точно лучше, чем тянуть в проект стороннюю либу, если тебе нужны лишь пара функций из неё. Как минимум, отсутствием зависимости от настроения разрабов этой самой либы.
Проблемы начинаются, когда базовый репо пухнет от кол-ва функций, которые используются лишь в части проектов. Т.е., в этих проектах мне нужна только работа с датами, в этих - только шифрование, а в этих - преобразование строк.
Можно сделать множество базовых репозиториев и получаем зависимость между проектами через базовые репо - когда ты не можешь спокойно править код в базовом репо, не проверив все зависимые проекты на "рухнет - не рухнет". Или можно тупо скопипастить (если код функции небольшой и довольно стабильный) и разорвать зависимость. Тогда в каждом проекте собирается свой набор "базового функционала".
Однозначно хорошего решения тут нет, всё зависит от всякого. У себя я часть кода держу в базовых репо, часть - копипащу, а часть - делаю в проекте обёртку для кода из базового репо и использую в проекте только обёртку. Зависимость от базы остаётся, но дальше обёртки не проходит.
И, да - es-модули рулят (y)
Забавно, когда показываешь человеку решение всех его проблем, а он делает вид, что ничего не услышал, и продолжает с упоением рассказывать про эти проблемы. Лучше быть экспертом в создании проблем, чем новичком в их решении?
Забавно, когда показываешь человеку решение всех его проблем...
Вот именно поэтому он и не слышит. Сложные задачи имеют более одного правильного решния, оптимальность которых зависит от применяемых критериев оценки. Заявление же, что кто-то нашёл "решение всех его проблем" - это лажа. Ну, как очередное изобретение "вечного двигателя".
И я, к тому же, предпочитаю "чистый JS". Просто не люблю транспиляцию, и всё тут. А ваш МАМ - "директория, внутри которой могут быть исходники на самых разных языках" (с) Стар я уже, изучать "самые разные языки", мне бы в одном ЯП удержаться ;)
Примечательно, что именно в МАМ вам и не нужна транспиляция для сборки бандла из исходников на чистом JS.
не нужна транспиляция для сборки бандла из исходников на чистом JS
Вы так пишете, как будто это заслуга МАМ :) По-моему, для того, чтобы собрать JS-бандл из JS-исходников, транспиляция вообще нигде не нужна. Если только вы не собираетесь сдвинуть версию JS. Но я, кстати, и бандлы не очень. Предпочитаю в браузере видеть ту же структуру файлов и тот же код, что и в IDE:
Зачем же ещё производители воткнули гигабайты и гигагерцы в оконечные устройства юзеров, как не для моего удобства? :)
Если перед строкой с html ставить /* html */, то будет вообще красота (подсветка html в коде js).
https://marketplace.visualstudio.com/items?itemName=Tobermory.es6-string-html
Ох уж эти эксперты, которые не знают, что из esm до сих пор нельзя собрать бандл без транспиляции.
Я уж молчу о сомнительном удобстве IoC через DI, вёрстки без подсветки синтаксиса, и развесистых JSDoc-ов, вместо нормальных тайпингов.
А я и не говорил, что я эксперт в сборке бандлов, скорее я говорил наоборот - что предпочитаю обходиться без них :)
И чем это вам не угодил "IoC через DI"? Какой тип IoC используете вы?
Вёрстка, кстати, в PhpStorm подсвечивается - у меня и скрин выше приведён.
Остаётся вопрос JSDoc'ов, но из двух зол (JSDoc'и или транспиляция) я выбрал первое, а вы - второе. Так что это моя плата за возможность видеть везде один и тот же код. Вы привыкли к транспиляции, а я - к JSDoc'ам.
Сорсмапы вроде бы уже изобрели.
Я просто когда-то давно читал "Dependency Injection, Principles, Practices, and Patterns", так там "Ambient Context" назван анти-паттерном. Вы, наверное, читали другую книгу - "Ambient Context, Principles, Practices, and Patterns" :)
Не читайте глупых книг, которые статические поля классов называют контекстами.
Я так понимаю, что одна звёздочка этой "глупой книге" на Амазоне от вас прилетела :)
Лично мне "IoC через DI" более чем удобно. Я и до середины возможностей этой технологии пока не добрался. Может быть потом, когда уткнусь в её ограничения, я переосмыслю накопленный опыт и перейду к "Контексту Окружения", но пока так.
Искренне надеюсь, что на Хабре это был технический сбой, а не разумная деятельность. Первый раз столкнулся, что минимум три коммента исчезли, оставив только следы в почтовых ящиках.
В общем, я у себя и Ambient Context использую, но только там, где не имею возможности работать с конструктором объекта напрямую. Например, я таким образом внедряю у себя во все vue-компоненты имя namespapce'а в котором они определяются, для последующего использования с i18next (нахождение пакета с переводами).
return {
teq: {package: DEF.SHARED.NAME},
name: NS,
template,
components: {},
data() {
return { };
},
computed: {},
...
};Это создание шаблона vue-компонента для последующего конструирования отдельных экземпляров на его основе. Свойство teq - нестандартное для vue, я через него передаю в шаблон всю нужную мне информацию, которая становится доступной в каждом экземпляре через this.$options.teq
Но это об безысходности - я не разработчик vue, а это был самый лёгкий способ внедриться, пусть и не самый правильный. Так и осталось.
Я говорю о том, что полностью решил проблему разрастания кода. Даже ничего копипастить не нужно. Причем я пишу код на чистом js с использованием jsdoc с typescript (директива в коде @ts-check). У меня код самый нативный при этом. Модули можно запускать со сборкой и без нее.
Так вот когда моя база разрастается, то я юзаю сборщик, чтобы он выпилил неиспользуемые функции. Таким образом бандл получается крохотный. Ну, я и пишу так, чтобы это все тришейкалось.
И всегда пишу тесты для сорсов и для бандлов.
KAN и веб-программирование