Весьма популярное заблуждение. Http2 не решает проблему, которую решает бандлинг.
Давайте представим ситуацию.
У вас есть точка входа, которая импортит класс приложения, который импортит еще модуль и так далее.
Думаю, вы без труда найдете в своем коде, например, 8 уровней импортов.
Если отказаться от сборки исходников в один\несколько файлов, то возникает следующая ситуация.
Браузер получает ваш entry point, узнает что ему нужен application
Получает application, узнает, что нужен rootComponent
и так далее до 8 уровня
Каждый шаг для браузера — это отдельный запрос со всеми вытекающими. http2 позволяет переиспользовать соединение, однако задержка между вами и пользователем, как ни крути, останется.
Если предположить, что задержка 50мс, то только 400мс уйдет на то, чтобы спросить у вас файлы (не учитывая скачивание, парсинг и всё такое). Если пользователь, не дай бог, с мобильного интернета, то там уже совсем другие цифры.
Решение у этой проблемы есть — сразу говорить пользователю, какие файлы ему понадобятся. Вместо того, чтобы собирать один\несколько файлов, нам теперь нужно строить граф зависимостей, чтобы оптимизировать отправку. Можно и из булки сделать троллейбус, но зачем? Воркфлоу без потерь не упрощается.
Ну и бонусом, бандлинг позволяет очень хорошо оптимизировать код (минификация, дедупликация, tree shaking, лучше гзипуется, легче пересылается по сети)
Если вы динамически меняете что-нибудь во внешней зависимости
Так и думал что дело не чисто и тут есть зависимость со стейтом :)
Да, если в деве дубликаты критичны то вы правы. Все очень плохо :)
Мы сейчас переходим с несколько npm-модулей на множество npm-модулей, но npm link используем только если нужно одновременно разрабатывать и слинкованный пакет и тот пакет, к которому линковка исполняется.
Вот видимо про симлинки я и упустил.
А как вы используете симлинки?
У нас есть workflow работы с симлинками во время разработки. Мы линкуем также *dep-a*, *dep-b* и там действительно будут дубликаты *not-react*, но это не важно во время разработки.
Во время сборки для выкладки нет никаких симлинков до *dep-a*, *dep-b*, они ставятся из *registry* и дубликатов *not-react* нет.
Давайте еще раз, я видимо чего-то не понял.
Вот как я это вижу.
У вас есть пакет Main и есть его зависимости dep-a и dep-b.
И у пакета Main и у его зависимостей dep-a, dep-b есть third-party зависимость not-react.
Если этот not-react и в Main и в dep-a и в dep-b одинаковой версии, то при установке зависимостей Main с помощью yarnа not-react будет только в рутовом node_modules.
И при сборке webpack будет тянуть один и тот же not-react в Main, dep-a, dep-b => нет дублирования.
При этом ваши пакеты dep-a, dep-b разрабатывайте и тестируйте как хотите в их собственных репозиториях\папках.
Если у вас общая зависимость ваших зависимостей одной и той же версии, то какой-нибудь yarn, делая плоский список зависимостей, вынесет общую зависимость в рутовый node_modules.
И тогда у вас будет 1 версия общей зависимости в одном месте и вебпак не должен это дублировать.
Весьма популярное заблуждение. Http2 не решает проблему, которую решает бандлинг.
Давайте представим ситуацию.
У вас есть точка входа, которая импортит класс приложения, который импортит еще модуль и так далее.
Думаю, вы без труда найдете в своем коде, например, 8 уровней импортов.
entry => application => rootComponent => component => anotherComponent => someLibrary => lodash.
Если отказаться от сборки исходников в один\несколько файлов, то возникает следующая ситуация.
Каждый шаг для браузера — это отдельный запрос со всеми вытекающими. http2 позволяет переиспользовать соединение, однако задержка между вами и пользователем, как ни крути, останется.
Если предположить, что задержка 50мс, то только 400мс уйдет на то, чтобы спросить у вас файлы (не учитывая скачивание, парсинг и всё такое). Если пользователь, не дай бог, с мобильного интернета, то там уже совсем другие цифры.
Решение у этой проблемы есть — сразу говорить пользователю, какие файлы ему понадобятся. Вместо того, чтобы собирать один\несколько файлов, нам теперь нужно строить граф зависимостей, чтобы оптимизировать отправку. Можно и из булки сделать троллейбус, но зачем? Воркфлоу без потерь не упрощается.
Ну и бонусом, бандлинг позволяет очень хорошо оптимизировать код (минификация, дедупликация, tree shaking, лучше гзипуется, легче пересылается по сети)
Если вы динамически меняете что-нибудь во внешней зависимостиТак и думал что дело не чисто и тут есть зависимость со стейтом :)
Да, если в деве дубликаты критичны то вы правы. Все очень плохо :)
Мы сейчас переходим с несколько npm-модулей на множество npm-модулей, но npm link используем только если нужно одновременно разрабатывать и слинкованный пакет и тот пакет, к которому линковка исполняется.
А как вы используете симлинки?
У нас есть workflow работы с симлинками во время разработки. Мы линкуем также *dep-a*, *dep-b* и там действительно будут дубликаты *not-react*, но это не важно во время разработки.
Во время сборки для выкладки нет никаких симлинков до *dep-a*, *dep-b*, они ставятся из *registry* и дубликатов *not-react* нет.
Хотя в целом проблем с симлинками достаточно.
Давайте еще раз, я видимо чего-то не понял.
Вот как я это вижу.
У вас есть пакет Main и есть его зависимости dep-a и dep-b.
И у пакета Main и у его зависимостей dep-a, dep-b есть third-party зависимость not-react.
Если этот not-react и в Main и в dep-a и в dep-b одинаковой версии, то при установке зависимостей Main с помощью yarnа not-react будет только в рутовом node_modules.
И при сборке webpack будет тянуть один и тот же not-react в Main, dep-a, dep-b => нет дублирования.
При этом ваши пакеты dep-a, dep-b разрабатывайте и тестируйте как хотите в их собственных репозиториях\папках.
Если у вас общая зависимость ваших зависимостей одной и той же версии, то какой-нибудь yarn, делая плоский список зависимостей, вынесет общую зависимость в рутовый node_modules.
И тогда у вас будет 1 версия общей зависимости в одном месте и вебпак не должен это дублировать.
Фича ES6
MDN — Тегированные шаблонные строки
ES6