#monorepo — Public Fediverse posts

Just published a new comment on the NPM discussion page about upcoming phase out of 2FA tokens for direct publishing and the dire consequences this will have on many projects (including ~220 of my own packages). I'd appreciate if more people impacted by these changes are making their voices heard, before it's too late...

https://github.com/orgs/community/discussions/201329#discussioncomment-18564680

Quoting here too:

This "discussion" has been up for almost 3 months and not a single time has the NPM team here constructively responded to any of the serious concerns raised here. So I will reiterate my strong objection to these proposals once more:

These changes, however well intended, are plainly exclusionary practices and bad for what's left of open source culture!

1. Trusted publishing is excluding any form of publishing with a custom publish tool/workflow which doesn't use a CI.
2. Staged publishing, the only cited alternative proposal, is completely unusable for publishing large numbers of packages, e.g. from a monorepo. At the very least this needs to be updated to allow batch approvals/publishing of staged packages, otherwise it's completely unfeasible!

These combined effects mean people publishing multiple/many packages in one release cycle (e.g. from a monorepo) won't be able to publish to NPM anymore and will have to find alternative hosting, which will incur further effort on the maintainer side & much reduced visibility/findability of our opensource work. Thank you very much NPM team! Not!

At the very least we're all deserving some actual feedback to these issues, not just an announcement that this is how it's gonna be from January and then absolute silence for months or snarky one-liner replies when people are trying share workarounds for this fiasco and some of the largest changes ever proposed to the NPM ecosystem!

#NPM #2FA #TrustedPublishing #Monorepo #OpenSource #ThingUmbrella

Just published a new comment on the NPM discussion page about upcoming phase out of 2FA tokens for direct publishing and the dire consequences this will have on many projects (including ~220 of my own packages). I'd appreciate if more people impacted by these changes are making their voices heard, before it's too late...

https://github.com/orgs/community/discussions/201329#discussioncomment-18564680

Quoting here too:

This "discussion" has been up for almost 3 months and not a single time has the NPM team here constructively responded to any of the serious concerns raised here. So I will reiterate my strong objection to these proposals once more:

These changes, however well intended, are plainly exclusionary practices and bad for what's left of open source culture!

1. Trusted publishing is excluding any form of publishing with a custom publish tool/workflow which doesn't use a CI.
2. Staged publishing, the only cited alternative proposal, is completely unusable for publishing large numbers of packages, e.g. from a monorepo. At the very least this needs to be updated to allow batch approvals/publishing of staged packages, otherwise it's completely unfeasible!

These combined effects mean people publishing multiple/many packages in one release cycle (e.g. from a monorepo) won't be able to publish to NPM anymore and will have to find alternative hosting, which will incur further effort on the maintainer side & much reduced visibility/findability of our opensource work. Thank you very much NPM team! Not!

At the very least we're all deserving some actual feedback to these issues, not just an announcement that this is how it's gonna be from January and then absolute silence for months or snarky one-liner replies when people are trying share workarounds for this fiasco and some of the largest changes ever proposed to the NPM ecosystem!

#NPM #2FA #TrustedPublishing #Monorepo #OpenSource #ThingUmbrella

Just published a new comment on the NPM discussion page about upcoming phase out of 2FA tokens for direct publishing and the dire consequences this will have on many projects (including ~220 of my own packages). I'd appreciate if more people impacted by these changes are making their voices heard, before it's too late...

https://github.com/orgs/community/discussions/201329#discussioncomment-18564680

Quoting here too:

This "discussion" has been up for almost 3 months and not a single time has the NPM team here constructively responded to any of the serious concerns raised here. So I will reiterate my strong objection to these proposals once more:

These changes, however well intended, are plainly exclusionary practices and bad for what's left of open source culture!

1. Trusted publishing is excluding any form of publishing with a custom publish tool/workflow which doesn't use a CI.
2. Staged publishing, the only cited alternative proposal, is completely unusable for publishing large numbers of packages, e.g. from a monorepo. At the very least this needs to be updated to allow batch approvals/publishing of staged packages, otherwise it's completely unfeasible!

