Electron ऐप में तारीख़ को नक़ली बनाना

इसे खोजें तो हर जवाब आपके अपने कोड को बदलने के बारे में होता है - Date ऑब्जेक्ट को मॉक करना, अपने टेस्ट फ़्रेमवर्क के नक़ली टाइमर इस्तेमाल करना। जब आपके पास बना-बनाया ऐप्लिकेशन हो, तब इनमें से कुछ भी काम नहीं आता। यह वही ऐप्लिकेशन चलाता है जो आपके पास पहले से है।

इंजेक्शन वहाँ क्यों नहीं पहुँचता

यह मोड एक ख़ास विफलता की वजह से बना। Electron पर बना एक पोमोडोरो टाइमर x60 सत्र में चलाया गया और उसका काउंटडाउन बिल्कुल नहीं हिला। ऐप्लिकेशन के बंडल को खोलने पर दो स्वतंत्र कारण मिले, और किसी का भी नेटिव तरफ़ कोई हल नहीं था:

काउंटडाउन कोई घड़ी पढ़ ही नहीं रहा था। वह setInterval से बढ़ाया जाने वाला एक काउंटर था, जो एक Web Worker के भीतर चल रहा था। रोकने के लिए कोई समय-कॉल थी ही नहीं, क्योंकि ऐप्लिकेशन ने कभी पूछा ही नहीं कि समय क्या है।
वह वर्कर एक सैंडबॉक्स्ड रेंडरर प्रोसेस में रहता है, जो ठीक वह जगह है जहाँ बाहर से इंजेक्ट की गई लाइब्रेरी नहीं पहुँचती।

इसलिए Windows की तरफ़ का तंत्र यहाँ मदद नहीं कर सकता, और जवाब यह है कि ऐप्लिकेशन के अपने JavaScript इंजन से बात की जाए।

इसके बजाय क्या होता है

ऐप्लिकेशन को एक डीबगिंग पोर्ट और एक साफ़, अस्थायी प्रोफ़ाइल के साथ लॉन्च किया जाता है, और उसके अपने समय API DevTools प्रोटोकॉल के ज़रिए सत्र की घड़ी पर रखे जाते हैं - Date.now, new Date() कंस्ट्रक्टर, performance.now, setTimeout और setInterval।

यह ओवरराइड ऐप्लिकेशन के खोले हर कॉन्टेक्स्ट में स्थापित होता है, उसके Web Worker समेत - जहाँ अक्सर टाइमर पाया जाता है, और वह अकेली जगह जहाँ नेटिव इंजेक्शन कभी नहीं पहुँचने वाला था।

आप इसे जिस तरह चलाते हैं उसमें कुछ नहीं बदलता। वही कमांड, वही विंडो, दोनों घड़ियों और निर्णय वाला वही सत्र पैनल।

# नेटिव ऐप्लिकेशन जैसी ही कमांड - मोड अपने-आप पहचाना जाता है
chrono run "%LOCALAPPDATA%\Programs\your-app\YourApp.exe" --at 2038-01-01T00:00:00 --mode x60

शुरू करने से पहले जानने लायक दो सीमाएँ

यह लॉन्च दख़लअंदाज़ है, और जानबूझकर इसके बारे में खुलकर बताता है।

ऐप्लिकेशन एक खुले रिमोट डीबगिंग पोर्ट और %TEMP% के नीचे एक नई, अलग प्रोफ़ाइल के साथ शुरू होता है - वह आपकी असली प्रोफ़ाइल पर नहीं चलता, और वह सिस्टम ट्रे में पहले से मौजूद प्रति भी नहीं है। प्रोफ़ाइल सत्र ख़त्म होने पर मिटा दी जाती है, और अगर न मिटाई जा सके तो सत्र का सारांश चुपचाप उसे छोड़ देने की जगह यही बताता है।

अपना --user-data-dir या --remote-debugging-port देने पर वह ओवरराइड नहीं होता, अस्वीकार कर दिया जाता है, क्योंकि जो साफ़ दिखने वाली दुर्घटना है - सत्र को आपकी असली ब्राउज़र प्रोफ़ाइल की ओर मोड़ देना - वह होने देने लायक नहीं है।

पेज सत्र का टाइम ज़ोन पढ़ते हैं।

हर पेज और हर worker को सत्र के टाइम ज़ोन पर रखा जाता है, जो डेलाइट सेविंग के बिना एक स्थिर ऑफ़सेट है, और वह जो ऑफ़सेट पढ़ता है उसकी जाँच करता है, इसलिए जिस पेज ने कोई और ज़ोन पढ़ा उसकी रिपोर्ट की जाती है। दो सीमाएँ हैं: Intl उस ज़ोन को शहर के नाम से नहीं, GMT+02:00 जैसे ऑफ़सेट के रूप में बताता है, और Electron ऐप्लिकेशन की मुख्य प्रक्रिया Node में JavaScript चलाती है, जहाँ सत्र नहीं पहुँचता, इसलिए वह असली घड़ी पर रहती है - रिपोर्ट यह बताती है।

एक और बात जो लोगों को चौंकाती है: पहले से निर्धारित इंटरवल सत्र के बीच गति बदलने पर अपनी पुरानी दर पर ही चलता रहता है। Date.now, new Date() और performance.now तुरंत प्रतिक्रिया देते हैं, चलता हुआ setInterval नहीं देता, और सत्र इस बारे में चेतावनी देता है, बजाय इसके कि आप यह नतीजा निकाल लें कि बदलाव ने कुछ नहीं किया।

यह कितना परखा गया है

प्रयोगात्मक, और इस शब्द का यहाँ तय अर्थ है: यह उन टारगेट पर चलता है जिनके विरुद्ध बना था, इसे व्यापक रूप से परखा नहीं गया है, और इस पेज की जगह बिल्ट-इन ऑडिट आपका सच का स्रोत है। इसे स्वचालित सूट से नहीं, हाथ से सत्यापित किया गया था, 64-बिट Windows पर एक असली Electron ऐप्लिकेशन के विरुद्ध।

कवरेज प्रति JavaScript कॉन्टेक्स्ट रिपोर्ट होती है, प्रति प्रोसेस नहीं, क्योंकि यहाँ वही इकाई मौजूद है। जो ऐप्लिकेशन निष्क्रिय बैठा है और कभी समय नहीं पूछता, वह ईमानदारी से अनिर्धारित देता है - उसने कोई घड़ी पढ़ी ही नहीं, इसलिए यह दावा नहीं किया जा सकता कि वह सही घड़ी देखता या नहीं। निर्णयों का मतलब →

आज़माएँ

Windows के लिए डाउनलोड करें FAQ पढ़ें