Избавляемся от дублей пакетов в бандлах

[vintage]

А вы попробуйте не фиксировать версии зависимостей и жить сразу станет легче :-)

[Tarik02]

Или веселее не в самом хорошем смысле :-)

[vintage]

Можно каждое утро делать пробежку, а можно раз в месяц задыхаться от подъёма на пару этажей по лестнице. Вы сами решаете держать ли себя в форме и держать руку на пульсе, либо лежать и тухнуть, пока вас жёстко не сбросят с дивана.

[Tarik02]

Если это была аналогия, то намного полезнее будет делать регулярную пробежку, то-есть самому исправлять зависимости, а не упасть в рандомном месте...

[itwillwork2]

с package-lock есть ньюанс, что если в нем будут конфилкты при мердже будет очень больно

[justboris]

А npm-merge-driver пробовали?

[vintage]

Зачем мне удача, если дев в любой момент может взять тот же артефакт сборки (например, докер-контейнер) и развернув у себя в точности воспроизвести продакшен окружение, а не надеяться на то, что он переключился на правильную ревизию, что результат сборки зависит исключительно от package-lock (что далеко не всегда так, например, при выгрузке свежих данных со внешнего сервиса при сборке), что никто не забыл закоммитить актуальный package-lock, что никто нигде не подменил и не удалил содержимое пакета (что особенно актуально для приватных репозиториев), что версия ноды и нпм/ярна совпадают с продом, и тд и тп?

[vintage]

Слово «например» вы проигнорировали сознательно или бессознательно? Артефакты сборки могут быть разные, но их не может не быть, иначе вам нечего выкладывать на сервер.

[vintage]

Они минифицированы (если мы говорим про js)

Сорсмапы или отсутствие минификации.

или в бинарном виде (если про компилируемый код)

Отладочные символы.

они настроены на прод сервисы

Не надо зашивать конфиги в бинарники.

они могут содержать закрытую информацию

В отдельный артефакт.

[vintage]

Сомнительное счастье жить с протухшими зависимостями.

[Tom910]

На самом деле package-lock и не фиксированные версии это компромис, когда не все разваливается при малейшей проблеме, но и при необходимости все просто обновляется. У нас такой подход используется

[dagen]

А зачем козе баян? Всмысле зачем брать тот же артефакт сборки для отладки, если можно зафиксировать версии, что будет гарантировать, что артефакты будут собираться с нужными версиями.

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

[vintage]

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

Не будет. Примеры я привёл в комментарии, на который вы отвечали.

не может гарантировать, что в артефакте использованы нужные версии.

А это и не надо гарантировать. Гарантировать нужно лишь два инварианта:

1. На прод попало именно то, что протестировано.
2. Легко развернуть окружение идентичное проду.

Артефакты это гарантируют. Исходные коды, хоть трижды обложитесь локами, — нет.

[dagen]

Примеры я привёл в комментарии, на который вы отвечали.

Вам про козу, а вы про Ерёму. В моём комментарии про версии, до сборки артефактов, и я нигде не говорил про что-либо стороннее, запихиваемое в артефакты сборки.

А это и не надо гарантировать.

Товарищ, я нигде не говорил и про то, что артефакты не нужны (более того, артефакт в том или ином виде у всех есть). Каждый сам кузнец своего счастья, и раз вам хочется получать менее стабильную сборку артефактов — дело ваше.

[itwillwork2]

если версии не фиксировать, то например при каждом ребилде jenkins'ом вы не можете гарантировать, что все работает, ибо существует вероятность, что какой-нибудь джун запаблишил не рабочий код и сломал компонент, а npm подтянет последнюю версию полагая, что она стабильней

[vintage]

CI для того и существует, чтобы сразу понимать, что что-то сломалось. Если это ваш джун, то почему у него есть право коммитить в мастер без тестирования и код ревью? Если это разработчик внешней зависимости, то это хороший повод задуматься о том, стоит ли зависеть от кода, разрабатываемого джунами.

[itwillwork2]

ну не обязательно джун, а кто-нибудь из комманды вполне разумный, внесет изменения, которые пройдут ревью у тим лида, а в вашем проекте что-то порушится из-за них. В команде в которой множество разработчиков знания распределены, не все знают нюансы каждого пакета.

[vintage]

Отлично, он получит быструю обратную связь и тут же поправит.

[inoyakaigor]

Напомниаю, что чтобы потестить не ставя этот пакет локально/глобально можно сделать так:

npx ostap ./package.json -d

[Psychosynthesis]

У меня сейчас нет возможности проверить, скажите, пожалуйста, ostap добавлен в общий репозиторий npm? То есть, смогу ли я установить его обычным npm install -g?

[itwillwork2]

да, можно установить

npm install -g ostap

если что в репозитории есть quick start

[Psychosynthesis]

Спасибо! Классный инструмент!

[kashey]

Заметим, что единственная проблема была связана с тем что 54 пакет был использован более одного раза.
В начале надо было решить эту проблему, а потом уже менять версию пакета (просто потому, что это не всегда возможно)

[itwillwork2]

чтобы «npm ls» сработал нужна предустановка всех пакетов «npm i», а так как пересборка папки node_modules долгий процесс, то становиться невозможно перебирать различные варианты нескольких зависимостей, то есть ostap заточен на именно комбинаторную подзадачу