These combined effects mean people publishing multiple/many packages in one release cycle (e.g. from a monorepo) won't be able to publish to NPM anymore and will have to find alternative hosting, which will incur further effort on the maintainer side & much reduced visibility/findability of our opensource work. Thank you very much NPM team! Not!

At the very least we're all deserving some actual feedback to these issues, not just an announcement that this is how it's gonna be from January and then absolute silence for months or snarky one-liner replies when people are trying share workarounds for this fiasco and some of the largest changes ever proposed to the NPM ecosystem!

#NPM #2FA #TrustedPublishing #Monorepo #OpenSource #ThingUmbrella

Just published a new comment on the NPM discussion page about upcoming phase out of 2FA tokens for direct publishing and the dire consequences this will have on many projects (including ~220 of my own packages). I'd appreciate if more people impacted by these changes are making their voices heard, before it's too late...

https://github.com/orgs/community/discussions/201329#discussioncomment-18564680

Quoting here too:

This "discussion" has been up for almost 3 months and not a single time has the NPM team here constructively responded to any of the serious concerns raised here. So I will reiterate my strong objection to these proposals once more:

These changes, however well intended, are plainly exclusionary practices and bad for what's left of open source culture!

1. Trusted publishing is excluding any form of publishing with a custom publish tool/workflow which doesn't use a CI.
2. Staged publishing, the only cited alternative proposal, is completely unusable for publishing large numbers of packages, e.g. from a monorepo. At the very least this needs to be updated to allow batch approvals/publishing of staged packages, otherwise it's completely unfeasible!

These combined effects mean people publishing multiple/many packages in one release cycle (e.g. from a monorepo) won't be able to publish to NPM anymore and will have to find alternative hosting, which will incur further effort on the maintainer side & much reduced visibility/findability of our opensource work. Thank you very much NPM team! Not!

At the very least we're all deserving some actual feedback to these issues, not just an announcement that this is how it's gonna be from January and then absolute silence for months or snarky one-liner replies when people are trying share workarounds for this fiasco and some of the largest changes ever proposed to the NPM ecosystem!

#NPM #2FA #TrustedPublishing #Monorepo #OpenSource #ThingUmbrella

Just published a new comment on the NPM discussion page about upcoming phase out of 2FA tokens for direct publishing and the dire consequences this will have on many projects (including ~220 of my own packages). I'd appreciate if more people impacted by these changes are making their voices heard, before it's too late...

https://github.com/orgs/community/discussions/201329#discussioncomment-18564680

Quoting here too:

This "discussion" has been up for almost 3 months and not a single time has the NPM team here constructively responded to any of the serious concerns raised here. So I will reiterate my strong objection to these proposals once more:

These changes, however well intended, are plainly exclusionary practices and bad for what's left of open source culture!

1. Trusted publishing is excluding any form of publishing with a custom publish tool/workflow which doesn't use a CI.
2. Staged publishing, the only cited alternative proposal, is completely unusable for publishing large numbers of packages, e.g. from a monorepo. At the very least this needs to be updated to allow batch approvals/publishing of staged packages, otherwise it's completely unfeasible!

These combined effects mean people publishing multiple/many packages in one release cycle (e.g. from a monorepo) won't be able to publish to NPM anymore and will have to find alternative hosting, which will incur further effort on the maintainer side & much reduced visibility/findability of our opensource work. Thank you very much NPM team! Not!

At the very least we're all deserving some actual feedback to these issues, not just an announcement that this is how it's gonna be from January and then absolute silence for months or snarky one-liner replies when people are trying share workarounds for this fiasco and some of the largest changes ever proposed to the NPM ecosystem!

#NPM #2FA #TrustedPublishing #Monorepo #OpenSource #ThingUmbrella

[Перевод] Трагедия версионирования ПО

