Monorepo सेट अप करना
In this page:
// root package.json
{ "workspaces": ["packages/*"] }
// packages/app/tsconfig.json
{
"references": [{ "path": "../shared" }]
}Core Concept
एक monorepo कई related TypeScript packages (एक shared library, एक backend, एक frontend) को एक repository में एक dependency tree के साथ रखता है, cross-package refactors को separate repos में coordinated releases की ज़रूरत के बजाय atomic बनाते हुए।
उदाहरण: Core Concept
// One repo, multiple packages: packages/shared, packages/backend, packages/frontend
console.log("A monorepo makes cross-package refactors atomic, not multi-repo");Basic Setup
एक basic setup एक workspace tool (npm/yarn/pnpm workspaces या Turborepo) उपयोग करता है जिसमें root package.json में workspaces listed हों, और packages/* के नीचे हर package का अपना package.json और tsconfig.json होता है।
उदाहरण: Basic Setup
// root package.json: { "workspaces": ["packages/*"] }
// packages/shared/package.json, packages/shared/tsconfig.json, etc.
console.log("Workspace tooling (npm/yarn/pnpm) links packages together");Typed Example
TypeScript project references (tsconfig.json का references array) एक package के tsconfig को दूसरे की ओर point करने देते हैं, इसलिए tsc --build उन्हें सही dependency order में compile करता है और सिर्फ वही rebuild करता है जो असल में बदला।
उदाहरण: Typed Example
// packages/app/tsconfig.json
// { "references": [{ "path": "../shared" }] }
console.log("tsc --build compiles referenced packages in dependency order");Project Usage
एक असली project में, एक monorepo आम तौर पर एक packages/shared-types package रखता है जिस पर frontend और backend दोनों packages depend करते हैं, request/response types को दोनों sides पर copy-paste किए बिना perfectly sync रखते हुए।
उदाहरण: Project Usage
// packages/shared-types exports API types used by both frontend and backend
console.log("A shared-types package keeps request/response types in sync");Best Practices
Path aliases को कम उपयोग करें और workspace packages के बीच असली package references को prefer करें, क्योंकि aliases एक package के असली dependency graph को छुपा सकते हैं और tsc --build के incremental ordering को unreliable बना सकते हैं।
उदाहरण: Best Practices
// Prefer real package references over path aliases between workspace packages
console.log("Aliases can hide the real dependency graph tsc --build relies on");- एक package publish करना जो किसी और workspace package पर depend करता है लेकिन इसे अपने
dependenciesमें list करना भूल जाना। - हर package में
tscगलत order में चलाना, project references या एक build tool उपयोग करने के बजाय। - सब कुछ के लिए एक loose root
tsconfig.jsonshare करना, जिससे packages को वे options मिलती हैं जो उन्हें नहीं मिलनी चाहिए।
Chapter Quiz — Complete all 5 topics to unlock
0/5 topics done
Complete these topics first: