5 ऐप एक ही रिपॉज़िटरी में - सोलो डेवलपर का Turborepo मोनोरेपो
कई ऐप और वेब को एक रिपॉज़िटरी में मैनेज करने वाला Turborepo मोनोरेपो सेटअप। साझा कॉन्फ़िग शेयर करना, कैश से बिल्ड बचाना और ऐप-वार डिप्लॉय तक, व्यावहारिक नज़रिए से समझाया है।
मुख्य सारांश
अकेले कई ऐप बनाएं तो कॉन्फ़िग बिखर जाता है। Turborepo मोनोरेपो में eslint और tsconfig को packages से शेयर करें, turbo कैश से न बदले ऐप दोबारा बिल्ड न हों, और --filter से ऐप-वार डिप्लॉय करें।
इस पेज पर
अकेले ऐप बनाते-बनाते रिपॉज़िटरी धड़ाधड़ बढ़ती जाती हैं। एक ऐप, एक वेब, फिर एक और ऐप… और eslint कॉन्फ़िग पांच बार कॉपी-पेस्ट हो जाता है। मैंने इन्हें एक मोनोरेपो में समेट दिया।
बिखरा कॉन्फ़िग ही असली समस्या है
रिपॉज़िटरी ज़्यादा होने पर सबसे ज़्यादा दर्द कोड नहीं, कॉन्फ़िग देता है।
- eslint, prettier और tsconfig हर रिपॉज़िटरी में कॉपी करना
- एक नियम बदलो तो सबका चक्कर लगाकर ठीक करना
- साझा UI और यूटिल npm पर डालने के लिए बहुत ही छोटे लगना
मोनोरेपो इसे एक जगह से शेयर करने के तरीक़े में बदल देता है।
बुनियादी स्ट्रक्चर
apps/
├── web/ # 랜딩
├── blog/ # 이 블로그
├── wave/ # 오늘의 파도
└── ...
packages/
├── eslint-config/ # 공용 eslint
└── typescript-config/ # 공용 tsconfig
apps/* असल डिप्लॉय होने वाली चीज़ें हैं, packages/* ऐप्स के बीच शेयर होने वाला कॉन्फ़िग और कोड। हर ऐप का tsconfig.json बस ऐसे इनहेरिट करता है।
{ "extends": "@repo/typescript-config/nextjs.json" }
अब नियम सिर्फ़ packages की एक जगह पर ही ठीक करने होते हैं।
turbo कैश ही मुख्य चीज़ है
Turborepo का असली हथियार कैश है। किसी टास्क का इनपुट (सोर्स, कॉन्फ़िग) न बदले तो पिछला नतीजा वैसे का वैसा दोबारा इस्तेमाल होता है।
turbo run build # 전체 빌드(바뀐 것만 실제로 돎)
turbo run build --filter=blog # blog 앱만
turbo.json में बस टास्क के बीच की dependency और आउटपुट घोषित करने होते हैं।
{
"tasks": {
"build": { "dependsOn": ["^build"], "outputs": [".next/**"] }
}
}
दूसरे बिल्ड से "FULL TURBO" के साथ कुछ ही सेकंड में ख़त्म।
ऐप-वार डिप्लॉय
रिपॉज़िटरी एक होने पर भी डिप्लॉय ऐप-वार अलग रहता है। Docker हो तो turbo prune से उस ऐप का सिर्फ़ सबट्री काटकर इमेज को हल्का बना सकते हैं।
turbo prune blog --docker # blog + 내부 의존성만 남긴 out/ 생성
यह ब्लॉग भी इसी तरह काटकर मिनी PC पर Docker से चढ़ाया गया है। वह कहानी सेल्फ़ होस्टिंग वाली पोस्ट में है।
सार
apps/*= डिप्लॉय होने वाली चीज़ें,packages/*= साझा कॉन्फ़िग- tsconfig और eslint इनहेरिटेंस से एक जगह मैनेज
turboकैश से न बदले ऐप दोबारा बिल्ड नहीं होते--filterऔरpruneसे ऐप-वार डिप्लॉय
अगर आप अकेले कई प्रोडक्ट चलाते हैं, तो मोनोरेपो कोई लग्ज़री नहीं, बल्कि ज़िंदा रहने का औज़ार है।
अक्सर पूछे जाने वाले सवाल
कितने ऐप से मोनोरेपो फ़ायदेमंद होता है?
सिर्फ़ 2 से ज़्यादा होते ही, अगर साझा कॉन्फ़िग (eslint, tsconfig, UI) बन जाए तो फ़ायदा है। कॉन्फ़िग एक जगह ठीक करो और सारे ऐप में लागू हो जाए, यही मुख्य बात है।
बिल्ड धीमा नहीं हो जाता?
उल्टा तेज़ हो जाता है। turbo उन टास्क का नतीजा कैश करता है जिनका इनपुट नहीं बदला, इसलिए सिर्फ़ बदले हुए ऐप ही दोबारा बिल्ड होते हैं।
संबंधित लेख
- 💻 डेवलपमेंट
एक bucket के मालिक दो हों, तो आखिरी apply करने वाला जीतता है
S3 lifecycle का एक rule जोड़ते ही terraform apply fail हो गया। वजह थी वह structure जिसमें एक ही bucket की lifecycle configuration के मालिक दो resources थे। S3 lifecycle rule स्तर पर नहीं, document स्तर पर चलता है, इसलिए आखिरी विजेता दूसरे के rules चुपचाप मिटा देता है।
- 💻 डेवलपमेंट
Test हरे थे, पर notification एक बार भी नहीं गया था
Queue में job डालने वाला code पहले दिन से हर बार fail हो रहा था। error निगल लिया गया, और mock की बदौलत test हरे रहते थे। एक colon ने तीन feature चुपचाप मार दिए, यह उसी की कहानी है।
- 💻 डेवलपमेंट
अलर्ट आया कि DB मर गया। DB कभी मरा ही नहीं था
एक ही दिन में चार CRITICAL अलर्ट जमा हो गए। 504, Prisma P2028, एडमिन 500, और 'DATABASE सर्विस डाउन'। सबसे पहले RDS मेट्रिक खोले तो 21 घंटे तक CPU अधिकतम 19.7% पर बिल्कुल ठीक चल रहा था। धीमा DB नहीं था, धीमी थी वह राउंड ट्रिप जो एक रिक्वेस्ट में पच्चीस बार अटलांटिक पार करती थी। और 'डाउन' वाला अलर्ट हेल्थ चेक ने ख़ुद ही पैदा किया था।