As we say, two of the most complicated problems in software are naming things and versioning software Когда-то в кулуарах Devoxx Belgium нечто подобное сказал Томас Вюртингер, лид проекта GraalVM, поясняя детали вот этой нашумевшей статьи . Это не точная цитата, а лишь фраза, призванная обратить внимание на проблему. О ней сегодня мы и поговорим. Всем привет! Меня зовут Михаил Поливаха, я являюсь техническим лидером Open Source проекта Axelix . Довольно давно я хотел написать небольшую статью про версионирование ПО в целом, поскольку, как мне кажется, этой теме незаслуженно достаётся мало внимания. Для многих версионирование заканчивается на SemVer, но тема гораздо, гораздо более обширна, чем может показаться.

https://habr.com/ru/companies/spring_aio/articles/1084716/

#semver #calver #lockstep #release_train #axelix #monorepo #backward_compatibility #springboot #sdlc

[Перевод] Трагедия версионирования ПО

As we say, two of the most complicated problems in software are naming things and versioning software Когда-то в кулуарах Devoxx Belgium нечто подобное сказал Томас Вюртингер, лид проекта GraalVM, поясняя детали вот этой нашумевшей статьи . Это не точная цитата, а лишь фраза, призванная обратить внимание на проблему. О ней сегодня мы и поговорим. Всем привет! Меня зовут Михаил Поливаха, я являюсь техническим лидером Open Source проекта Axelix . Довольно давно я хотел написать небольшую статью про версионирование ПО в целом, поскольку, как мне кажется, этой теме незаслуженно достаётся мало внимания. Для многих версионирование заканчивается на SemVer, но тема гораздо, гораздо более обширна, чем может показаться.

https://habr.com/ru/companies/spring_aio/articles/1084716/

#semver #calver #lockstep #release_train #axelix #monorepo #backward_compatibility #springboot #sdlc

[Перевод] Трагедия версионирования ПО

As we say, two of the most complicated problems in software are naming things and versioning software Когда-то в кулуарах Devoxx Belgium нечто подобное сказал Томас Вюртингер, лид проекта GraalVM, поясняя детали вот этой нашумевшей статьи . Это не точная цитата, а лишь фраза, призванная обратить внимание на проблему. О ней сегодня мы и поговорим. Всем привет! Меня зовут Михаил Поливаха, я являюсь техническим лидером Open Source проекта Axelix . Довольно давно я хотел написать небольшую статью про версионирование ПО в целом, поскольку, как мне кажется, этой теме незаслуженно достаётся мало внимания. Для многих версионирование заканчивается на SemVer, но тема гораздо, гораздо более обширна, чем может показаться.

https://habr.com/ru/companies/spring_aio/articles/1084716/

#semver #calver #lockstep #release_train #axelix #monorepo #backward_compatibility #springboot #sdlc

🧩 Micro-frontend architecture: honest take

Pros:
✅ Independent deployment per team
✅ Tech stack freedom
✅ Clear ownership

Cons:
❌ Bundle size bloat (multiple React instances)
❌ Shared state is a nightmare
❌ Integration testing hell
❌ Overkill for <10 dev teams

Verdict: Only worth it at 50+ devs with distinct product areas.

Monorepo > micro-frontends for most teams.

#Frontend #WebDev #Architecture #React #FullStack #Monorepo

🧩 Micro-frontend architecture: honest take

Pros:
✅ Independent deployment per team
✅ Tech stack freedom
✅ Clear ownership

Cons:
❌ Bundle size bloat (multiple React instances)
❌ Shared state is a nightmare
❌ Integration testing hell
❌ Overkill for <10 dev teams

Verdict: Only worth it at 50+ devs with distinct product areas.

Monorepo > micro-frontends for most teams.

#Frontend #WebDev #Architecture #React #FullStack #Monorepo

🧩 Micro-frontend architecture: honest take

Pros:
✅ Independent deployment per team
✅ Tech stack freedom
✅ Clear ownership

Cons:
❌ Bundle size bloat (multiple React instances)
❌ Shared state is a nightmare
❌ Integration testing hell
❌ Overkill for <10 dev teams

Verdict: Only worth it at 50+ devs with distinct product areas.

Monorepo > micro-frontends for most teams.

#Frontend #WebDev #Architecture #React #FullStack #Monorepo

🧩 Micro-frontend architecture: honest take

Pros:
✅ Independent deployment per team
✅ Tech stack freedom
✅ Clear ownership

