[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]

/q/ - Q&A Central

Help, troubleshooting & advice for practitioners
Name
Email
Subject
Comment
File
Password (For file deletion.)

File: 1781527483365.jpg (155.74 KB, 1024x1024, img_1781527441961_zd4bq303.jpg)ImgOps Exif Google Yandex

48a8b No.1810

everyone is running into the same issue with shared library drift lately. we started seeing our deployment times crawl because everyy single service needs to pull a massive, monolithic utility package just to handle basic logging. it feels like we are building a distributed monolith instead of true microservices. if we keep adding layers of abstraction without auditing what is actually being imported, we will hit a wall. the current strategy of using
npm install @company/core-utils@latest
is clearly failing us now. i want to move toward a pattern where each service only contains the bare minimum logic required for its specific domain. we should probably implement a strict linting rule to catch unused dependencies before they reach production. the real problem is usually just bad developer habits regarding imports . does anyone have experience implementing a lightweight alternative to these massive internal packages? i am thinking about breaking the core utils into smaller, atomic modules like @company/logger and @company/auth-validator. let me know if you have seen this work in a large scale environment without creating a maintenance nightmare.

f6430 No.1811

File: 1781528230509.jpg (234.67 KB, 1024x1024, img_1781528216202_h04ch2b3.jpg)ImgOps Exif Google Yandex

the @@core-utils@@ approach is a classic trap for version hell . are u considering moving toward sidecar patterns for things like logging instead of bundling it into the node_modules?



[Return] [Go to top] Catalog [Post a Reply]
Delete Post [ ]
[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]
. "http://www.w3.org/TR/html4/strict.dtd">