#bundler — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #bundler, aggregated by home.social.
-
Dependabot has resolved the remaining Bundler 4 compatibility issues. Cleaner Gemfile.lock updates, fewer CI surprises, and more predictable dependency PRs. 🚀
https://rubystacknews.com/2026/07/01/dependabot-resolves-remaining-bundler-4-compatibility-issues/
-
Need to know if a gem is actually loaded in your Bundler env, not just installed?
`Gem.loaded_specs.keys` returns every gem live in the environment, so you can grep it: `bundle exec ruby -e 'puts Gem.loaded_specs.keys.grep(/pattern/)'`
We used it to confirm `mutex_m` was not loaded before adding it to fix a dependency snag. Handy for spelunking unfamiliar codebases too.
-
Need to know if a gem is actually loaded in your Bundler env, not just installed?
`Gem.loaded_specs.keys` returns every gem live in the environment, so you can grep it: `bundle exec ruby -e 'puts Gem.loaded_specs.keys.grep(/pattern/)'`
We used it to confirm `mutex_m` was not loaded before adding it to fix a dependency snag. Handy for spelunking unfamiliar codebases too.
-
A vulnerable gem in your Gemfile.lock is a door left unlocked.
`bundler-audit` scans your lockfile against the CVE database and ranks issues Low to Critical so you patch the scary ones first.
Fix with bundle update gem --conservative, then wire it into CI so every push gets scanned.
-
A vulnerable gem in your Gemfile.lock is a door left unlocked.
`bundler-audit` scans your lockfile against the CVE database and ranks issues Low to Critical so you patch the scary ones first.
Fix with bundle update gem --conservative, then wire it into CI so every push gets scanned.
-
So #bundler added support for cooldowns.
https://blog.rubygems.org/2026/06/03/cooldown-let-new-gems-be-vetted.html
Aside: This feature is mostly developed by Claude. I haven't reviewed the code. Maybe it's fine. Maybe hsbt did actually read, understood, and guided all the code generated here. But in any case it's kinda depressing that even #Ruby, "a Programmer's Best Friend" language with goals like happiness and fun is outsourced to AI that neither can have fun, nor can be happy, nor have friends.
Anyway, I don't fully get the appeal. My main point of contention is that it's a solution trice removed from the problem.
The problem is "supply chain security". Sometimes malicious packages get pushed to package registries. It's not that much of a problem if the package is completely new as it doesn't have users yet and people tend to be cautious about new packages. But it's a problem for established projects that get compromised. They have a lot of users and many people depend on them. So a compromised package with lots of users needs very little time to get installed all over and execute its evil plots.
Someone noticed that it doesn't take much time for people to notice that something's not right. Just days, even mere hours. And they came up with a solution: what if we don't install packages right as they get released but wait, say, a week?
It's a self-defeating strategy. Imagine everyone does this. No one installs packages until they get a week old. How will people know if something's not right if no one's using the package?
The whole thing depends on someone noticing that something's not right. But the fewer people use the package the lower the chance that someone will notice. Package cooldowns work great for the small fraction of users in the beginning. But the closer cooldowns adoption goes to 100% the less effective it becomes.
It also implicitly relies on someone noticing an issue. And someone investigating it. Someone needs to a) install the package, b) notice the issue, c) investigate it. None of this is guaranteed by cooldowns.
A more explicit strategy would be that every package needs a certain amount of reviews from the users to become generally available. So every package upon release becomes available on the index for review. A package manager notifies users that a new version is available in staging and they can help it move along. The package is not available for automatic installation. There's a diff to the previous version that people can review. This is my first idea and it certainly can be improved but, as an example… Users who reviewed the package and approved it can install it right away. The package becomes generally available once a certain amount of reviews came in. E.g. 0.5% of weekly downloads, or 5, 10, 20, etc. approvals from highly trusted well known people in the community who are not involved in the project.
As opposed to cooldowns this explicitly depends on actual reviews. Unlike cooldowns, wider adoption improves efficiency: more reviews—faster availability. It also promotes the "best practice" of actually reading the code you install.
Now, to make it a thing I need a catchy name for it. I'm taking suggestions.
-
So #bundler added support for cooldowns.
https://blog.rubygems.org/2026/06/03/cooldown-let-new-gems-be-vetted.html
Aside: This feature is mostly developed by Claude. I haven't reviewed the code. Maybe it's fine. Maybe hsbt did actually read, understood, and guided all the code generated here. But in any case it's kinda depressing that even #Ruby, "a Programmer's Best Friend" language with goals like happiness and fun is outsourced to AI that neither can have fun, nor can be happy, nor have friends.
Anyway, I don't fully get the appeal. My main point of contention is that it's a solution trice removed from the problem.
The problem is "supply chain security". Sometimes malicious packages get pushed to package registries. It's not that much of a problem if the package is completely new as it doesn't have users yet and people tend to be cautious about new packages. But it's a problem for established projects that get compromised. They have a lot of users and many people depend on them. So a compromised package with lots of users needs very little time to get installed all over and execute its evil plots.
Someone noticed that it doesn't take much time for people to notice that something's not right. Just days, even mere hours. And they came up with a solution: what if we don't install packages right as they get released but wait, say, a week?
It's a self-defeating strategy. Imagine everyone does this. No one installs packages until they get a week old. How will people know if something's not right if no one's using the package?
The whole thing depends on someone noticing that something's not right. But the fewer people use the package the lower the chance that someone will notice. Package cooldowns work great for the small fraction of users in the beginning. But the closer cooldowns adoption goes to 100% the less effective it becomes.
It also implicitly relies on someone noticing an issue. And someone investigating it. Someone needs to a) install the package, b) notice the issue, c) investigate it. None of this is guaranteed by cooldowns.
A more explicit strategy would be that every package needs a certain amount of reviews from the users to become generally available. So every package upon release becomes available on the index for review. A package manager notifies users that a new version is available in staging and they can help it move along. The package is not available for automatic installation. There's a diff to the previous version that people can review. This is my first idea and it certainly can be improved but, as an example… Users who reviewed the package and approved it can install it right away. The package becomes generally available once a certain amount of reviews came in. E.g. 0.5% of weekly downloads, or 5, 10, 20, etc. approvals from highly trusted well known people in the community who are not involved in the project.
As opposed to cooldowns this explicitly depends on actual reviews. Unlike cooldowns, wider adoption improves efficiency: more reviews—faster availability. It also promotes the "best practice" of actually reading the code you install.
Now, to make it a thing I need a catchy name for it. I'm taking suggestions.
-
So #bundler added support for cooldowns.
https://blog.rubygems.org/2026/06/03/cooldown-let-new-gems-be-vetted.html
Aside: This feature is mostly developed by Claude. I haven't reviewed the code. Maybe it's fine. Maybe hsbt did actually read, understood, and guided all the code generated here. But in any case it's kinda depressing that even #Ruby, "a Programmer's Best Friend" language with goals like happiness and fun is outsourced to AI that neither can have fun, nor can be happy, nor have friends.
Anyway, I don't fully get the appeal. My main point of contention is that it's a solution trice removed from the problem.
The problem is "supply chain security". Sometimes malicious packages get pushed to package registries. It's not that much of a problem if the package is completely new as it doesn't have users yet and people tend to be cautious about new packages. But it's a problem for established projects that get compromised. They have a lot of users and many people depend on them. So a compromised package with lots of users needs very little time to get installed all over and execute its evil plots.
Someone noticed that it doesn't take much time for people to notice that something's not right. Just days, even mere hours. And they came up with a solution: what if we don't install packages right as they get released but wait, say, a week?
It's a self-defeating strategy. Imagine everyone does this. No one installs packages until they get a week old. How will people know if something's not right if no one's using the package?
The whole thing depends on someone noticing that something's not right. But the fewer people use the package the lower the chance that someone will notice. Package cooldowns work great for the small fraction of users in the beginning. But the closer cooldowns adoption goes to 100% the less effective it becomes.
It also implicitly relies on someone noticing an issue. And someone investigating it. Someone needs to a) install the package, b) notice the issue, c) investigate it. None of this is guaranteed by cooldowns.
A more explicit strategy would be that every package needs a certain amount of reviews from the users to become generally available. So every package upon release becomes available on the index for review. A package manager notifies users that a new version is available in staging and they can help it move along. The package is not available for automatic installation. There's a diff to the previous version that people can review. This is my first idea and it certainly can be improved but, as an example… Users who reviewed the package and approved it can install it right away. The package becomes generally available once a certain amount of reviews came in. E.g. 0.5% of weekly downloads, or 5, 10, 20, etc. approvals from highly trusted well known people in the community who are not involved in the project.
As opposed to cooldowns this explicitly depends on actual reviews. Unlike cooldowns, wider adoption improves efficiency: more reviews—faster availability. It also promotes the "best practice" of actually reading the code you install.
Now, to make it a thing I need a catchy name for it. I'm taking suggestions.
-
So #bundler added support for cooldowns.
https://blog.rubygems.org/2026/06/03/cooldown-let-new-gems-be-vetted.html
Aside: This feature is mostly developed by Claude. I haven't reviewed the code. Maybe it's fine. Maybe hsbt did actually read, understood, and guided all the code generated here. But in any case it's kinda depressing that even #Ruby, "a Programmer's Best Friend" language with goals like happiness and fun is outsourced to AI that neither can have fun, nor can be happy, nor have friends.
Anyway, I don't fully get the appeal. My main point of contention is that it's a solution trice removed from the problem.
The problem is "supply chain security". Sometimes malicious packages get pushed to package registries. It's not that much of a problem if the package is completely new as it doesn't have users yet and people tend to be cautious about new packages. But it's a problem for established projects that get compromised. They have a lot of users and many people depend on them. So a compromised package with lots of users needs very little time to get installed all over and execute its evil plots.
Someone noticed that it doesn't take much time for people to notice that something's not right. Just days, even mere hours. And they came up with a solution: what if we don't install packages right as they get released but wait, say, a week?
It's a self-defeating strategy. Imagine everyone does this. No one installs packages until they get a week old. How will people know if something's not right if no one's using the package?
The whole thing depends on someone noticing that something's not right. But the fewer people use the package the lower the chance that someone will notice. Package cooldowns work great for the small fraction of users in the beginning. But the closer cooldowns adoption goes to 100% the less effective it becomes.
It also implicitly relies on someone noticing an issue. And someone investigating it. Someone needs to a) install the package, b) notice the issue, c) investigate it. None of this is guaranteed by cooldowns.
A more explicit strategy would be that every package needs a certain amount of reviews from the users to become generally available. So every package upon release becomes available on the index for review. A package manager notifies users that a new version is available in staging and they can help it move along. The package is not available for automatic installation. There's a diff to the previous version that people can review. This is my first idea and it certainly can be improved but, as an example… Users who reviewed the package and approved it can install it right away. The package becomes generally available once a certain amount of reviews came in. E.g. 0.5% of weekly downloads, or 5, 10, 20, etc. approvals from highly trusted well known people in the community who are not involved in the project.
As opposed to cooldowns this explicitly depends on actual reviews. Unlike cooldowns, wider adoption improves efficiency: more reviews—faster availability. It also promotes the "best practice" of actually reading the code you install.
Now, to make it a thing I need a catchy name for it. I'm taking suggestions.
-
RubyGems 4.0.13 and Bundler 4.0.13 are out.
The most notable addition is a new cooldown mechanism for newly published gems, helping reduce the risk of supply-chain attacks.
Plus security fixes, Windows improvements, and Bundler enhancements.
Read more 👇
-
RubyGems 4.0.13 and Bundler 4.0.13 are out.
The most notable addition is a new cooldown mechanism for newly published gems, helping reduce the risk of supply-chain attacks.
Plus security fixes, Windows improvements, and Bundler enhancements.
Read more 👇
-
RubyGems 4.0.13 and Bundler 4.0.13 are out.
The most notable addition is a new cooldown mechanism for newly published gems, helping reduce the risk of supply-chain attacks.
Plus security fixes, Windows improvements, and Bundler enhancements.
Read more 👇
-
RubyGems 4.0.13 and Bundler 4.0.13 are out.
The most notable addition is a new cooldown mechanism for newly published gems, helping reduce the risk of supply-chain attacks.
Plus security fixes, Windows improvements, and Bundler enhancements.
Read more 👇
-
RubyGems 4.0.13 and Bundler 4.0.13 are out.
The most notable addition is a new cooldown mechanism for newly published gems, helping reduce the risk of supply-chain attacks.
Plus security fixes, Windows improvements, and Bundler enhancements.
Read more 👇
-
Почему ваш бандл тяжелее чем должен быть — тестирую tree shaking на 7 бандлерах
Вы уверены, что ваш бандлер вырезает неиспользуемый код? Я тоже был уверен — пока бандл Next.js проекта не оказался в два раза тяжелее, чем нужно. Прогнал одинаковый тест на webpack, rollup, vite, esbuild и Next.js — 5 из 7 ломаются на банальном barrel файле. Полез в исходники, нашёл основную причину — и она оказалась не там, где ожидал.
https://habr.com/ru/articles/1024404/
#tree_shaking #webpack #barrel_file #bundler #nextjs #rollup #vite #esbuild #оптимизация_бандла #фронтенд
-
Почему ваш бандл тяжелее чем должен быть — тестирую tree shaking на 7 бандлерах
Вы уверены, что ваш бандлер вырезает неиспользуемый код? Я тоже был уверен — пока бандл Next.js проекта не оказался в два раза тяжелее, чем нужно. Прогнал одинаковый тест на webpack, rollup, vite, esbuild и Next.js — 5 из 7 ломаются на банальном barrel файле. Полез в исходники, нашёл основную причину — и она оказалась не там, где ожидал.
https://habr.com/ru/articles/1024404/
#tree_shaking #webpack #barrel_file #bundler #nextjs #rollup #vite #esbuild #оптимизация_бандла #фронтенд
-
Почему ваш бандл тяжелее чем должен быть — тестирую tree shaking на 7 бандлерах
Вы уверены, что ваш бандлер вырезает неиспользуемый код? Я тоже был уверен — пока бандл Next.js проекта не оказался в два раза тяжелее, чем нужно. Прогнал одинаковый тест на webpack, rollup, vite, esbuild и Next.js — 5 из 7 ломаются на банальном barrel файле. Полез в исходники, нашёл основную причину — и она оказалась не там, где ожидал.
https://habr.com/ru/articles/1024404/
#tree_shaking #webpack #barrel_file #bundler #nextjs #rollup #vite #esbuild #оптимизация_бандла #фронтенд
-
André Arko helped ship Bundler 1.0, wrote The Ruby Way, and started Ruby Together. At Rubycon 2026 he'll present rv: version manager, dependency manager, and script runner for Ruby. Built in Rust.
Rimini, May 8th. -
André Arko helped ship Bundler 1.0, wrote The Ruby Way, and started Ruby Together. At Rubycon 2026 he'll present rv: version manager, dependency manager, and script runner for Ruby. Built in Rust.
Rimini, May 8th. -
I asked the AI on duckduckgo about TypeScript to include bundling, with issue URLs. I got 2 URLs of unrelated issues, and three times the same. Then:
"I’m sorry about that. The URLs I gave were placeholders and don’t correspond to the actual discussions.
The real, relevant TypeScript‑repo issues are:"And again it gave me the irrelevant URLs. 🤣
It is often surprising how quick I get useful pointers, but building an industry on this. 🤦♀️
#GPT-OSS120b #ai #typescript #bundler
-
I asked the AI on duckduckgo about TypeScript to include bundling, with issue URLs. I got 2 URLs of unrelated issues, and three times the same. Then:
"I’m sorry about that. The URLs I gave were placeholders and don’t correspond to the actual discussions.
The real, relevant TypeScript‑repo issues are:"And again it gave me the irrelevant URLs. 🤣
It is often surprising how quick I get useful pointers, but building an industry on this. 🤦♀️
#GPT-OSS120b #ai #typescript #bundler
-
One Open-source Project Daily
create a single executable out of your node.js apps
https://github.com/nexe/nexe
#1ospd #opensource #binaries #binary #bundle #bundler #cli #executable #javascript #nexe #nodejs -
One Open-source Project Daily
create a single executable out of your node.js apps
https://github.com/nexe/nexe
#1ospd #opensource #binaries #binary #bundle #bundler #cli #executable #javascript #nexe #nodejs -
One Open-source Project Daily
create a single executable out of your node.js apps
https://github.com/nexe/nexe
#1ospd #opensource #binaries #binary #bundle #bundler #cli #executable #javascript #nexe #nodejs -
One Open-source Project Daily
create a single executable out of your node.js apps
https://github.com/nexe/nexe
#1ospd #opensource #binaries #binary #bundle #bundler #cli #executable #javascript #nexe #nodejs -
One Open-source Project Daily
create a single executable out of your node.js apps
https://github.com/nexe/nexe
#1ospd #opensource #binaries #binary #bundle #bundler #cli #executable #javascript #nexe #nodejs -
Oh, look! Another mind-blowing revelation: #Bundler might eventually be as fast as uv! 🎉 But wait, it comes with a built-in excuse—a "margin #of #error." 🤔 Let's all hold our breath for this groundbreaking #speed increase... or not. 🙄
https://tenderlovemaking.com/2025/12/29/can-bundler-be-as-fast-as-uv/ #uv #revelation #margin #technews #HackerNews #ngated -
Oh, look! Another mind-blowing revelation: #Bundler might eventually be as fast as uv! 🎉 But wait, it comes with a built-in excuse—a "margin #of #error." 🤔 Let's all hold our breath for this groundbreaking #speed increase... or not. 🙄
https://tenderlovemaking.com/2025/12/29/can-bundler-be-as-fast-as-uv/ #uv #revelation #margin #technews #HackerNews #ngated -
Oh, look! Another mind-blowing revelation: #Bundler might eventually be as fast as uv! 🎉 But wait, it comes with a built-in excuse—a "margin #of #error." 🤔 Let's all hold our breath for this groundbreaking #speed increase... or not. 🙄
https://tenderlovemaking.com/2025/12/29/can-bundler-be-as-fast-as-uv/ #uv #revelation #margin #technews #HackerNews #ngated -
Oh, look! Another mind-blowing revelation: #Bundler might eventually be as fast as uv! 🎉 But wait, it comes with a built-in excuse—a "margin #of #error." 🤔 Let's all hold our breath for this groundbreaking #speed increase... or not. 🙄
https://tenderlovemaking.com/2025/12/29/can-bundler-be-as-fast-as-uv/ #uv #revelation #margin #technews #HackerNews #ngated -
Can Bundler Be as Fast as uv?
https://tenderlovemaking.com/2025/12/29/can-bundler-be-as-fast-as-uv/
-
Can Bundler Be as Fast as uv?
https://tenderlovemaking.com/2025/12/29/can-bundler-be-as-fast-as-uv/
-
Can Bundler Be as Fast as uv?
https://tenderlovemaking.com/2025/12/29/can-bundler-be-as-fast-as-uv/
-
Can Bundler Be as Fast as uv?
https://tenderlovemaking.com/2025/12/29/can-bundler-be-as-fast-as-uv/
-
Can Bundler Be as Fast as uv?
https://tenderlovemaking.com/2025/12/29/can-bundler-be-as-fast-as-uv/
-
Intlayer: альтернатива @nuxt/i18n с фокусом на оптимизации бандла
После интеграции nuxt/i18n в несколько моих проектов я пришел к однозначному выводу: это, безусловно, лучшее i18n-решение для JS-фреймворков. Его «plug&play» настройка, загрузка пространств имен (namespaces) и встроенная маршрутизация, настоящее удовольствие в работе. Однако у этого решения есть серьезная проблема: загруженные пространства имен не подвергаются «тришейкингу» (tree-shaking). Несмотря на то, что JSON-файлы могут загружаться динамически для каждой локали, Nuxt в итоге объединяет их, что означает, что файл locale/zh/about.json загружается на всех страницах.
-
Intlayer: альтернатива @nuxt/i18n с фокусом на оптимизации бандла
После интеграции nuxt/i18n в несколько моих проектов я пришел к однозначному выводу: это, безусловно, лучшее i18n-решение для JS-фреймворков. Его «plug&play» настройка, загрузка пространств имен (namespaces) и встроенная маршрутизация, настоящее удовольствие в работе. Однако у этого решения есть серьезная проблема: загруженные пространства имен не подвергаются «тришейкингу» (tree-shaking). Несмотря на то, что JSON-файлы могут загружаться динамически для каждой локали, Nuxt в итоге объединяет их, что означает, что файл locale/zh/about.json загружается на всех страницах.
-
Intlayer: альтернатива @nuxt/i18n с фокусом на оптимизации бандла
После интеграции nuxt/i18n в несколько моих проектов я пришел к однозначному выводу: это, безусловно, лучшее i18n-решение для JS-фреймворков. Его «plug&play» настройка, загрузка пространств имен (namespaces) и встроенная маршрутизация, настоящее удовольствие в работе. Однако у этого решения есть серьезная проблема: загруженные пространства имен не подвергаются «тришейкингу» (tree-shaking). Несмотря на то, что JSON-файлы могут загружаться динамически для каждой локали, Nuxt в итоге объединяет их, что означает, что файл locale/zh/about.json загружается на всех страницах.
-
Не спешите выкидывать Webpack: разбор альтернатив и реальных сценариев миграции
Привет, Хабр! На связи Никита Ли, я Frontend-разработчик в Рунити. Вокруг сборщиков последние годы кипят страсти: большинство боготворит Vite, кто-то экспериментирует с esbuild, а энтузиасты активно продвигают инструменты на базе Rust — прежде всего Rspack и SWC. На фоне этого Webpack нередко называют пережитком, который якобы тормозит развитие команд. Но жизнь реальных продуктов куда сложнее, чем пишут в соцсетях . Иногда Webpack остается единственным зрелым вариантом. А иногда — мешает и действительно требует замены. В этой статье я попробую разобраться, откуда вообще взялись сборщики и что именно происходит внутри Webpack, насколько современные альтернативы действительно готовы его заменить, почему в Рунити мы осознанно продолжаем использовать Webpack в основных продуктах и в каких случаях смена сборщика действительно имеет смысл, а в каких может обернуться лишней тратой времени и сил без ощутимой выгоды.
-
Не спешите выкидывать Webpack: разбор альтернатив и реальных сценариев миграции
Привет, Хабр! На связи Никита Ли, я Frontend-разработчик в Рунити. Вокруг сборщиков последние годы кипят страсти: большинство боготворит Vite, кто-то экспериментирует с esbuild, а энтузиасты активно продвигают инструменты на базе Rust — прежде всего Rspack и SWC. На фоне этого Webpack нередко называют пережитком, который якобы тормозит развитие команд. Но жизнь реальных продуктов куда сложнее, чем пишут в соцсетях . Иногда Webpack остается единственным зрелым вариантом. А иногда — мешает и действительно требует замены. В этой статье я попробую разобраться, откуда вообще взялись сборщики и что именно происходит внутри Webpack, насколько современные альтернативы действительно готовы его заменить, почему в Рунити мы осознанно продолжаем использовать Webpack в основных продуктах и в каких случаях смена сборщика действительно имеет смысл, а в каких может обернуться лишней тратой времени и сил без ощутимой выгоды.
-
Не спешите выкидывать Webpack: разбор альтернатив и реальных сценариев миграции
Привет, Хабр! На связи Никита Ли, я Frontend-разработчик в Рунити. Вокруг сборщиков последние годы кипят страсти: большинство боготворит Vite, кто-то экспериментирует с esbuild, а энтузиасты активно продвигают инструменты на базе Rust — прежде всего Rspack и SWC. На фоне этого Webpack нередко называют пережитком, который якобы тормозит развитие команд. Но жизнь реальных продуктов куда сложнее, чем пишут в соцсетях . Иногда Webpack остается единственным зрелым вариантом. А иногда — мешает и действительно требует замены. В этой статье я попробую разобраться, откуда вообще взялись сборщики и что именно происходит внутри Webpack, насколько современные альтернативы действительно готовы его заменить, почему в Рунити мы осознанно продолжаем использовать Webpack в основных продуктах и в каких случаях смена сборщика действительно имеет смысл, а в каких может обернуться лишней тратой времени и сил без ощутимой выгоды.