Cons:
❌ Bundle size bloat (multiple React instances)
❌ Shared state is a nightmare
❌ Integration testing hell
❌ Overkill for <10 dev teams

Verdict: Only worth it at 50+ devs with distinct product areas.

Monorepo > micro-frontends for most teams.

#Frontend #WebDev #Architecture #React #FullStack #Monorepo

🧩 Micro-frontend architecture: honest take

Pros:
✅ Independent deployment per team
✅ Tech stack freedom
✅ Clear ownership

Cons:
❌ Bundle size bloat (multiple React instances)
❌ Shared state is a nightmare
❌ Integration testing hell
❌ Overkill for <10 dev teams

Verdict: Only worth it at 50+ devs with distinct product areas.

Monorepo > micro-frontends for most teams.

#Frontend #WebDev #Architecture #React #FullStack #Monorepo

Монорепозиторий с поддержкой Vite, TS, ESM и абсолютных импортов без расширений с использованием «subpath imports»

Абсолютные импорты без расширений в ESM-монорепозитории. Настраиваем Vite, TypeScript и автоимпорты в IDE (VSCode) с помощью “subpath imports”. Разрешаем конфликты настроек без костылей. Добавляем приоритет автоимпорта папок в качестве модулей, при наличии “index.ts”. Настраиваем Vite и TypeScript на работу с исходниками компилируемой библиотеки в dev-режиме.

https://habr.com/ru/articles/1074190/

#vite #typescript #esm #subpath_imports #intellisense #autoimport #directorymodules #tsdown #monorepo #path_aliases

Монорепозиторий с поддержкой Vite, TS, ESM и абсолютных импортов без расширений с использованием «subpath imports»

Абсолютные импорты без расширений в ESM-монорепозитории. Настраиваем Vite, TypeScript и автоимпорты в IDE (VSCode) с помощью “subpath imports”. Разрешаем конфликты настроек без костылей. Добавляем приоритет автоимпорта папок в качестве модулей, при наличии “index.ts”. Настраиваем Vite и TypeScript на работу с исходниками компилируемой библиотеки в dev-режиме.

https://habr.com/ru/articles/1074190/

#vite #typescript #esm #subpath_imports #intellisense #autoimport #directorymodules #tsdown #monorepo #path_aliases

Монорепозиторий с поддержкой Vite, TS, ESM и абсолютных импортов без расширений с использованием «subpath imports»

Абсолютные импорты без расширений в ESM-монорепозитории. Настраиваем Vite, TypeScript и автоимпорты в IDE (VSCode) с помощью “subpath imports”. Разрешаем конфликты настроек без костылей. Добавляем приоритет автоимпорта папок в качестве модулей, при наличии “index.ts”. Настраиваем Vite и TypeScript на работу с исходниками компилируемой библиотеки в dev-режиме.

https://habr.com/ru/articles/1074190/

#vite #typescript #esm #subpath_imports #intellisense #autoimport #directorymodules #tsdown #monorepo #path_aliases

[Перевод] One Branch To Rule Them All

Всем привет. На связи Михаил, технический лидер проекта Axelix . Я уже довольно давно хотел написать небольшую статью о нашей модели ветвления git в надежде, что она может пригодиться и другим. В мире существует немало стратегий ветвления git, например: Gitflow, GitHub-flow, Trunk-Based-Development (TBD) и так далее. По своему опыту могу сказать, что команды обычно не берут какую-либо стратегию в точности в её исходной форме, а либо изобретают нечто совершенно новое сами, либо просто берут, к примеру, уже упомянутый GitFlow и адаптируют его под свои нужды.

https://habr.com/ru/companies/spring_aio/articles/1072386/

#axelix #git #semver #версионирование #gitflow #tbd #trunkbaseddevelopment #github_flow #monorepo #lockstep

[Перевод] One Branch To Rule Them All

