Testlify - साझा कंपोनेंट लाइब्रेरी

नेतृत्व किया, अकेले नहीं बनाया

मैंने लाइब्रेरी प्रस्तावित की और आर्किटेक्चर को आगे बढ़ाया, लेकिन यह एक अकेले इंसान का काम नहीं था: मई 2026 से 7 योगदानकर्ताओं के 86 कमिट, जिनमें मेरे अपने कमिट कुल का लगभग दो-तिहाई हैं। 4 प्रोडक्ट टीमों में एक साझा डिज़ाइन सिस्टम अपनवाना सिर्फ़ कंपोनेंट लिखने से ज़्यादा कुछ मांगता है; इसके लिए वह रिलीज़ प्रोसेस चाहिए जो उन्हें अपनाने को कम-जोखिम वाला बनाए, और यही असली मुश्किल समस्या बनी।

हर PR पर पब्लिश किए बिना एक अनरिलीज़्ड कंपोनेंट बदलाव को टेस्ट करना

किसी साझा लाइब्रेरी को अपनाने में सबसे बड़ी अड़चन कंपोनेंट लिखना नहीं है, यह "मैंने कुछ बदला" और "एक कंज़्यूमिंग टीम असल में उसे आज़मा सकती है" के बीच का फासला है। हर एक PR पर एक टेम्परेरी वर्ज़न पब्लिश करना उस पैकेज के लिए असली, बार-बार होने वाली CI लागत होगी जिसे ज़्यादातर PR कहीं भी इंस्टॉल ही नहीं करते, इसलिए यह ऑप्ट-इन है: एक PR को needs-snapshot लेबल तभी मिलता है जब किसी कंज़्यूमर को असल में उसे टेस्ट करना हो, जो एक snapshot.yml GitHub Action ट्रिगर करता है जो एक टेम्परेरी @pr<number> टैग वाला पैकेज पब्लिश करता है। PR बंद होते ही एक जोड़ा हुआ cleanup-snapshot.yml उस टैग को हटा देता है। नियमित रिलीज़ दो चैनलों पर Changesets से होकर गुज़रती हैं, main से @latest और एक स्टेजिंग ब्रांच से @beta, और रिलीज़ वर्कफ्लो CI पास होते ही अपनी खुद जनरेट की गई "Version Packages" PR को ऑटो-मर्ज कर देता है।

एक मोनोरेपो जो अपनी खुद की डिपेंडेंसी दिशा लागू करता है

लाइब्रेरी एक फ्लैट पैकेज नहीं, बल्कि लेयर में बंटी है: tokens, icons, और styles सबसे नीचे बैठते हैं, ज़ीरो इंटरनल डिपेंडेंसी के साथ, core उन पर बनता है, ds core पर बनता है, और ds-patterns ds, core, और styles पर बनता है। हर लेयर सिर्फ़ नीचे की ओर निर्भर हो सकती है, कभी ऊपर की ओर नहीं, ताकि कोई निचले-स्तर का प्रिमिटिव चुपचाप किसी ऊंचे-स्तर के पैटर्न कंपोनेंट पर निर्भरता न पाले। ds-patterns भी सिर्फ़ सामान्य प्रिमिटिव नहीं है: इसमें असली Testlify डोमेन विजेट भी शामिल हैं (जैसे एक CandidateCard), उसी प्रिमिटिव लेयर पर बने जिसे बाकी सब इस्तेमाल करता है। Storybook, जिसमें accessibility ऐडऑन सक्षम है, हर कंपोनेंट को दस्तावेज़ीकृत करता है और पब्लिकली डिप्लॉय होता है, ताकि एक कंज़्यूमर टीम (या कोई बाहरी रिव्यूअर) बिना रेपो खींचे किसी कंपोनेंट की स्टेट और a11y नतीजे जांच सके। हर कंपोनेंट में एक समर्पित .a11y.spec.ts फाइल भी है जो CI में असली axe-core जांच चलाती है, सिर्फ़ मैनुअल निरीक्षण के लिए Storybook ऐडऑन नहीं।

डेटा मॉडल और स्केल

• 6 पब्लिश किए गए पैकेज (ds, -core, -icons, -patterns, -styles, -tokens), हर एक स्वतंत्र रूप से वर्ज़न किया गया।
• 243 स्पेक फाइलें (Vitest + Vue Test Utils) जो लाइब्रेरी को सीधे एक्सरसाइज़ करती हैं, सिर्फ़ इसे इस्तेमाल करने वाले ऐप्स को नहीं।
• 9 GitHub Actions वर्कफ्लो जो CI, प्रीव्यू और प्रोडक्शन डिप्लॉय, Storybook डिप्लॉय, स्टेजिंग और प्रोडक्शन रिलीज़, PR स्नैपशॉट, और स्नैपशॉट क्लीनअप को कवर करते हैं।
• pnpm workspaces प्लस Turborepo, कैश करते हैं और बिल्ड टास्क को उन पैकेजों तक सीमित रखते हैं जो किसी दिए गए बदलाव से असल में प्रभावित होते हैं; टेस्ट Turbo के task graph के बजाय पूरे workspace में सीधे Vitest के ज़रिए चलते हैं।

अडॉप्शन हर टीम के हिसाब से रोलआउट हुआ, किसी एक ज़बरदस्ती वाले फ्लैग डे पर नहीं: रिक्रूटर/एडमिन ऐप आज सभी 6 पब्लिश किए गए पैकेजों पर चलता है, जबकि बाकी प्रोडक्ट टीमें अपने-अपने रिलीज़ शेड्यूल पर अलग-अलग कंपोनेंट खींचती हैं, चारों एप्लिकेशन में एक साथ किसी समन्वित कटओवर के बजाय।

Build vs. Buy

कोई हाथ से बनी version-bump स्क्रिप्ट नहीं: Changesets हर PR के एक changeset फाइल से सभी 6 पैकेजों में वर्ज़निंग और चेंजलॉग मैनेज करता है। कोई सेल्फ-होस्टेड प्राइवेट रजिस्ट्री नहीं: GitHub Packages उसी GitHub auth का दोबारा इस्तेमाल करता है जो पहले से रेपो एक्सेस को गेट करता है, Verdaccio जैसी एक अलग रजिस्ट्री चलाने और सुरक्षित करने के बजाय।

Stack

Vue 3, TypeScript, Vite, Turborepo के साथ pnpm workspaces, accessibility ऐडऑन के साथ Storybook, वर्ज़निंग के लिए Changesets, Vitest और Vue Test Utils, GitHub Packages के ज़रिए पब्लिश।