Разные стратегии
дедупликации в разных пакетных менеджерах - это просто бомба замедленного действия, если у вас в зависимостях есть пакеты-синглтоны (часто для ноды могут встречаться).
Мне в доку реатома
пришлось добавить гайды для ключевой тройки (еще предстоит узнать что там с bun и deno), и там все у всех по разному. Еще и по версиям отличается, я указал только про то что сам знаю.
Бай зе вей, если вы попробуете запустить
npm dedupe "@package-scope/*" нпм это радостно проглотит, но задедупит вообще все нод модули. Свинюшка.
—
Зачем синглтоны вообще нужны?Примеров много, приведу только один. Мне нужно трекать создаваемые объекты со всех пакетов экосистемы, точнее выставлять им какую-то мета инфу. Писать в объекты - грязно и не производительно (портит хиден шейпы). В теории решение простое - иметь шаренную WeakMap в которой эта мета будет лежать. А где хранить эту викмапу? Она как раз должна быть глобальной и не повторяться. Только в синглтон модуле.
В комментариях напомнили,
instanceof и, в этом смысле, классы тоже идут лесом.
Даже если мы уйдем от синглтонов и будем использовать строковые ключи содержащие текущую версию - дупликация зависимостей (и, соответственно, версий) все равно это поломает.
Можно еще в globalThis писать, но это и проблема с тестами, неймспейсы и т.п.
В целом, ничего плохого в релевантном использовании синглтонов не вижу. А дублировать один и тот же код - очень не надежная практика. Увеличивает бандлсайз и замедляет разогрев кода.
Так что нет, тут нет одного простого решения. А npm и другие пакетные менеджеры плохие тем что еще не придумали и не поддержали какое-то поле
"singleton": true в package.json.
Я в следующей версии реатома буду переходить на жирный монопакет, но биндинги к фреймворкам все равно придется в отдельных пакетах держать. Поэтому проблемы дупликацией не уйдут, а просто станут реже. А еще появятся проблемы с тришейкингом...
Вот вы как думаете, если вам бандлер какой-то store.ts в вашем приложении задублирует в какой-то момент, у вас все нормально пойдет?