Всем привет. На связи Михаил, технический лидер проекта Axelix . Я уже довольно давно хотел написать небольшую статью о нашей модели ветвления git в надежде, что она может пригодиться и другим. В мире существует немало стратегий ветвления git, например: Gitflow, GitHub-flow, Trunk-Based-Development (TBD) и так далее. По своему опыту могу сказать, что команды обычно не берут какую-либо стратегию в точности в её исходной форме, а либо изобретают нечто совершенно новое сами, либо просто берут, к примеру, уже упомянутый GitFlow и адаптируют его под свои нужды.

https://habr.com/ru/companies/spring_aio/articles/1072386/

#axelix #git #semver #версионирование #gitflow #tbd #trunkbaseddevelopment #github_flow #monorepo #lockstep

[Перевод] One Branch To Rule Them All

Всем привет. На связи Михаил, технический лидер проекта Axelix . Я уже довольно давно хотел написать небольшую статью о нашей модели ветвления git в надежде, что она может пригодиться и другим. В мире существует немало стратегий ветвления git, например: Gitflow, GitHub-flow, Trunk-Based-Development (TBD) и так далее. По своему опыту могу сказать, что команды обычно не берут какую-либо стратегию в точности в её исходной форме, а либо изобретают нечто совершенно новое сами, либо просто берут, к примеру, уже упомянутый GitFlow и адаптируют его под свои нужды.

https://habr.com/ru/companies/spring_aio/articles/1072386/

#axelix #git #semver #версионирование #gitflow #tbd #trunkbaseddevelopment #github_flow #monorepo #lockstep

Вторая копия Vue: как лишняя строка в lockfile повесила Chromium

Может ли лишняя запись в yarn.lock повесить браузер? Наша прожила в репозитории три месяца, не привлекая внимания, а потом ночью после релиза положила прод вечным лоадером - причём только в Chromium. Рассказываю, как мы шли к разгадке через ложные следы и что в итоге оказалось в рантайме.

https://habr.com/ru/articles/1068420/

#vue_3 #module_federation #yarn #monorepo #yarnlock #chromium #микрофронтенды #отладка

Вторая копия Vue: как лишняя строка в lockfile повесила Chromium

Может ли лишняя запись в yarn.lock повесить браузер? Наша прожила в репозитории три месяца, не привлекая внимания, а потом ночью после релиза положила прод вечным лоадером - причём только в Chromium. Рассказываю, как мы шли к разгадке через ложные следы и что в итоге оказалось в рантайме.

https://habr.com/ru/articles/1068420/

#vue_3 #module_federation #yarn #monorepo #yarnlock #chromium #микрофронтенды #отладка

Вторая копия Vue: как лишняя строка в lockfile повесила Chromium

Может ли лишняя запись в yarn.lock повесить браузер? Наша прожила в репозитории три месяца, не привлекая внимания, а потом ночью после релиза положила прод вечным лоадером - причём только в Chromium. Рассказываю, как мы шли к разгадке через ложные следы и что в итоге оказалось в рантайме.

https://habr.com/ru/articles/1068420/

#vue_3 #module_federation #yarn #monorepo #yarnlock #chromium #микрофронтенды #отладка

For the poor souls who burn in #monorepo hell, this is godsent:
Stacked pull requests are now in public preview
https://github.blog/changelog/2026-07-30-stacked-pull-requests-are-now-in-public-preview/
#GitHub

For the poor souls who burn in #monorepo hell, this is godsent:
Stacked pull requests are now in public preview
https://github.blog/changelog/2026-07-30-stacked-pull-requests-are-now-in-public-preview/
#GitHub

For the poor souls who burn in #monorepo hell, this is godsent:
Stacked pull requests are now in public preview
https://github.blog/changelog/2026-07-30-stacked-pull-requests-are-now-in-public-preview/
#GitHub

For the poor souls who burn in #monorepo hell, this is godsent:
Stacked pull requests are now in public preview
https://github.blog/changelog/2026-07-30-stacked-pull-requests-are-now-in-public-preview/
#GitHub

For the poor souls who burn in #monorepo hell, this is godsent:
Stacked pull requests are now in public preview
https://github.blog/changelog/2026-07-30-stacked-pull-requests-are-now-in-public-preview/
#GitHub

TypeScript 7 перенесли на Go. Проверяем, действительно ли он быстрее в десять раз

