टर्बोरेपो मोनोरेपो गाइड: मल्टी-ऐप प्रोजेक्ट्स का प्रबंधन
**कई एप्लिकेशन और साझा पैकेज वाले मोनोरेपो अब इंटरकनेक्टेड सॉफ्टवेयर उत्पाद बनाने वाली कंपनियों के लिए मानक आर्किटेक्चर हैं। ** वर्सेल द्वारा अधिग्रहीत टर्बोरेपो, बिल्ड ऑर्केस्ट्रेशन परत प्रदान करता है जो मोनोरेपो को व्यावहारिक बनाता है - दर्जनों पैकेजों में कार्य निर्भरता, कैशिंग और समानांतर निष्पादन को संभालना।
मुख्य बातें
- टर्बोरेपो रिमोट कैशिंग वृद्धिशील परिवर्तनों पर सीआई निर्माण समय को 80-90% तक कम कर सकता है
- कार्य पाइपलाइनें सुनिश्चित करती हैं कि पैकेज स्वचालित रूप से सही निर्भरता क्रम में निर्मित हों
- साझा पैकेज (प्रकार, सत्यापनकर्ता, उपयोगिताएँ) सभी ऐप्स में कोड दोहराव को समाप्त करते हैं
- पीएनपीएम कार्यस्थान मोनोरेपोज़ के लिए डिस्क-कुशल निर्भरता प्रबंधन प्रदान करते हैं
मोनोरेपो आर्किटेक्चर
निर्देशिका संरचना
एक विशिष्ट टर्बोरेपो मोनोरेपो अनुप्रयोगों को साझा पैकेजों से अलग करता है:
my-monorepo/
apps/
api/ # NestJS backend
web/ # Next.js frontend
docs/ # Documentation site
mobile/ # React Native app
packages/
db/ # Drizzle ORM schemas and migrations
types/ # Shared TypeScript types
validators/ # Zod validation schemas
utils/ # Shared utility functions
ui/ # Shared UI components
config/ # Shared configuration (ESLint, TypeScript)
turbo.json # Turborepo configuration
pnpm-workspace.yaml
package.json # Root package.json
कार्यक्षेत्र विन्यास
pnpm-workspace.yaml में कार्यस्थान परिभाषित करें:
packages:
- "apps/*"
- "packages/*"
निर्भरता और स्क्रिप्ट के साथ प्रत्येक कार्यक्षेत्र का अपना पैकेज.जेसन होता है। साझा पैकेजों को कार्यस्थान प्रोटोकॉल का उपयोग करके संदर्भित किया जाता है:
{
"dependencies": {
"@myorg/types": "workspace:*",
"@myorg/validators": "workspace:*",
"@myorg/utils": "workspace:*"
}
}
टर्बोरेपो कॉन्फ़िगरेशन
कार्य पाइपलाइन
Turbo.json परिभाषित करता है कि कार्य एक-दूसरे से कैसे संबंधित हैं:
{
"tasks": {
"build": {
"dependsOn": ["^build"],
"outputs": ["dist/**", ".next/**"]
},
"dev": {
"dependsOn": ["^build"],
"cache": false,
"persistent": true
},
"lint": {
"dependsOn": ["^build"]
},
"test": {
"dependsOn": ["build"]
}
}
}
मुख्य अवधारणाएँ:
- निर्भर करता है: ["^बिल्ड"]: कैरेट (^) का अर्थ है "पहले सभी निर्भरताएं बनाएं।" वेब ऐप बनाते समय, टर्बोरेपो पहले पैकेज/प्रकार, पैकेज/सत्यापनकर्ता, और पैकेज/बर्तन बनाता है।
- आउटपुट: फ़ाइलें जो टर्बोरेपो कैश करती हैं। बाद के रन पर, यदि इनपुट नहीं बदला है, तो टर्बोरेपो पुनर्निर्माण के बजाय कैश्ड आउटपुट को दोबारा चलाता है।
- निरंतर: सत्य: देव सर्वरों के लिए जो चलते रहते हैं।
- कैश: गलत: उन कार्यों के लिए कैशिंग अक्षम करें जिन्हें हमेशा चलना चाहिए (जैसे देव सर्वर)।
साझा पैकेज
प्रकार पैकेज
ऐप्स में उपयोग किए जाने वाले सेंट्रलाइज़ टाइपस्क्रिप्ट प्रकार:
// packages/types/src/user.ts
export interface User {
id: string;
email: string;
name: string;
role: "admin" | "user" | "support";
createdAt: Date;
}
export type CreateUserDTO = Omit<User, "id" | "createdAt">;
export type UpdateUserDTO = Partial<CreateUserDTO>;
सत्यापनकर्ता पैकेज
Zod schemas shared between frontend and backend:
// packages/validators/src/user.ts
import { z } from "zod";
export const createUserSchema = z.object({
email: z.string().email(),
name: z.string().min(2).max(255),
role: z.enum(["admin", "user", "support"]),
});
कॉन्फ़िगरेशन बनाएँ
इससे पहले कि ऐप्स उनका उपभोग कर सकें, साझा पैकेज पूर्व-निर्मित होने चाहिए। प्रत्येक पैकेज को एक बिल्ड स्क्रिप्ट के साथ कॉन्फ़िगर करें जो टाइपस्क्रिप्ट को जावास्क्रिप्ट में संकलित करता है:
{
"scripts": {
"build": "tsc --project tsconfig.json",
"dev": "tsc --watch"
}
}
कैशिंग रणनीति
स्थानीय कैशिंग
Turborepo caches task outputs in node_modules/.cache/turbo by default. जब आप टर्बो बिल्ड चलाते हैं और कुछ भी नहीं बदला है, तो टर्बोरेपो कैश्ड आउटपुट को मिलीसेकंड में दोबारा चलाता है।
रिमोट कैशिंग
सीआई/सीडी के लिए, टीम के सदस्यों और सीआई रन के बीच बिल्ड कलाकृतियों को साझा करने के लिए रिमोट कैशिंग सक्षम करें:
npx turbo login
npx turbo link
रिमोट कैशिंग का मतलब है कि एक डेवलपर मशीन पर पूरा किया गया निर्माण या सीआई रन सभी के लिए उपलब्ध है। प्रभाव नाटकीय है: वृद्धिशील सीआई 10 मिनट से घटकर 1 मिनट से भी कम हो जाता है।
विकास कार्यप्रवाह
सभी ऐप्स चलाना
pnpm dev # Starts all apps and watches all packages
टर्बोरेपो पहले साझा पैकेज बनाता है (क्योंकि डेव ^बिल्ड पर निर्भर करता है), फिर समानांतर में ऐप डेव सर्वर शुरू करता है। साझा पैकेजों में परिवर्तन पुनर्निर्माण को ट्रिगर करता है जो उपभोग करने वाले ऐप्स तक फैलता है।
विशिष्ट ऐप्स चलाना
pnpm dev --filter=web # Only the web app and its dependencies
pnpm dev --filter=api # Only the API and its dependencies
बड़े मोनोरेपो के लिए फ़िल्टरिंग आवश्यक है जहां सब कुछ शुरू करना अनावश्यक है।
सीआई/सीडी अनुकूलन
प्रभावित पैकेज का पता लगाना
टर्बोरेपो यह निर्धारित करता है कि अंतिम प्रतिबद्धता के बाद से कौन से पैकेज बदले हैं और केवल प्रभावित पैकेजों के लिए कार्य चलाता है:
turbo build --filter=...[HEAD^1]
यह केवल उन पैकेजों के लिए बिल्ड चलाता है जो नवीनतम प्रतिबद्धता और उनके आश्रितों में बदल गए हैं।
समानांतर निष्पादन
टर्बोरेपो समानांतर में स्वतंत्र कार्य चलाता है। यदि पैकेज/प्रकार और पैकेज/यूटिल्स का कोई निर्भरता संबंध नहीं है, तो वे एक साथ निर्मित होते हैं। समवर्ती स्तर उपलब्ध सीपीयू कोर के अनुकूल होता है।
अक्सर पूछे जाने वाले प्रश्न
प्रश्न: एक टर्बोरेपो मोनोरेपो कितने पैकेज संभाल सकता है?
टर्बोरेपो सैकड़ों पैकेजों के साथ मोनोरेपो को संभालता है। प्रदर्शन का पैमाना अच्छा है क्योंकि स्टार्टअप पर कार्य ग्राफ़ का विश्लेषण किया जाता है, और कैशिंग का मतलब है कि अधिकांश पैकेज वृद्धिशील परिवर्तनों पर निर्माण को छोड़ देते हैं।
प्रश्न: क्या हमें कार्यस्थानों के लिए पीएनपीएम या एनपीएम का उपयोग करना चाहिए?
मोनोरेपोज़ के लिए पीएनपीएम की पुरजोर अनुशंसा की जाती है। इसका कंटेंट-एड्रेसेबल स्टोर सभी पैकेजों पर निर्भरता को कम करता है, जिससे महत्वपूर्ण डिस्क स्थान और इंस्टॉलेशन समय की बचत होती है। पीएनपीएम कार्यस्थान निर्भरता समाधान के बारे में भी अधिक सख्त हैं, लापता निर्भरता घोषणाओं को पकड़ते हैं।
प्रश्न: हम सभी ऐप्स में विभिन्न Node.js संस्करणों को कैसे संभालते हैं?
Node.js संस्करण आवश्यकताओं को निर्दिष्ट करने के लिए प्रत्येक package.json में इंजन फ़ील्ड का उपयोग करें। रनटाइम अंतर के लिए, प्रति ऐप उचित संस्करण का उपयोग करने के लिए सीआई को कॉन्फ़िगर करें।
प्रश्न: क्या हम क्रमिक रूप से टर्बोरेपो को अपना सकते हैं?
हाँ। मौजूदा पीएनपीएम कार्यक्षेत्र प्रोजेक्ट में टर्बो.जेसन जोड़ें और कार्य पाइपलाइनों को कॉन्फ़िगर करें। मौजूदा स्क्रिप्ट काम करना जारी रखती हैं. आप पुनर्गठन के बिना तुरंत कैशिंग और कार्य ऑर्केस्ट्रेशन प्राप्त करते हैं।
आगे क्या है
टर्बोरेपो मोनोरेपो विकास को रखरखाव के बोझ से उत्पादकता गुणक में बदल देता है। एक सरल संरचना से शुरुआत करें और अपने प्रोजेक्ट की मांग के अनुसार आगे बढ़ें।
मोनोरेपो आर्किटेक्चर परामर्श के लिए ECOSIRE से संपर्क करें, या मल्टी-ऐप ईआरपी आर्किटेक्चर के लिए हमारी Odoo एकीकरण सेवाओं का पता लगाएं।
ECOSIRE द्वारा प्रकाशित - एंटरप्राइज़ सॉफ़्टवेयर समाधानों के साथ व्यवसायों को बड़े पैमाने पर मदद करना।
लेखक
ECOSIRE TeamTechnical Writing
The ECOSIRE technical writing team covers Odoo ERP, Shopify eCommerce, AI agents, Power BI analytics, GoHighLevel automation, and enterprise software best practices. Our guides help businesses make informed technology decisions.
ECOSIRE
ECOSIRE के साथ अपना व्यवसाय बढ़ाएं
ईआरपी, ईकॉमर्स, एआई, एनालिटिक्स और ऑटोमेशन में एंटरप्राइज समाधान।
संबंधित लेख
Drizzle ORM vs Prisma 2026: Schema, Performance, DX Comparison
Balanced Drizzle vs Prisma comparison for TypeScript: schema design, performance, migrations, query DX, edge runtimes. Real production benchmarks.
Odoo CI/CD with GitHub Actions: Testing and Deployment
Build a production Odoo CI/CD pipeline with GitHub Actions: linting, runbot-style testing, multi-version matrix, staging deploy, zero-downtime production.
Odoo Tests: TransactionCase, HttpCase, Tags, post_install
Practical Odoo testing guide: TransactionCase vs HttpCase vs SavepointCase, test tags, post_install timing, tour tests, mocking, CI integration.