𝗕𝗲𝘆𝗼𝗻𝗱 𝗠𝗶𝘀𝘀𝗶𝗻𝗴 𝗘𝘅𝗽𝗼𝗿𝘁𝘀: 𝗕𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗮𝗻 𝗘𝗮𝗿𝗹𝘆 𝗚𝗮𝗿𝗯𝗮𝗴𝗲 𝗖𝗼𝗹𝗹𝗲𝗰𝘁𝗼𝗿

Webpack ஆவணங்களில் விடுபட்ட இணைப்புகளைச் சரிசெய்ய நான் ஒரு நிலையான பிளகினைப் (standard plugin) பயன்படுத்த முயன்றேன். அது தோல்வியடைந்தது.

ஒரு பெரிய codebase-இல் பிளகினை ஒருங்கிணைப்பது எளிதான காரியம் அல்ல. அது ஒரு கட்டமைப்பு சவாலாக (architectural challenge) மாறியது. நான் Abstract Syntax Tree (AST) கையாளுதல், நினைவகப் பயன்பாடு (memory use) மற்றும் மறுநிகழ்வு சுழற்சிகள் (recursive loops) ஆகியவற்றை நிர்வகிக்க வேண்டியிருந்தது.

நிலையான பிளகின்களில் உள்ள சிக்கல்

ஒரு தீர்வை கண்டறிய நான் மூன்று சோதனைகளைச் செய்தேன்.

சோதனை 1: பிளகின் 135 வகைகளை (types) மீட்டெடுத்தது. இருப்பினும், அது அவற்றை ஒரு உள் தொகுதியில் (internal module) வைத்தது. எங்கள் கருவி அவற்றிற்காக ஒரு தனி ஃபோல்டரை உருவாக்கியது. நாங்கள் அவற்றை கைமுறையாக வரிசைப்படுத்த வேண்டியிருந்தது. ஆவணத்தின் கட்டமைப்பு முறையும் தவறாக இருந்தது.

சோதனை 2: வெளிப்புற வகைகளை மறைப்பதற்கான ஒரு அமைப்பை (setting) நான் இயக்கினேன். இது சில விஷயங்களுக்குப் பயன்பட்டது. இது payload அளவை 60 Webpack வகைகளாகக் குறைத்தது. ஆனால் TypeDoc உட்பொதிக்கப்பட்ட சார்புகளை (nested dependencies) புறக்கணித்தது. பல வகைகள் மறைக்கப்பட்டிருந்தாலும், அவை தொடர்ந்து நினைவகத்தைப் பயன்படுத்திக்கொண்டிருந்தன.

சோதனை 3: வகைகளை அவற்றின் அசல் தொகுதிகளுக்கு (original modules) மீண்டும் இணைக்க முயன்றேன். இது ஒரு மறுநிகழ்வு சுழற்சியை (recursive loop) ஏற்படுத்தியது. பிளகின் 630 வகைகளை உருவாக்கும் வரை உட்பொதிக்கப்பட்ட இடைமுகங்களை (nested interfaces) தொடர்ந்து பிரித்தெடுத்தது. ஆவணங்கள் தேவையற்ற தகவல்களால் (noise) நிறைந்திருந்தன. இது பயனர் அனுபவத்தைக் கெடுத்தது.

தீர்வு: ஆரம்பகால குப்பை சேகரிப்பு (Early Garbage Collection)

தேவையற்ற இரைச்சல் இன்றி, வகைகளை அவற்றின் சரியான தொகுதிகளில் எனக்குத் தேவைப்பட்டது. நான் வெளியீட்டைச் (output) சரிசெய்ய முயல்வதை நிறுத்திவிட்டு, செயல்முறையைச் (process) சரிசெய்யத் தொடங்கினேன்.

நான் EVENT_RESOLVE_END என்ற hook-ஐப் பயன்படுத்தினேன். இது resolution முடிந்தவுடன் AST-ஐ இடைமறிக்க எனக்கு அனுமதித்தது. TypeDoc வகைகளை வகைப்படுத்துவதற்கு அல்லது அதிக நினைவகத்தைப் பயன்படுத்துவதற்கு முன்பே நான் இதைச் செய்தேன்.

எனது தர்க்கம் (logic) மூன்று படிகளைப் பின்பற்றியது:

முடிவு: நான் 240 முக்கியமான வகைகளைக் காப்பாற்றினேன். அவை இப்போது தெளிவாகத் தெரிகின்றன மற்றும் சரியாக வழிநடத்தப்படுகின்றன. மூன்றாவது சோதனையில் ஏற்பட்ட மறுநிகழ்வு இரைச்சலை நான் தவிர்த்தேன்.

கற்றுக்கொண்ட பாடங்கள்

• AST-களை ஆரம்பத்திலேயே கையாளவும். தேவையற்ற நோட்களை நீக்குவது பிற்காலத்தில் நினைவக வீணாவதைத் தடுக்கும். • ஹேக் முறைகளுக்குப் பதிலாக hooks-களைப் பயன்படுத்தவும். கம்பைலர் வாழ்க்கைச் சுழற்சியைப் (compiler lifecycle) புரிந்துகொள்வது தூய்மையான வேலையைச் செய்ய உதவும். • பின்னூட்டம் கட்டமைப்பை மேம்படுத்துகிறது. பராமரிப்பாளர் ஆய்வுகள் (Maintainer reviews) சிறந்த அமைப்பை உருவாக்க எனக்கு உதவின. • அதிக தரவு என்பது சிறந்தது அல்ல. சிறந்த பொறியியல் என்பது தரவு மற்றும் பயன்பாட்டுத்தன்மைக்கு இடையிலான சமநிலையைக் கண்டறிவதாகும்.