Есть одно предложение, которое за последние месяцы перепечатали, кажется, все. Вот оно, в переводе с блога TypeScript: 📣 Заявка. «Проверка типов проекта VS Code (около 1,5 млн строк) ускорилась с 77.8 с до 7.5 с». Итог, который команда вынесла в заголовок, — «примерно в 10 раз быстрее» . Это не обзор релиза. Это попытка воспроизвести один график — не на кодовой базе Microsoft, а на монорепо, которое я собрал специально под замер, двумя компиляторами на одной машине, с показом каждой цифры и с репозиторием, где любую из них можно получить командой pnpm bench . Сразу спойлер: да, TS7 быстрее, и заметно. Но „в десять раз“ живёт в одном конкретном месте, испаряется в другом, а кое-что важное в 7.0 пока не вошло — и это „кое-что“ важнее скорости. Главная мысль: «10×» — это про чекер на большом проекте, а не про весь ваш день. TS7 радикально ускоряет проверку типов и режет память, и замеры это подтверждают. Но в 7.0 отсутствует стабильный программный API — а с ним из сборки выпадают кастомные трансформеры, tsserver-плагины и типизированный линтинг. Поэтому вопрос миграции — не «стало ли быстрее», а «завязана ли ваша сборка на этот API».

https://habr.com/ru/articles/1057640/

#TypeScript_7 #TypeScript_Go #TypeScript_Compiler #tsc #Compiler_API #TypeScript_performance #benchmark #monorepo #typecheck #frontend_tooling

TypeScript 7 перенесли на Go. Проверяем, действительно ли он быстрее в десять раз

Есть одно предложение, которое за последние месяцы перепечатали, кажется, все. Вот оно, в переводе с блога TypeScript: 📣 Заявка. «Проверка типов проекта VS Code (около 1,5 млн строк) ускорилась с 77.8 с до 7.5 с». Итог, который команда вынесла в заголовок, — «примерно в 10 раз быстрее» . Это не обзор релиза. Это попытка воспроизвести один график — не на кодовой базе Microsoft, а на монорепо, которое я собрал специально под замер, двумя компиляторами на одной машине, с показом каждой цифры и с репозиторием, где любую из них можно получить командой pnpm bench . Сразу спойлер: да, TS7 быстрее, и заметно. Но „в десять раз“ живёт в одном конкретном месте, испаряется в другом, а кое-что важное в 7.0 пока не вошло — и это „кое-что“ важнее скорости. Главная мысль: «10×» — это про чекер на большом проекте, а не про весь ваш день. TS7 радикально ускоряет проверку типов и режет память, и замеры это подтверждают. Но в 7.0 отсутствует стабильный программный API — а с ним из сборки выпадают кастомные трансформеры, tsserver-плагины и типизированный линтинг. Поэтому вопрос миграции — не «стало ли быстрее», а «завязана ли ваша сборка на этот API».

https://habr.com/ru/articles/1057640/

#TypeScript_7 #TypeScript_Go #TypeScript_Compiler #tsc #Compiler_API #TypeScript_performance #benchmark #monorepo #typecheck #frontend_tooling

TypeScript 7 перенесли на Go. Проверяем, действительно ли он быстрее в десять раз

Есть одно предложение, которое за последние месяцы перепечатали, кажется, все. Вот оно, в переводе с блога TypeScript: 📣 Заявка. «Проверка типов проекта VS Code (около 1,5 млн строк) ускорилась с 77.8 с до 7.5 с». Итог, который команда вынесла в заголовок, — «примерно в 10 раз быстрее» . Это не обзор релиза. Это попытка воспроизвести один график — не на кодовой базе Microsoft, а на монорепо, которое я собрал специально под замер, двумя компиляторами на одной машине, с показом каждой цифры и с репозиторием, где любую из них можно получить командой pnpm bench . Сразу спойлер: да, TS7 быстрее, и заметно. Но „в десять раз“ живёт в одном конкретном месте, испаряется в другом, а кое-что важное в 7.0 пока не вошло — и это „кое-что“ важнее скорости. Главная мысль: «10×» — это про чекер на большом проекте, а не про весь ваш день. TS7 радикально ускоряет проверку типов и режет память, и замеры это подтверждают. Но в 7.0 отсутствует стабильный программный API — а с ним из сборки выпадают кастомные трансформеры, tsserver-плагины и типизированный линтинг. Поэтому вопрос миграции — не «стало ли быстрее», а «завязана ли ваша сборка на этот API».

https://habr.com/ru/articles/1057640/

#TypeScript_7 #TypeScript_Go #TypeScript_Compiler #tsc #Compiler_API #TypeScript_performance #benchmark #monorepo #typecheck #frontend_tooling

And as always: #Monorepo & #monolith all the way down. The fact that my app, about page, settings (including live elements), release notes, changelog are all in sync is only ever possible thanks to the these two.
Any other way will inevitably fail at some point.

And as always: #Monorepo & #monolith all the way down. The fact that my app, about page, settings (including live elements), release notes, changelog are all in sync is only ever possible thanks to the these two.
Any other way will inevitably fail at some point.

And as always: #Monorepo & #monolith all the way down. The fact that my app, about page, settings (including live elements), release notes, changelog are all in sync is only ever possible thanks to the these two.
Any other way will inevitably fail at some point.

And as always: #Monorepo & #monolith all the way down. The fact that my app, about page, settings (including live elements), release notes, changelog are all in sync is only ever possible thanks to the these two.
Any other way will inevitably fail at some point.

And as always: #Monorepo & #monolith all the way down. The fact that my app, about page, settings (including live elements), release notes, changelog are all in sync is only ever possible thanks to the these two.
Any other way will inevitably fail at some point.

“Evolving A Codebase At Google Scale” [2024], Laurent Le Brun (https://laurent.le-brun.eu/blog/evolving-a-codebase-at-google-scale).

#Google #Programming #Bazel #Starlark #SoftwareEngineering #MonoRepo #LargeScaleChanges #ContinuousIntegration

“Evolving A Codebase At Google Scale” [2024], Laurent Le Brun (https://laurent.le-brun.eu/blog/evolving-a-codebase-at-google-scale).

#Google #Programming #Bazel #Starlark #SoftwareEngineering #MonoRepo #LargeScaleChanges #ContinuousIntegration

“Evolving A Codebase At Google Scale” [2024], Laurent Le Brun (https://laurent.le-brun.eu/blog/evolving-a-codebase-at-google-scale).

#Google #Programming #Bazel #Starlark #SoftwareEngineering #MonoRepo #LargeScaleChanges #ContinuousIntegration

“Evolving A Codebase At Google Scale” [2024], Laurent Le Brun (https://laurent.le-brun.eu/blog/evolving-a-codebase-at-google-scale).

#Google #Programming #Bazel #Starlark #SoftwareEngineering #MonoRepo #LargeScaleChanges #ContinuousIntegration

#Dropbox cut its backend monorepo from 87GB → 20GB.📉

In collaboration with #GitHub, they fixed a massive bottleneck by optimizing Git delta compression.

The impact:
• Reduced clone times
• Improved CI performance
• Boosted developer velocity

Learn more 👉 https://bit.ly/3R9pSfZ

#InfoQ #SoftwareArchitecture #Git #Monorepo #Optimization

#Dropbox cut its backend monorepo from 87GB → 20GB.📉

In collaboration with #GitHub, they fixed a massive bottleneck by optimizing Git delta compression.

The impact:
• Reduced clone times
• Improved CI performance
• Boosted developer velocity

Learn more 👉 https://bit.ly/3R9pSfZ

#InfoQ #SoftwareArchitecture #Git #Monorepo #Optimization

#Dropbox cut its backend monorepo from 87GB → 20GB.📉

In collaboration with #GitHub, they fixed a massive bottleneck by optimizing Git delta compression.

The impact:
• Reduced clone times
• Improved CI performance
• Boosted developer velocity

Learn more 👉 https://bit.ly/3R9pSfZ

#InfoQ #SoftwareArchitecture #Git #Monorepo #Optimization

#Dropbox cut its backend monorepo from 87GB → 20GB.📉

In collaboration with #GitHub, they fixed a massive bottleneck by optimizing Git delta compression.

The impact:
• Reduced clone times
• Improved CI performance
• Boosted developer velocity

Learn more 👉 https://bit.ly/3R9pSfZ

#InfoQ #SoftwareArchitecture #Git #Monorepo #Optimization

#Dropbox cut its backend monorepo from 87GB → 20GB.📉

In collaboration with #GitHub, they fixed a massive bottleneck by optimizing Git delta compression.

The impact:
• Reduced clone times
• Improved CI performance
• Boosted developer velocity

Learn more 👉 https://bit.ly/3R9pSfZ

#InfoQ #SoftwareArchitecture #Git #Monorepo #Optimization

Reducing our #monorepo size to improve developer velocity

https://dropbox.tech/infrastructure/reducing-our-monorepo-size-to-improve-developer-velocity

#GitHub #Dropbox

Reducing our #monorepo size to improve developer velocity

https://dropbox.tech/infrastructure/reducing-our-monorepo-size-to-improve-developer-velocity

#GitHub #Dropbox

Reducing our #monorepo size to improve developer velocity

https://dropbox.tech/infrastructure/reducing-our-monorepo-size-to-improve-developer-velocity

#GitHub #Dropbox

Reducing our #monorepo size to improve developer velocity

https://dropbox.tech/infrastructure/reducing-our-monorepo-size-to-improve-developer-velocity

#GitHub #Dropbox

Reducing our #monorepo size to improve developer velocity

https://dropbox.tech/infrastructure/reducing-our-monorepo-size-to-improve-developer-velocity

#GitHub #Dropbox

Using Changesets in a polyglot monorepo

https://luke.hsiao.dev/blog/changesets-polyglot-monorepo/

#HackerNews #changesets #polyglot #monorepo #softwaredevelopment #devops #programming

Using Changesets in a polyglot monorepo

https://luke.hsiao.dev/blog/changesets-polyglot-monorepo/

#HackerNews #changesets #polyglot #monorepo #softwaredevelopment #devops #programming

Using Changesets in a polyglot monorepo

https://luke.hsiao.dev/blog/changesets-polyglot-monorepo/

#HackerNews #changesets #polyglot #monorepo #softwaredevelopment #devops #programming

Using Changesets in a polyglot monorepo

https://luke.hsiao.dev/blog/changesets-polyglot-monorepo/

#HackerNews #changesets #polyglot #monorepo #softwaredevelopment #devops #programming

Using Changesets in a polyglot monorepo

https://luke.hsiao.dev/blog/changesets-polyglot-monorepo/

#HackerNews #changesets #polyglot #monorepo #softwaredevelopment #devops #programming

Tour d'horizon des workspaces npm.

🔗 https://wasp.sh/blog/2026/03/25/gentle-intro-npm-workspaces

#npm #workspace #monorepo #NodeJS

Tour d'horizon des workspaces npm.

🔗 https://wasp.sh/blog/2026/03/25/gentle-intro-npm-workspaces

#npm #workspace #monorepo #NodeJS

Tour d'horizon des workspaces npm.

🔗 https://wasp.sh/blog/2026/03/25/gentle-intro-npm-workspaces

#npm #workspace #monorepo #NodeJS

Tour d'horizon des workspaces npm.

🔗 https://wasp.sh/blog/2026/03/25/gentle-intro-npm-workspaces

#npm #workspace #monorepo #NodeJS

🚀 Heading to Istanbul for @teknasyon meetup on April 11th!

I'll be talking about Monorepos - from architecture to tooling, CI/CD strategies, and real-world migration stories.

6 years of monorepo experience packed into one talk 📦

See you there! 👉 https://meetup.teknasyon.com/

#monorepo #javascript #devops #istanbul

🚀 Heading to Istanbul for @teknasyon meetup on April 11th!

I'll be talking about Monorepos - from architecture to tooling, CI/CD strategies, and real-world migration stories.

6 years of monorepo experience packed into one talk 📦

See you there! 👉 https://meetup.teknasyon.com/

#monorepo #javascript #devops #istanbul