விடுபட்ட Exports-களுக்கு அப்பால்: Webpack-ன் TypeDoc AST-க்கான ஒரு ஆரம்பகால Garbage Collector-ஐ உருவாக்குதல்

TypeDoc என்பது TypeScript திட்டங்களுக்கான ஆவணங்களை (documentation) உருவாக்கப் பயன்படும் ஒரு சிறந்த கருவியாகும். இருப்பினும், இது சில நேரங்களில் உண்மையில் பயன்பாட்டில் இல்லாத அல்லது சரியாக export செய்யப்படாத குறியீடுகளையும் (code) ஆவணப்படுத்துகிறது. இது ஆவணங்களின் துல்லியத்தைக் குறைக்கிறது.

இந்தக் கட்டுரையில், Webpack மற்றும் TypeDoc-ன் AST (Abstract Syntax Tree) கட்டமைப்பைப் பயன்படுத்தி, தேவையற்றத் தரவுகளை நீக்கும் ஒரு ஆரம்பகால Garbage Collector-ஐ எவ்வாறு உருவாக்குவது என்பதைப் பார்ப்போம்.

பிரச்சனை: விடுபட்ட Exports (The Problem: Missing Exports)

TypeDoc ஆவணங்களை உருவாக்கும் போது, அது குறியீட்டின் ஒரு பகுதியாக இருக்கும் அனைத்துத் தரவுகளையும் எடுத்துக்கொள்ள முயற்சிக்கும். ஆனால், சில நேரங்களில் ஒரு function அல்லது class உண்மையில் export செய்யப்படாமல் இருக்கலாம், அல்லது அது ஒரு குறிப்பிட்ட module-க்குள் மட்டுமே இருக்க வேண்டியிருக்கலாம்.

இதனால் ஆவணங்களில் தேவையற்ற தகவல்கள் இடம்பெறுகின்றன. இது பயனர்களுக்குக் குழப்பத்தை ஏற்படுத்தும்.

தீர்வு: AST Garbage Collector

இதற்குத் தீர்வாக, நாம் ஒரு Garbage Collector-ஐ உருவாக்கலாம். இது TypeDoc ஆவணங்களை உருவாக்குவதற்கு முன்பே, AST-ஐ ஆய்வு செய்து, எந்தெந்த Nodes தேவை என்பதைத் தீர்மானிக்கும்.

இது எவ்வாறு செயல்படுகிறது?

இதன் அடிப்படைத் தத்துவம் மூன்று நிலைகளைக் கொண்டது:

  1. AST Traversal: முதலில், நாம் முழுமையான AST-ஐத் தேடிச் செல்ல வேண்டும் (traverse).
  2. Reachability Analysis: ஒவ்வொரு Node-ம் ஒரு export மூலம் அணுகக்கூடியதா என்பதைச் சரிபார்க்க வேண்டும்.
  3. Pruning: அணுக முடியாத Nodes-களை நாம் AST-லிருந்து நீக்கிவிட வேண்டும்.

செயல்படுத்துதல் (Implementation)

இந்த Garbage Collector-ஐ உருவாக்க, நாம் TypeDoc-ன் API மற்றும் Visitor pattern-ஐப் பயன்படுத்த வேண்டும்.

படி 1: AST-ஐ ஆய்வு செய்தல்

முதலில், நாம் AST-ல் உள்ள அனைத்து Nodes-களையும் ஆய்வு செய்ய ஒரு Visitor-ஐ உருவாக்க வேண்டும்.

import { TypeDoc, DeclarationKind } from 'typedoc';

class GarbageCollector {
  private reachableNodes = new Set<string>();

  // Nodes-களைக் கண்டறியும் முறை
  collect(context: any) {
    // logic to traverse AST
  }
}

படி 2: தேவையற்றவற்றை நீக்குதல் (Pruning)

அணுக முடியாத Nodes-களைக் கண்டறிந்தவுடன், அவற்றை AST கட்டமைப்பிலிருந்து நீக்க வேண்டும்.

// Pruning logic
if (!this.isReachable(node)) {
  node.parent.removeChild(node);
}

முடிவு

ஒரு ஆரம்பகால Garbage Collector-ஐ உருவாக்குவதன் மூலம், TypeDoc ஆவணங்களின் தரத்தை நாம் கணிசமாக உயர்த்த முடியும். இது தேவையற்றத் தகவல்களை நீக்கி, பயனர்களுக்குத் தெளிவான மற்றும் துல்லியமான ஆவணங்களை வழங்க உதவுகிறது.

இந்த அணுகுமுறை Webpack போன்ற சிக்கலான கட்டமைப்புகளிலும் சிறப்பாகச் செயல்படும் வகையில் வடிவமைக்கப்பட்டுள்ளது.