Typescript: "मध्यम आकार" परियोजनाओं का समर्थन करें

को निर्मित 10 जून 2015 · 147टिप्पणियाँ · स्रोत: microsoft/TypeScript

@nycdotnet को सुनकर मैं इससे निपटने के लिए तैयार हो गया। धन्यवाद, स्टीव। (बीटीडब्ल्यू, आप उनका अच्छा साक्षात्कार यहां देख सकते हैं: http://www.dotnetrocks.com/default.aspx?showNum=1149)

यहां प्रस्ताव पहली बार प्रागैतिहासिक काल (#11 से पहले भी) में शुरू किया गया था, जब डायनासोर झुलसी हुई धरती पर चले थे। हालांकि इस प्रस्ताव में कुछ भी नया नहीं है, लेकिन मेरा मानना है कि अब समय आ गया है कि हम इस मुद्दे से निपटें। स्टीव का अपना प्रस्ताव #3394 है।

समस्या

वर्तमान में, टाइपस्क्रिप्ट में, इसे शुरू करना और आगे बढ़ना काफी आसान है, और हम इसे हर दिन (#2338 और System.js पर काम की मदद से) के साथ आसान बना रहे हैं। यह अद्भुत है। लेकिन जैसे-जैसे परियोजना का आकार बढ़ता है, इसमें थोड़ी बाधा होती है। वर्तमान में हमारे पास एक मानसिक मॉडल है जो कुछ इस प्रकार है:

छोटे आकार के प्रोजेक्ट: tsconfig.json का उपयोग करें, अपने अधिकांश स्रोत को वर्तमान निर्देशिका में रखें
बड़े आकार की परियोजनाएं: कस्टम बिल्ड का उपयोग करें, जहां आपको इसकी आवश्यकता हो वहां स्रोत डालें

छोटे आकार के प्रोजेक्ट के लिए, tsconfig.json आपको किसी भी संपादक के साथ क्रॉस प्लेटफॉर्म तरीके से जाने का एक आसान-से-सेटअप तरीका देता है। बड़े पैमाने की परियोजनाओं के लिए, आप बड़े पैमाने की परियोजनाओं की विभिन्न आवश्यकताओं के कारण सिस्टम बनाने के लिए स्विच करना समाप्त कर देंगे, और अंतिम परिणाम कुछ ऐसा होगा जो आपके परिदृश्यों के लिए काम करता है लेकिन टूल करना मुश्किल है क्योंकि टूल करना बहुत मुश्किल है निर्माण प्रणालियों और विकल्पों की विविधता।

स्टीव, अपने साक्षात्कार में, बताते हैं कि यह दुनिया का बिल्कुल सही मॉडल नहीं है, और मैं उससे सहमत हूं। इसके बजाय, परियोजना के तीन आकार हैं:

छोटे आकार के प्रोजेक्ट: tsconfig.json का उपयोग करें, अपने अधिकांश स्रोत को वर्तमान निर्देशिका में रखें
मध्यम आकार की परियोजनाएं: मानक निर्माण और साझा घटकों के साथ
बड़े आकार की परियोजनाएं: कस्टम बिल्ड का उपयोग करें, जहां आपको इसकी आवश्यकता हो वहां स्रोत डालें

जैसा कि आप परियोजना के आकार में स्केल करते हैं, स्टीव का तर्क है, आपको मध्यम चरण के माध्यम से स्केल करने में सक्षम होना चाहिए, या उपकरण समर्थन बहुत जल्दी गिर जाता है।

प्रस्ताव

इसे हल करने के लिए, मेरा प्रस्ताव है कि हम "मध्यम आकार" परियोजनाओं का समर्थन करें। इन परियोजनाओं में मानक निर्माण चरण होते हैं जिन्हें आज tsconfig.json में वर्णित किया जा सकता है, इस अपवाद के साथ कि परियोजना कई घटकों से बनाई गई है। यहां परिकल्पना यह है कि इस स्तर पर काफी संख्या में परियोजनाएं हैं जिन्हें इस समर्थन से अच्छी तरह से परोसा जा सकता है।

लक्ष्य

कमांड-लाइन संकलन और आईडीई में इन परियोजनाओं के साथ काम करते समय दोनों के लिए "मध्यम आकार" प्रोजेक्ट बनाने वाले डेवलपर्स के लिए उपयोग में आसान अनुभव प्रदान करें।

गैर-लक्ष्य

इस प्रस्ताव में _not_ वैकल्पिक संकलन शामिल है, या संकलक आज जो काम करता है, उसके बाहर कोई चरण शामिल है। इस प्रस्ताव में बंडलिंग या पैकेजिंग भी शामिल नहीं है, जिसे एक अलग प्रस्ताव में संभाला जाएगा। संक्षेप में, जैसा कि नाम में उल्लेख किया गया है, यह प्रस्ताव केवल 'मध्यम आकार' की परियोजनाओं को शामिल करता है, न कि बड़े पैमाने पर उनकी जरूरतों को।

डिज़ाइन

मध्यम आकार की परियोजनाओं का समर्थन करने के लिए, हम एक के उपयोग के मामले पर ध्यान केंद्रित करते हैं tsconfig.json दूसरे को संदर्भित करता है।

उदाहरण tsconfig.json आज का:

{
    "compilerOptions": {
        "module": "commonjs",
        "noImplicitAny": true,
        "sourceMap": true
    },
    "files": [
        "core.ts",
        "sys.ts"
    ]
}

प्रस्तावित tsconfig.json 'निर्भरता' अनुभाग:

{
    "compilerOptions": {
        "module": "commonjs",
        "noImplicitAny": true,
        "sourceMap": true
    },
    "dependencies": [
        "../common", 
        "../util"
    ],
    "files": [
        "core.ts",
        "sys.ts"
    ]
}

निर्भरताएँ या तो इंगित करती हैं:

एक निर्देशिका, जहाँ एक tsconfig.json पाया जा सकता है
एक tsconfig.json सीधे

निर्भरता पदानुक्रमित हैं। पूरे प्रोजेक्ट को संपादित करने के लिए, आपको सही निर्देशिका खोलनी होगी जिसमें रूट tsconfig.json हो। इसका तात्पर्य है कि निर्भरता चक्रीय नहीं हो सकती है। हालांकि कुछ मामलों में चक्रीय निर्भरताओं को संभालना संभव हो सकता है, अन्य मामलों में, अर्थात् वे प्रकार जिनके पास परिपत्र निर्भरताएं हैं, पूर्ण संकल्प करना संभव नहीं हो सकता है।

यह काम किस प्रकार करता है

निर्भरताएँ पहले बनाई जाती हैं, क्रम में वे 'निर्भरता' अनुभाग में सूचीबद्ध होती हैं। यदि कोई निर्भरता निर्माण करने में विफल रहती है, तो संकलक एक त्रुटि के साथ बाहर निकल जाएगा और शेष परियोजना का निर्माण जारी नहीं रखेगा।

जैसे ही प्रत्येक निर्भरता पूरी होती है, आउटपुट का प्रतिनिधित्व करने वाली '.d.ts' फ़ाइल वर्तमान बिल्ड के लिए उपलब्ध कराई जाती है। एक बार सभी निर्भरताएँ पूरी हो जाने के बाद, वर्तमान परियोजना का निर्माण किया जाता है।

यदि उपयोगकर्ता एक उपनिर्देशिका को एक निर्भरता के रूप में निर्दिष्ट करता है, और एक 'फाइल' अनुभाग प्रदान न करके इसके संकलन का भी तात्पर्य है, तो निर्भरता संकलन के दौरान निर्भरता संकलित की जाती है और वर्तमान परियोजना के संकलन से भी हटा दी जाती है।

भाषा सेवा प्रत्येक निर्भरता में देख सकती है। चूंकि प्रत्येक निर्भरता को अपने स्वयं के tsconfig.json से हटा दिया जाएगा, इसका मतलब यह हो सकता है कि कई भाषा सेवा उदाहरण बनाने की आवश्यकता होगी। अंतिम परिणाम एक समन्वित भाषा सेवा होगी जो निर्भरता में रिफैक्टरिंग, कोड नेविगेशन, सभी संदर्भों को खोजने आदि में सक्षम थी।

सीमाओं

एक निर्देशिका को एक निर्भरता के रूप में जोड़ना जिसमें कोई tsconfig.json नहीं है, एक त्रुटि मानी जाती है।

निर्भरता के आउटपुट को स्व-निहित और वर्तमान परियोजना से अलग माना जाता है। इसका तात्पर्य है कि आप tsconfig.json के माध्यम से वर्तमान प्रोजेक्ट के साथ एक निर्भरता के आउटपुट .js को संयोजित नहीं कर सकते। बाहरी उपकरण, निश्चित रूप से, यह कार्यक्षमता प्रदान कर सकते हैं।

जैसा कि पहले उल्लेख किया गया है, परिपत्र निर्भरता को एक त्रुटि माना जाता है। साधारण मामले में:

ए - बी
\ सी

ए 'वर्तमान परियोजना' है और दो निर्भरताओं पर निर्भर करता है: बी और सी। यदि बी और सी स्वयं निर्भरता नहीं रखते हैं, तो यह मामला छोटा है। यदि C, B पर निर्भर करता है, तो B, C को उपलब्ध कराया जाता है। इसे वृत्ताकार नहीं माना जाता है। यदि, तथापि, B, A पर निर्भर करता है, तो इसे वृत्ताकार माना जाता है और यह एक त्रुटि होगी।

यदि, उदाहरण में, B, C पर निर्भर है और C स्व-निहित है, तो इसे एक चक्र नहीं माना जाएगा। इस मामले में, संकलन क्रम सी, बी, ए होगा, जो हमारे पास /// रेफरी के तर्क का पालन करता है।

वैकल्पिक अनुकूलन/सुधार

यदि एक निर्भरता का पुनर्निर्माण नहीं किया जाता है, तो इसके निर्माण चरण को छोड़ दिया जाता है और पिछले निर्माण से '.d.ts' प्रतिनिधित्व का पुन: उपयोग किया जाता है। इसे संभालने के लिए बढ़ाया जा सकता है यदि निर्भरता के संकलन ने निर्भरताएं बनाई हैं जो बाद में वर्तमान परियोजना की 'निर्भरता' सूची में दिखाई देंगी (जैसा कि सीमा अनुभाग में दिए गए उदाहरण में हुआ)।

निर्देशिकाओं को निर्भरता के रूप में मानने के बजाय, जिसमें tsconfig.json त्रुटि मामलों के रूप में नहीं है, हम वैकल्पिक रूप से डिफ़ॉल्ट 'फ़ाइलें' और वर्तमान प्रोजेक्ट की सेटिंग्स को उस निर्भरता पर लागू कर सकते हैं।

Committed Monorepos & Cross-Project References Suggestion

स्रोत

jonathandturner

👍173 ❤49 🎉26

सबसे उपयोगी टिप्पणी

नीचे डॉक्स/ब्लॉगपोस्ट का कार्य प्रगति पर है (फ़ीडबैक के आधार पर इसे संपादित करेंगे)

मैं इस धागे का अनुसरण करने वाले किसी भी व्यक्ति को इसे आज़माने के लिए प्रोत्साहित करता हूँ। मैं अब मोनोरेपो परिदृश्य पर काम कर रहा हूं ताकि वहां किसी भी अंतिम बग/सुविधाओं को दूर किया जा सके और जल्द ही इस पर कुछ मार्गदर्शन किया जाना चाहिए

परियोजना संदर्भ

प्रोजेक्ट संदर्भ टाइपस्क्रिप्ट 3.0 में एक नई विशेषता है जो आपको अपने टाइपस्क्रिप्ट प्रोग्राम को छोटे टुकड़ों में संरचित करने की अनुमति देता है।

ऐसा करने से, आप बिल्ड समय में बहुत सुधार कर सकते हैं, घटकों के बीच तार्किक अलगाव को लागू कर सकते हैं, और अपने कोड को नए और बेहतर तरीके से व्यवस्थित कर सकते हैं।

हम tsc , --build ध्वज के लिए एक नया मोड भी पेश कर रहे हैं, जो तेजी से टाइपस्क्रिप्ट बिल्ड को सक्षम करने के लिए प्रोजेक्ट संदर्भों के साथ हाथ से काम करता है।

एक उदाहरण परियोजना

आइए एक सामान्य कार्यक्रम को देखें और देखें कि कैसे परियोजना संदर्भ हमें इसे बेहतर ढंग से व्यवस्थित करने में मदद कर सकते हैं।
कल्पना कीजिए कि आपके पास दो मॉड्यूल के साथ एक प्रोजेक्ट है, converter और units , और प्रत्येक के लिए एक संबंधित परीक्षण फ़ाइल:

/src/converter.ts
/src/units.ts
/test/converter-tests.ts
/test/units-tests.ts
/tsconfig.json

परीक्षण फ़ाइलें कार्यान्वयन फ़ाइलों को आयात करती हैं और कुछ परीक्षण करती हैं:

// converter-tests.ts
import * as converter from "../converter";

assert.areEqual(converter.celsiusToFahrenheit(0), 32);

पहले, यदि आप एक tsconfig फ़ाइल का उपयोग करते हैं तो यह संरचना काम करने के लिए अजीब थी:

कार्यान्वयन फ़ाइलों के लिए परीक्षण फ़ाइलों को आयात करना संभव था
आउटपुट फ़ोल्डर नाम में src दिखाई दिए बिना एक ही समय में test और src बनाना संभव नहीं था, जो आप शायद नहीं चाहते
कार्यान्वयन फ़ाइलों में केवल आंतरिक को बदलने के लिए परीक्षणों को फिर से टाइप करना आवश्यक है, भले ही यह कभी भी नई त्रुटियों का कारण न बने
केवल परीक्षणों को बदलने के लिए कार्यान्वयन को फिर से टाइप करना आवश्यक है, भले ही कुछ भी न बदला हो

आप उन समस्याओं में से कुछ को हल करने के लिए कई tsconfig फाइलों का उपयोग कर सकते हैं, लेकिन नए दिखाई देंगे:

कोई अंतर्निहित अप-टू-डेट जाँच नहीं है, इसलिए आप हमेशा tsc दो बार चलते हैं
tsc दो बार आमंत्रित करने से स्टार्टअप समय अधिक लगता है
tsc -w एक साथ कई कॉन्फिग फाइलों पर नहीं चल सकता

परियोजना संदर्भ इन सभी समस्याओं और बहुत कुछ को हल कर सकते हैं।

एक परियोजना संदर्भ क्या है?

tsconfig.json फाइलों में एक नई शीर्ष-स्तरीय संपत्ति है, references । यह वस्तुओं की एक सरणी है जो संदर्भ के लिए परियोजनाओं को निर्दिष्ट करती है:

{
    "compilerOptions": {
        // The usual
    },
    "references": [
        { "path": "../src" }
    ]
}

प्रत्येक संदर्भ की path संपत्ति एक निर्देशिका को इंगित कर सकती है जिसमें tsconfig.json फ़ाइल है, या स्वयं कॉन्फ़िगरेशन फ़ाइल (जिसका कोई भी नाम हो सकता है)।

जब आप किसी प्रोजेक्ट का संदर्भ देते हैं, तो नई चीज़ें होती हैं:

किसी संदर्भित प्रोजेक्ट से मॉड्यूल आयात करने के बजाय इसकी आउटपुट घोषणा फ़ाइल ( .d.ts ) लोड होगी
यदि संदर्भित प्रोजेक्ट outFile उत्पन्न करता है, तो आउटपुट फ़ाइल .d.ts फ़ाइल की घोषणाएं इस प्रोजेक्ट में दिखाई देंगी
बिल्ड मोड (नीचे देखें) जरूरत पड़ने पर स्वचालित रूप से संदर्भित प्रोजेक्ट का निर्माण करेगा

कई परियोजनाओं में विभाजित करके, आप टाइपचेकिंग और संकलन की गति में काफी सुधार कर सकते हैं, एक संपादक का उपयोग करते समय स्मृति उपयोग को कम कर सकते हैं, और अपने कार्यक्रम के तार्किक समूहों के प्रवर्तन में सुधार कर सकते हैं।

`composite`

संदर्भित प्रोजेक्ट में नई composite सेटिंग सक्षम होनी चाहिए।
यह सुनिश्चित करने के लिए इस सेटिंग की आवश्यकता है कि टाइपस्क्रिप्ट जल्दी से यह निर्धारित कर सके कि संदर्भित प्रोजेक्ट के आउटपुट को कहां खोजना है।
composite ध्वज को सक्षम करने से कुछ चीज़ें बदल जाती हैं:

rootDir सेटिंग, यदि स्पष्ट रूप से सेट नहीं है, तो tsconfig फ़ाइल वाली निर्देशिका के लिए डिफ़ॉल्ट है
सभी कार्यान्वयन फ़ाइलों का मिलान include पैटर्न से होना चाहिए या files सरणी में सूचीबद्ध होना चाहिए। यदि इस बाधा का उल्लंघन किया जाता है, तो tsc आपको सूचित करेगा कि कौन-सी फ़ाइलें निर्दिष्ट नहीं की गई थीं
declaration चालू होना चाहिए

`declarationMaps`

हमने घोषणा स्रोत मानचित्रों के लिए समर्थन भी जोड़ा है।
यदि आप --declarationMap सक्षम करते हैं, तो आप समर्थित संपादकों में परियोजना की सीमाओं के पार कोड को पारदर्शी रूप से नेविगेट करने और संपादित करने के लिए "परिभाषा पर जाएं" और नाम बदलें जैसी संपादक सुविधाओं का उपयोग करने में सक्षम होंगे।

`prepend` साथ `outFile`

आप संदर्भ में prepend विकल्प का उपयोग करके किसी निर्भरता के आउटपुट को प्रीपेन्ड करना भी सक्षम कर सकते हैं:

   "references": [
       { "path": "../utils", "prepend": true }
   ]

किसी प्रोजेक्ट को तैयार करने में वर्तमान प्रोजेक्ट के आउटपुट के ऊपर प्रोजेक्ट का आउटपुट शामिल होगा।
यह .js फ़ाइलों और .d.ts फ़ाइलों दोनों के लिए काम करता है, और स्रोत मानचित्र फ़ाइलें भी सही ढंग से उत्सर्जित होंगी।

tsc इस प्रक्रिया को करने के लिए केवल डिस्क पर मौजूदा फ़ाइलों का उपयोग करेगा, इसलिए एक प्रोजेक्ट बनाना संभव है जहां एक सही आउटपुट फ़ाइल उत्पन्न नहीं की जा सकती क्योंकि कुछ प्रोजेक्ट का आउटपुट परिणामी फ़ाइल में एक से अधिक बार मौजूद होगा .
उदाहरण के लिए:

  ^ ^ 
 /   \
B     C
 ^   ^
  \ /
   D

यह प्रत्येक संदर्भ में पहले जोड़ें नहीं करने के लिए इस स्थिति में महत्वपूर्ण है, क्योंकि आप की दो प्रतियां साथ खत्म हो जाएगा A के उत्पादन में D - इस अप्रत्याशित परिणाम हो सकता है।

परियोजना संदर्भों के लिए चेतावनी

परियोजना संदर्भों में कुछ ट्रेड-ऑफ हैं जिनके बारे में आपको अवगत होना चाहिए।

क्योंकि निर्भर परियोजनाओं का इस्तेमाल करते हैं .d.ts फ़ाइलों है कि उनके निर्भरता से निर्माण कर रहे हैं, आप या तो नकली देखे बिना कुछ निर्माण आउटपुट में की जाँच करें या यह क्लोनिंग के बाद एक परियोजना का निर्माण करने से पहले आप एक संपादक में इस परियोजना को नेविगेट कर सकते हैं होगा त्रुटियाँ।
हम एक परदे के पीछे की .d.ts पीढ़ी की प्रक्रिया पर काम कर रहे हैं जो इसे कम करने में सक्षम होनी चाहिए, लेकिन अभी के लिए हम डेवलपर्स को सूचित करने की सलाह देते हैं कि उन्हें क्लोनिंग के बाद निर्माण करना चाहिए।

इसके अतिरिक्त, मौजूदा बिल्ड वर्कफ़्लो के साथ संगतता बनाए रखने के लिए, tsc स्वचालित रूप से निर्भरता का निर्माण नहीं करेगा जब तक कि --build स्विच के साथ लागू नहीं किया जाता है।
आइए --build बारे में और जानें।

टाइपस्क्रिप्ट के लिए बिल्ड मोड

एक लंबे समय से प्रतीक्षित विशेषता टाइपस्क्रिप्ट परियोजनाओं के लिए स्मार्ट वृद्धिशील बिल्ड है।
3.0 में आप --build ध्वज का उपयोग tsc ।
यह प्रभावी रूप से tsc लिए एक नया प्रवेश बिंदु है जो एक साधारण कंपाइलर की तुलना में बिल्ड ऑर्केस्ट्रेटर की तरह व्यवहार करता है।

tsc --build ( tsc -b संक्षेप में) चलाना निम्नलिखित कार्य करेगा:

सभी संदर्भित प्रोजेक्ट खोजें
पता लगाएँ कि क्या वे अप-टू-डेट हैं
पुरानी परियोजनाओं को सही क्रम में बनाएं

आप tsc -b एकाधिक कॉन्फ़िगरेशन फ़ाइल पथ (उदाहरण tsc -b src test ) के साथ प्रदान कर सकते हैं।
tsc -p , कॉन्फ़िगरेशन फ़ाइल नाम निर्दिष्ट करना स्वयं अनावश्यक है यदि इसका नाम tsconfig.json ।

`tsc -b` कमांडलाइन

आप किसी भी संख्या में कॉन्फिग फाइल निर्दिष्ट कर सकते हैं:

 > tsc -b                                # Build the tsconfig.json in the current directory
 > tsc -b src                            # Build src/tsconfig.json
 > tsc -b foo/release.tsconfig.json bar  # Build foo/release.tsconfig.json and bar/tsconfig.json

कमांडलाइन पर आपके द्वारा पास की गई फ़ाइलों को ऑर्डर करने के बारे में चिंता न करें - tsc जरूरत पड़ने पर उन्हें फिर से ऑर्डर करेगा ताकि निर्भरता हमेशा पहले बनी रहे।

tsc -b लिए विशिष्ट कुछ झंडे भी हैं:

--verbose : क्या हो रहा है यह समझाने के लिए वर्बोज़ लॉगिंग को प्रिंट करता है (किसी अन्य ध्वज के साथ जोड़ा जा सकता है)
--dry : दिखाता है कि क्या किया जाएगा लेकिन वास्तव में कुछ भी नहीं बनाता है
--clean : निर्दिष्ट परियोजनाओं के आउटपुट को हटाता है ( --dry के साथ जोड़ा जा सकता है)
--force : ऐसा व्यवहार करें जैसे कि सभी प्रोजेक्ट पुराने हैं
--watch : वॉच मोड ( --verbose को छोड़कर किसी भी ध्वज के साथ जोड़ा नहीं जा सकता है)

चेतावनियां

आम तौर पर, tsc सिंटैक्स या टाइप त्रुटियों की उपस्थिति में आउटपुट ( .js और .d.ts ) का उत्पादन करेगा, जब तक कि noEmitOnError चालू न हो।
एक वृद्धिशील निर्माण प्रणाली में ऐसा करना बहुत बुरा होगा - यदि आपकी पुरानी निर्भरताओं में से एक में कोई नई त्रुटि थी, तो आप इसे केवल एक बार देखेंगे क्योंकि बाद का निर्माण अब अप-टू-डेट प्रोजेक्ट का निर्माण छोड़ देगा।
इस कारण से, tsc -b प्रभावी रूप से कार्य करता है जैसे कि सभी परियोजनाओं के लिए noEmitOnError सक्षम है।

यदि आप किसी भी बिल्ड आउटपुट ( .js , .d.ts , .d.ts.map , आदि) की जांच करते हैं, तो आपको कुछ स्रोत नियंत्रण के बाद --force बिल्ड चलाने की आवश्यकता हो सकती है संचालन इस पर निर्भर करता है कि आपका स्रोत नियंत्रण उपकरण स्थानीय प्रतिलिपि और दूरस्थ प्रतिलिपि के बीच टाइमस्टमैप को सुरक्षित रखता है या नहीं।

एमएसबिल्ड

यदि आपके पास एक एमएसबिल्ड प्रोजेक्ट है, तो आप जोड़कर सक्षम बिल्ड मोड चालू कर सकते हैं

    <TypeScriptBuildMode>true</TypeScriptBuildMode>

आपकी प्रोज फ़ाइल में। यह स्वचालित वृद्धिशील निर्माण के साथ-साथ सफाई को भी सक्षम करेगा।

ध्यान दें कि tsconfig.json / -p , मौजूदा टाइपस्क्रिप्ट प्रोजेक्ट गुणों का सम्मान नहीं किया जाएगा - सभी सेटिंग्स को आपकी tsconfig फ़ाइल का उपयोग करके प्रबंधित किया जाना चाहिए।

कुछ टीमों ने एमएसबिल्ड-आधारित वर्कफ़्लोज़ सेट अप किया है जिसमें tsconfig फ़ाइलों में एक ही अंतर्निहित ग्राफ़ ऑर्डरिंग है जो प्रबंधित प्रोजेक्ट्स के साथ जोड़ा जाता है।
यदि आपका समाधान ऐसा है, तो आप परियोजना संदर्भों के साथ msbuild साथ tsc -p का उपयोग करना जारी रख सकते हैं; ये पूरी तरह से इंटरऑपरेबल हैं।

दिशा निर्देश

समग्र संरचना

अधिक tsconfig.json फ़ाइलों के साथ, आप आमतौर पर अपने सामान्य कंपाइलर विकल्पों को केंद्रीकृत करने के लिए कॉन्फ़िगरेशन फ़ाइल विरासत का उपयोग करना चाहेंगे।
इस तरह आप एकाधिक फ़ाइलों को संपादित करने के बजाय एक फ़ाइल में सेटिंग बदल सकते हैं।

एक और अच्छा अभ्यास एक "समाधान" tsconfig.json फ़ाइल है जिसमें आपकी सभी लीफ-नोड परियोजनाओं के लिए बस references है।
यह एक साधारण प्रवेश बिंदु प्रस्तुत करता है; उदाहरण के लिए टाइपस्क्रिप्ट रेपो में हम सभी एंडपॉइंट बनाने के लिए बस tsc -b src चलाते हैं क्योंकि हम सभी सबप्रोजेक्ट्स को src/tsconfig.json में सूचीबद्ध करते हैं
ध्यान दें कि 3.0 से शुरू होने पर, यदि आपके पास tsconfig.json फ़ाइल में कम से कम एक reference है, तो अब खाली files सरणी होने में कोई त्रुटि नहीं है।

आप इन पैटर्न को टाइपस्क्रिप्ट रेपो में देख सकते हैं - src/tsconfig_base.json , src/tsconfig.json , और src/tsc/tsconfig.json प्रमुख उदाहरणों के रूप में देखें।

सापेक्ष मॉड्यूल के लिए संरचना

सामान्य तौर पर, सापेक्ष मॉड्यूल का उपयोग करके रेपो को बदलने के लिए बहुत अधिक आवश्यकता नहीं होती है।
किसी दिए गए मूल फ़ोल्डर की प्रत्येक उपनिर्देशिका में बस एक tsconfig.json फ़ाइल रखें, और प्रोग्राम की इच्छित लेयरिंग से मेल खाने के लिए इन कॉन्फ़िग फ़ाइलों में reference s जोड़ें।
आपको या तो outDir को आउटपुट फ़ोल्डर के स्पष्ट सबफ़ोल्डर में सेट करना होगा, या rootDir को सभी प्रोजेक्ट फ़ोल्डरों के सामान्य रूट पर सेट करना होगा।

आउटफाइल के लिए संरचना

outFile का उपयोग करके संकलन के लिए लेआउट अधिक लचीला है क्योंकि सापेक्ष पथ उतना मायने नहीं रखता है।
ध्यान रखने वाली एक बात यह है कि आप आम तौर पर "अंतिम" प्रोजेक्ट तक prepend उपयोग नहीं करना चाहेंगे - इससे बिल्ड समय में सुधार होगा और किसी भी बिल्ड में आवश्यक I/O की मात्रा कम हो जाएगी।
टाइपस्क्रिप्ट रेपो अपने आप में एक अच्छा संदर्भ है - हमारे पास कुछ "लाइब्रेरी" प्रोजेक्ट और कुछ "एंडपॉइंट" प्रोजेक्ट हैं; "समापन बिंदु" परियोजनाओं को जितना संभव हो उतना छोटा रखा जाता है और केवल उन पुस्तकालयों में खींचा जाता है जिनकी उन्हें आवश्यकता होती है।

monorepos . के लिए संरचना

TODO: अधिक प्रयोग करें और इसका पता लगाएं। ऐसा लगता है कि रश और लर्न के पास अलग-अलग मॉडल हैं जो हमारे अंत में अलग-अलग चीजें दर्शाते हैं

RyanCavanaugh 26 जून 2018

👍26 ❤15

सभी 147 टिप्पणियाँ

हे भगवान!

nycdotnet 10 जून 2015

❤1

:+1:

unional 11 जून 2015

हां! यह आपके द्वारा प्रदान किए गए उपयोग-मामलों के लिए एकदम सही समझ में आता है। हमारे द्वारा उपयोग किए जाने वाले टूल को बेहतर तरीके से प्रदान करना कि हमारे कोड का उपभोग करने का इरादा कैसे है, निश्चित रूप से सही काम है। हर बार जब मैं गलती से .d.ts फ़ाइल में F12 करता हूँ तो मुझे लगता है कि मैं बिल्ली के बच्चे का गला घोंट रहा हूँ!

kungfusheep 11 जून 2015

जोनाथन,

इस तरह की प्रतिक्रिया के लिए और इसे लेने का निर्णय लेने के लिए बहुत-बहुत धन्यवाद। टाइपस्क्रिप्ट एक ऐसा महान उपकरण है और यह कार्यक्षमता कई लोगों की मदद करेगी जो अपने मध्यम आकार के कोडबेस को घटक बनाना चाहते हैं जो बड़ी परियोजनाओं द्वारा अनिवार्य अक्षमता को उचित नहीं ठहरा सकते हैं जो चिंताओं के सख्त विभाजन पर भरोसा करते हैं (उदाहरण के लिए एज़ूर पोर्टल्स या प्रोजेक्ट मोनाकोस का दुनिया> 100kloc और कई स्वतंत्र टीमों के साथ)। दूसरे शब्दों में, यह वास्तव में "नियमित लोगों" की मदद करेगा। साथ ही, अन्य लोगों ने इसके लिए पहले से ही सामग्री का प्रस्ताव दिया है, उदाहरण के लिए @NoelAbrahams (#2180), और अन्य इसलिए मैं यहां मौलिकता का दावा नहीं कर सकता। यह कुछ ऐसा है जिसकी मुझे कुछ समय से आवश्यकता थी।

मुझे लगता है कि आपका प्रस्ताव उत्कृष्ट है। मेरे प्रस्ताव (#3394) की तुलना में केवल एक ही कमी है, जिसे मैंने अब बंद कर दिया है, वह है संदर्भों के लिए फॉलबैक तंत्र की कमी।

निम्नलिखित वास्तविक दुनिया के परिदृश्य पर विचार करें जो मैंने यहां विस्तृत किया है: https://github.com/Microsoft/TypeScript/issues/3394#issuecomment -109359701

मेरे पास एक टाइपस्क्रिप्ट प्रोजेक्ट ग्रंट-टीएस है जो एक अलग प्रोजेक्ट csproj2ts पर निर्भर करता है। ग्रंट-टीएस पर काम करने वाला शायद ही कोई csproj2ts पर काम करना चाहेगा क्योंकि इसकी कार्यक्षमता का दायरा बहुत सीमित है। हालांकि, मेरे जैसे किसी व्यक्ति के लिए - दोनों परियोजनाओं पर एक साथ काम करने में सक्षम होना और रिफैक्टरिंग करना/परिभाषा पर जाना/उनमें सभी संदर्भ ढूंढना बहुत अच्छा होगा।

जब मैंने अपना प्रस्ताव दिया, तो मैंने सुझाव दिया कि निर्भरता वस्तु नामित फॉलबैक के साथ एक वस्तु शाब्दिक हो। आपके प्रस्ताव को ध्यान में रखते हुए एक और संस्करण होगा:

"dependencies": {
   "csproj2ts": ["../csproj2ts","node_modules/csproj2ts/csproj2ts.d.ts"],
   "SomeRequiredLibrary": "../SomeRequiredLibraryWithNoFallback"
}

इसे अभी भी एक सरणी के रूप में सरल बनाने के लिए, मैं ग्रंट-टीएस tsconfig.json फ़ाइल के भविष्य के काल्पनिक dependencies अनुभाग के निम्नलिखित वैकल्पिक कार्यान्वयन का सुझाव देता हूं:

"dependencies": [
   ["../csproj2ts","node_modules/csproj2ts/csproj2ts.d.ts"],
   "../SomeRequiredLibraryWithNoFallback"
]

dependencies में प्रत्येक सरणी-प्रकार के आइटम के लिए रिज़ॉल्यूशन नियम होगा: _first_ आइटम जो प्रत्येक में पाया जाता है वह वह है जिसका उपयोग किया जाता है, और बाकी को अनदेखा कर दिया जाता है। स्ट्रिंग-प्रकार की वस्तुओं को जोनाथन के प्रस्ताव के अनुसार ही नियंत्रित किया जाता है।

यह एक बहुत ही थोड़ा अधिक जटिल-से-कार्यान्वयन समाधान है, हालांकि यह डेवलपर (और पुस्तकालय लेखकों) को अधिक से अधिक लचीलापन देता है। उन डेवलपर्स के लिए जिन्हें csproj2ts पर विकसित करने की आवश्यकता नहीं है (और इसलिए ../csproj2ts/tsconfig.json फ़ाइल नहीं है), निर्भरता केवल एक परिभाषा फ़ाइल होगी जो संकलन संदर्भ में जुड़ जाती है। जिन डेवलपर्स के पास _do_ के पास ../csproj2ts/tsconfig.json फ़ाइल है, उनके लिए प्रस्ताव ठीक वैसे ही काम करेगा जैसा आपने ऊपर बताया है।

उपरोक्त उदाहरण में, आपके मौजूदा प्रस्ताव की तरह ही "../SomeRequiredLibraryWithNoFallback" आवश्यकता होगी, और इसकी अनुपस्थिति एक कंपाइलर त्रुटि होगी।

इस पर विचार करने के लिए आपका बहुत-बहुत धन्यवाद।

nycdotnet 11 जून 2015

यहाँ दो समस्याएँ हैं जिन्हें हमें अलग करने की आवश्यकता है, वहाँ निर्माण है, और भाषा सेवा समर्थन है।

बिल्ड के लिए, मुझे नहीं लगता कि tsconfig इसके लिए सही जगह है। यह स्पष्ट रूप से एक बिल्ड सिस्टम समस्या है। इस प्रस्ताव के साथ टाइपस्क्रिप्ट कंपाइलर को निम्न के व्यवसायों में होना चाहिए:

निर्भरता का पता लगाना
अप-टू-डेट जांचों के लिए मुखर
कॉन्फ़िगरेशन प्रबंधन (रिलीज़ बनाम डीबग)

ये सभी स्पष्ट रूप से बिल्ड सिस्टम की जिम्मेदारी हैं; ये कठिन समस्याएं हैं और पहले से ही ऐसे उपकरण हैं जो ऐसा करते हैं, जैसे एमएसबिल्ड, ग्रंट, गल्प इत्यादि।
एक बार जब tsconfig और tsc बिल्ड ड्राइवर बन जाते हैं तो आप चाहते हैं कि यह सभी CPU का उपयोग असंबंधित उपट्री बनाने के लिए करे, या प्रत्येक प्रोजेक्ट के लिए पोस्ट और प्री बिल्ड कमांड हो, और संभवतः अन्य प्रोजेक्ट भी बना सके। फिर से, मुझे लगता है कि वहां ऐसे निर्माण उपकरण हैं जो वे जो करते हैं उसमें अच्छे हैं, और हमें इसे फिर से बनाने की कोई आवश्यकता नहीं है।

भाषा सेवा के लिए,
मुझे लगता है कि टूलिंग के लिए कई tsconfig फाइलों के बारे में जानना ठीक है और इससे अनुमान लगाया जा सकता है और आपको और मदद मिल सकती है, लेकिन इससे आपके निर्माण को प्रभावित नहीं होना चाहिए। मैं कुछ ऐसा मानूंगा:

"files" : [
    "file1.ts",
    {
        "path": "../projectB/out/projectB.d.ts",
         "sourceProject": "../projectB/"
     }
]

जहां tsc केवल "पथ" को देखेगा, लेकिन उपकरण अन्य सूचनाओं को देख सकते हैं और यथासंभव सहायक होने का प्रयास कर सकते हैं।

मैं समस्या के अस्तित्व को स्वीकार करता हूं लेकिन यह नहीं सोचता कि लंपिंग बिल्ड और टूलिंग सही समाधान है। tsconfig.json एक कॉन्फ़िगरेशन बैग (यानी प्रतिक्रिया फ़ाइलों के लिए एक json विकल्प) बना रहना चाहिए, एक बिल्ड सिस्टम नहीं बनना चाहिए। एक tsconfig.json एकल tsc आमंत्रण का प्रतिनिधित्व करता है। tsc सिंगल प्रोजेक्ट कंपाइलर के रूप में रहना चाहिए।

वीएस में एमएसबिल्ड परियोजनाएं आईडीई सुविधाओं के निर्माण के लिए बिल्ड सिस्टम का उपयोग करने का एक उदाहरण हैं और अब पीपीएल इससे खुश नहीं हैं क्योंकि यह बहुत बड़ा है।

mhegazy 11 जून 2015

आपके उत्तर के लिए धन्यवाद, मोहम्मद। मुझे यह देखने के लिए पुन: प्रयास करने दें कि क्या मैं समझता हूं:

आपको लगता है कि मल्टी-प्रोजेक्ट बिल्ड के समन्वय का कार्य समर्पित बिल्ड टूल्स का डोमेन रहना चाहिए।
आपको लगता है कि टाइपस्क्रिप्ट भाषा सेवा के लिए इस सुझाव में कुछ हो सकता है।
आपको लगता है कि इस tsc --project पर tsconfig.json चलाना tsc file1.ts ../project/out/project.d.ts चलाने जैसा ही होगा। हालांकि, वीएस या टाइपस्क्रिप्ट भाषा सेवा के साथ किसी अन्य संपादक में इस तरह की एक परियोजना खोलने से डेवलपर को _वास्तविक टाइपस्क्रिप्ट फ़ाइल_ में लाने के लिए "परिभाषा पर जाने" की अनुमति मिल जाएगी जहां सुविधा परिभाषित की गई थी ( projectB.d.ts में परिभाषा के बजाय)

क्या मेरे पास वह अधिकार है?

अगर ऐसा है तो मुझे लगता है कि यह बहुत ही उचित है। मेरे मूल प्रस्ताव (https://github.com/Microsoft/TypeScript/issues/3394) में, मैंने कहा था कि मेरा विचार अधूरा था क्योंकि इसमें उत्सर्जित परिणामों की प्रतिलिपि बनाने का चरण शामिल नहीं था जहां से वे आउटपुट होंगे संदर्भित पुस्तकालय में जहां संदर्भ पुस्तकालय उन्हें रनटाइम पर उम्मीद करेगा। मुझे लगता है कि आप कह रहे हैं "निर्माण के लिए सड़क के आधे रास्ते नीचे क्यों जाएं जब वास्तव में भाषा सेवा समर्थन की आवश्यकता होती है"।

अपने उदाहरण में डेटा को थोड़ा बदलने के लिए, क्या आप कुछ इस तरह का समर्थन करने के इच्छुक होंगे?

"files" : [
    "file1.ts",
    {
        "path": "externalLibraries/projectB.d.ts",
         "sourceProject": "../projectB/"
     }
]

धारणा यह है कि वर्तमान प्रोजेक्ट प्रोजेक्टबी के लिए एक परिभाषा के साथ शिप करेगा जो डिफ़ॉल्ट रूप से उपयोग किया जाएगा, लेकिन यदि प्रोजेक्टबी के लिए वास्तविक स्रोत उपलब्ध है, तो इसके बजाय वास्तविक स्रोत का उपयोग किया जाएगा।

nycdotnet 11 जून 2015

@nycdotnet आपने इसे सही बताया; मैं एक ऐसी प्रणाली बनाना चाहता हूं जो शिथिल रूप से युग्मित हो और अलग-अलग IDE के साथ अलग-अलग बिल्ड टूल्स को मिलाने और मिलान करने की अनुमति दे लेकिन फिर भी एक बेहतरीन डिज़ाइन समय का अनुभव प्राप्त करें।

mhegazy 12 जून 2015

बहुत अच्छा लगता है!

nycdotnet 12 जून 2015

मैं @mhegazy से सहमत

फ़ाइल और पैकेज रिज़ॉल्यूशन उस बिल्ड सिस्टम की ज़िम्मेदारी है जिसका आप उपयोग कर रहे हैं (ब्राउज़राइज़, सिस्टमज, वेबपैक इत्यादि), इसलिए टूलींग को काम करने के लिए भाषा सेवा को फाइलों को उसी तरह हल करने में सक्षम होना चाहिए जैसे कि आप जो भी सिस्टम/प्लेटफार्म बनाते हैं का उपयोग कर रहे हैं। इसका मतलब या तो प्रत्येक बिल्ड सिस्टम के लिए एक कस्टम LanguageServicesHost लागू करना या प्रत्येक के लिए एक टूल प्रदान करना है जो tsconfig.json में सही मैपिंग प्रविष्टियां उत्पन्न करता है। इनमें से कोई भी स्वीकार्य है।

@nycdotnet मुझे लगता है कि एकाधिक फ़ॉलबैक पथों के लिए आपके उपयोग के मामले को npm link ../csproj2ts का उपयोग करके बेहतर तरीके से संभाला जाएगा?

frankwallis 14 जून 2015

👍1

मैं @mhegazy से सहमत

"फाइलें" : [
{
"पथ": "externalLibraries/projectB.d.ts",
"सोर्सप्रोजेक्ट": "../प्रोजेक्टबी/"
}
]

tsconfig.json फ़ाइल वाली निर्देशिका और उपनिर्देशिका में अभी भी सभी ts फ़ाइलें शामिल होंगी।

dbaeumer 16 जून 2015

@dbaeumer फिर आप इसे एक अलग संपत्ति में रखना चाहते हैं, है ना? वर्तमान में, यदि फ़ाइलें परिभाषित हैं, तो इसका हमेशा उपयोग किया जाता है और हम शामिल *.ts भाग को अनदेखा कर देते हैं।

mhegazy 16 जून 2015

@mhegazy जरूरी नहीं कि एक अलग खंड हो, हालांकि यह अंत में चीजों को स्पष्ट कर देगा। अगर मैं tsconfig -> tsconfig निर्भरता का उपयोग करता हूं तो मैं सभी फाइलों को सूचीबद्ध करने के लिए मजबूर होना चाहता हूं। उपरोक्त उदाहरण में मैं अभी भी किसी *.ts फ़ाइलों को कंपाइलर में फीड करने के लिए सूचीबद्ध नहीं करना चाहूंगा।

dbaeumer 6 जुल॰ 2015

मुझे लगता है कि इसकी बहुत जरूरत है। मुझे नहीं लगता कि हम बिल्ड प्रश्न से बच सकते हैं। इसका मतलब यह नहीं है कि हमें इस प्रस्ताव के साथ एक बिल्ड सिस्टम को लागू करने की आवश्यकता है, लेकिन हमें कुछ अच्छे मार्गदर्शन के बारे में सोचना चाहिए जो कि प्रस्तावित जैसे कॉन्फ़िगरेशन में काम करता है। सही होने के लिए यह गैर-तुच्छ होगा (और हमें इसे विजुअल स्टूडियो के लिए हल करने की आवश्यकता है)।

उपरोक्त प्रस्ताव में (जहां .d.ts और स्रोत दोनों को संदर्भित किया गया है), क्या यह पता लगाता है कि क्या .d.ts पुराना है (यानी फिर से बनाने की आवश्यकता है)? क्या परियोजनाओं में रिफैक्टर/नाम बदलें जैसे संचालन काम करते हैं (यानी संदर्भित परियोजना स्रोत में नाम अपडेट करता है, न कि केवल इसकी .d.ts फ़ाइल जो अगले निर्माण को अधिलेखित कर देगी)? क्या GoToDef मुझे संदर्भित प्रोजेक्ट में मूल कोड पर ले जाता है (पूरे प्रोजेक्ट के लिए एक विशाल .d.ts फ़ाइल के बीच में नहीं)? ऐसा लगता है कि इसे हल करने की आवश्यकता है, और कुछ मामलों में संदर्भित परियोजनाओं के स्रोत का विश्लेषण करते हैं, किस मामले में .d.ts उपयोगी है?

billti 13 जुल॰ 2015

सामान्य समाधान, जो आज हमारे पास है, आपके पास एक प्रोजेक्ट के बिल्ड आउटपुट के रूप में एक .d.ts है, और फिर दूसरे प्रोजेक्ट में इनपुट के रूप में संदर्भित है। यह निर्माण के लिए ठीक काम करता है, इसलिए इसे बदलने की कोई आवश्यकता नहीं है।

समस्या संपादन परिदृश्य है। आप संपादन करते समय जेनरेट की गई फ़ाइल से नहीं गुजरना चाहते हैं। मेरा प्रस्तावित समाधान एक "संकेत" प्रदान करना है जहां से उत्पन्न .d.ts आया था। भाषा सेवा तब .d.ts लोड नहीं करेगी, और इसके बजाय संकेत पथ से "प्रोजेक्ट" लोड करेगी। इस तरह गोटो डीफ़ आपको .d.ts के बजाय कार्यान्वयन फ़ाइल में ले जाएगा और इसी तरह त्रुटियाँ संकलन की आवश्यकता के बिना काम करेंगी।

नाम बदलने जैसे संचालन, एक परियोजना से दूसरी परियोजना में "प्रचार" करेंगे, इसी तरह संदर्भ ढूंढेंगे, करेंगे।

mhegazy 13 जुल॰ 2015

आज यह पूरी तरह से tsconfig.json फ़ाइल को खोजने के लिए होस्ट (आईडीई, जो कुछ भी) पर निर्भर है, हालांकि टीएस फिर इसे पढ़ने और पार्स करने के लिए एपीआई प्रदान करता है। आप इस कार्य की कल्पना कैसे करेंगे यदि एक पदानुक्रमित फैशन में कई tsconfig.json स्थित हों? क्या होस्ट अभी भी प्रारंभिक फ़ाइल को हल करने के लिए ज़िम्मेदार होगा, लेकिन अन्य नहीं या होस्ट सभी tsconfigs को हल करने के लिए ज़िम्मेदार होगा?

ऐसा लगता है कि सुविधा/सम्मेलन और लचीलेपन के बीच एक समझौता है।

jbrantly 6 अग॰ 2015

क्या यह #2568 (या कम से कम सापेक्ष आयात) में वर्णित d.ts फ़ाइलों को बनाने की क्षमता से शुरू नहीं होगा?

spion 6 अग॰ 2015

@spion मुझे यकीन नहीं है कि मैं यहां निर्भरता देखता हूं। आपके पास एक प्रोजेक्ट के कई आउटपुट हो सकते हैं, इसमें आपके पास एक एकल डिलेक्टेशन फ़ाइल नहीं है। बिल्ड सिस्टम को यह जानने में सक्षम होना चाहिए और उन्हें निर्भर परियोजनाओं के इनपुट के रूप में तारित करना चाहिए।

mhegazy 7 अग॰ 2015

@mhegazy ओह, क्षमा करें। इस मुद्दे को फिर से देखने पर ऐसा प्रतीत होता है कि यह भाषा सेवा से अधिक संबंधित है। मैंने निम्नलिखित पढ़ा:

मध्यम आकार की परियोजनाएं: मानक निर्माण और साझा घटकों के साथ

और स्वचालित रूप से एनपीएम/ब्राउज़राइज़ (या वेबपैक) के लिए बेहतर समर्थन से संबंधित माना जाता है, जहां परियोजना के हिस्से बाहरी मॉड्यूल हैं।

AFAIK बाहरी मॉड्यूल के लिए अभी तक .d.ts फ़ाइल उत्पन्न करने का कोई तरीका नहीं है? यदि ऐसा है, तो एक भाषा सेवा बाहरी मॉड्यूल आयात करने वाली परियोजनाओं को जोड़ने का एकमात्र तरीका tsconfig.json में ऐसा कुछ होना होगा:

{ 
  "provides": "external-module-name"
}

जो परियोजनाओं को किसी अन्य tsconfig.json में संदर्भित किए जाने पर LS को सूचित करेगा

spion 7 अग॰ 2015

AFAIK बाहरी मॉड्यूल के लिए अभी तक .d.ts फ़ाइल उत्पन्न करने का कोई तरीका नहीं है?

मुझे नहीं लगता कि यह सच है। tsc --m --d कॉल करने से एक डिक्लेरेशन फाइल जेनरेट होगी जो एक बाहरी मॉड्यूल है। संकल्प तर्क एक .ts खोजने की कोशिश करेगा और यदि नहीं तो उसी नाम के साथ एक .d.ts,

mhegazy 7 अग॰ 2015

@spion टाइपस्क्रिप्ट बाहरी मॉड्यूल के लिए d.ts फाइलें उत्पन्न कर सकता है जैसा कि @mhegazy ने कहा, लेकिन इसका परिणाम स्रोत फ़ाइलों की परिभाषाओं के 1:1 अनुपात में होता है जो कि लाइब्रेरी की टाइपस्क्रिप्ट परिभाषाओं का आम तौर पर उपभोग करने से अलग है। इसे हल करने का एक तरीका यह टाइपस्ट्रांग लाइब्रेरी है: https://github.com/TypeStrong/dts-bundle

nycdotnet 7 अग॰ 2015

@mhegazy क्षमा करें, मेरा मतलब "परिवेश बाहरी मॉड्यूल" के लिए था, यानी अगर मैं टाइपस्क्रिप्ट में external-module-name लिखता हूं और इसकी एक कक्षा को दूसरे मॉड्यूल से आयात करता हूं:

import {MyClass} from 'external-module-name'

वहाँ बनाने के लिए कोई रास्ता नहीं है tsc उचित .d.ts फ़ाइल कि वाणी उत्पन्न 'external-module-name'

@nycdotnet मुझे डीटीएस-बंडल और डीटीएस-जनरेटर के बारे में पता है लेकिन फिर भी अगर भाषा सेवा को मेरी अन्य परियोजना के स्रोत के बारे में जानना है, तो यह भी पता होना चाहिए कि यह कौन सा मॉड्यूल नाम प्रदान करता है ताकि आयात को सही तरीके से ट्रैक किया जा सके

spion 8 अग॰ 2015

इस सुविधा की स्थिति क्या है? ऐसा लगता है कि मध्यम आकार की परियोजनाओं के लिए यह एक महत्वपूर्ण विकल्प है। आप उस प्रोजेक्ट को कैसे कॉन्फ़िगर करते हैं जिसमें विशिष्ट "requirejs" कॉन्फ़िगरेशन के साथ विभिन्न फ़ोल्डरों में स्रोत है?

llgcode 29 फ़र॰ 2016

@llgcode कृपया https://github.com/Microsoft/TypeScript/issues/5039 पर एक नज़र डालें, यह typescript@next में उपलब्ध होना चाहिए।

mhegazy 29 फ़र॰ 2016

मुझे वास्तव में यह नहीं मिलता है कि उप-परियोजनाओं को संकलित करने वाले कार्यों के साथ एक गल्पफाइल लिखने के बारे में इतना कठिन क्या है कि आपको मध्यम आकार की परियोजनाओं के लिए इसकी आवश्यकता कैसे होती है। मैं इसे छोटे आकार की परियोजनाओं में भी करता हूं। मेरे द्वारा tsconfig.json का उपयोग करने का एकमात्र कारण वीएस कोड है

felixfbecker 9 मार्च 2016

पहले मैं गल्प का उपयोग नहीं करता। दूसरा यह एक बड़ी परियोजना हो सकती है जहां आप हर बार पुन: संकलित नहीं करना चाहते हैं। लेकिन अगर आपके पास गल्प के साथ अच्छा समाधान है तो मुझे बताएं कि यह कैसे करें।

llgcode 9 मार्च 2016

@llgcode ठीक है, गल्प एक कार्य धावक है। आप एक gulpfile.js लिखते हैं जहाँ आप gulp.task() साथ जितने चाहें उतने कार्यों को परिभाषित करते हैं। अपने कार्य के अंदर, आप gulp.src() साथ इनपुट फ़ाइलों की एक धारा ले सकते हैं और फिर .pipe() उन्हें रूपांतरणों की एक पाइपलाइन के माध्यम से ले सकते हैं, जैसे संकलन, संयोजन, खनन, स्रोतमैप, संपत्ति की प्रतिलिपि बनाना ... आप कर सकते हैं कुछ भी करें जो नोड और एनपीएम मॉड्यूल के साथ संभव हो।
यदि आपको कई परियोजनाओं को संकलित करना है, तो बस उस कार्य को परिभाषित करें जो ऐसा करता है। यदि आप एकाधिक tsconfig.json का उपयोग करना चाहते हैं, तो गल्प-टाइपस्क्रिप्ट के पास इसके लिए समर्थन है, या आप केवल जेसन फाइलों को पढ़ सकते हैं। वृद्धिशील निर्माण भी संभव हैं। मुझे नहीं पता कि आपकी परियोजना कैसे संरचित है, यदि आपके पास उन्हें अलग-अलग रेपो में है और सबमॉड्यूल का उपयोग करें, या जो भी हो। लेकिन गल्प 100% लचीला है।

felixfbecker 9 मार्च 2016

ठीक है धन्यवाद एक अच्छा उपकरण प्रतीत होता है। अगर मुझे आवश्यकता ("mylibs/lib") जैसे मैपिंग की आवश्यकता है और मेरी फाइलें उदाहरण के लिए एक फ़ोल्डर प्रोजेक्ट/src/lib.js में हैं तो पूर्णता परमाणु में काम नहीं करेगी और मुझे नहीं पता कि टाइपस्क्रिप्ट या गल्प कैसे हल होगा मैपिंग/कॉन्फ़िगरेशन "mylibs" और स्थानीय पथ के साथ किया गया। इसलिए मुझे लगता है कि #5039 में यह नया विकल्प पथ इस समस्या का एक अच्छा समाधान है।

llgcode 9 मार्च 2016

@llgcode अच्छी तरह से गल्प के साथ आप ग्लोब के साथ सभी फाइलें (.d.ts फाइलों सहित) प्राप्त कर सकते हैं, देखें https://www.npmjs.com/package/gulp-typescript#resolving -files।

मुझे लगता है कि टाइपस्क्रिप्ट यहां बहुत कुछ करने की कोशिश कर रहा है, यह एक ट्रांसपिलर है न कि एक बिल्ड टूल। प्रस्ताव में उल्लिखित "निर्भरता" का प्रबंधन वास्तव में पैकेज प्रबंधकों या संस्करण नियंत्रण प्रणालियों का कार्य है और उन्हें एक साथ तार-तार करना उपकरण बनाने का कार्य है।

felixfbecker 9 मार्च 2016

@felixfbecker मैं सहमत नहीं हूँ। मुझे पता है कि प्रत्येक कंपाइलर (टाइप चेकिंग के साथ) इस तरह का एक विकल्प है। उदाहरण के लिए:
जीसीसी -> फाइलें शामिल करें
जावा -> क्लासपाथ और सोर्सपाथ
जाओ -> गोपथ
अजगर -> अजगरपथ
कंपाइलर/ट्रांसपिलर को यह जानने की जरूरत है कि कौन सी सोर्स फाइल्स को ट्रांसपाइल करने की जरूरत है, कौन सी सोर्स फाइल्स में सिर्फ शामिल/लिब फाइलें हैं।
फ़ाइल बदलने पर क्या करना है, यह जानने के लिए गल्प जैसे बिल्ड टूल की आवश्यकता होती है।

llgcode 9 मार्च 2016

@llgcode से सहमत हैं। इसके अलावा, एक कंपाइलर के रूप में एक्सपोज़ करने के अलावा, टाइपस्क्रिप्ट एक भाषा सेवा के रूप में भी उजागर होती है, जो IDE को सिंटैक्स हाइलाइट (वास्तव में पता लगाने) और पूर्णता कार्यक्षमता प्रदान करती है। और उसे भी निर्भरता के पेड़ पर चलने की जरूरत है।

unional 9 मार्च 2016

@llgcode @unional मान्य अंक। एक बात यह भी मदद करता है कि हो सकता है बनाने के लिए files tsconfig.json globs स्वीकार ताकि आप सभी फ़ोल्डर आप शामिल करना चाहते में सभी फाइलों को परिभाषित कर सकते में संपत्ति। लेकिन मैं देख रहा हूं कि आप कहां से आ रहे हैं और बड़ी परियोजनाओं के लिए एक से अधिक tsconfig.json क्यों चाहते हैं।

felixfbecker 9 मार्च 2016

कॉमनजेएस के लिए AFAIK यह पहले से ही node_modules और npm link ../path/to/other-project माध्यम से समर्थित है

spion 9 मार्च 2016

जैसे ही आप परियोजनाओं में पुस्तकालयों का पुन: उपयोग करना शुरू करते हैं, एनपीएम लिंक काम नहीं करता है। यदि आप अपनी खुद की दो अलग-अलग परियोजनाओं के बीच एक सामान्य पुस्तकालय का उपयोग करते हैं, (उदाहरण के रूप में rxjs लेते हुए) टाइपस्क्रिप्ट आपको बताएगा कि 'ऑब्जर्वेबल ऑब्जर्वेबल को असाइन करने योग्य नहीं है'। ऐसा इसलिए है क्योंकि शामिल पथ दो अलग-अलग नोड_मॉड्यूल फ़ोल्डरों में सिमलिंक फ़ोल्डरों का अनुसरण कर रहे हैं और एक ही पुस्तकालय होने के बावजूद। समाधान के परिणामस्वरूप गल्प कार्य या स्थानीय/निजी npm रेपो का निर्माण होता है, मूल रूप से बड़े प्रोजेक्ट विकल्प पर वापस।

EricABC 19 मार्च 2016

@EricABC शायद इसलिए कि वे परिवेशी बाहरी मॉड्यूल घोषणाओं का उपयोग कर रहे हैं, इस स्थिति में उन्हें नई समर्थित node_modules आधारित .d.ts फ़ाइलों के लिए परिभाषाएँ भी शामिल करनी चाहिए। इसके अलावा, कोई समस्या नहीं होनी चाहिए क्योंकि टीएस प्रकार केवल संरचनात्मक रूप से जांचे जाते हैं, इसलिए इससे कोई फर्क नहीं पड़ता कि वे एक अलग मॉड्यूल से आते हैं या जब तक संरचनाएं मेल खाती हैं तब तक अलग-अलग नाम होते हैं।

spion 19 मार्च 2016

धन्यवाद @spion , बस मान लिया कि यह फ़ाइल-आधारित था, ऐसा लगता है कि आप मुझे कुछ आत्म-पीड़ित दर्द से बचाने जा रहे हैं।

EricABC 20 मार्च 2016

एक चीज जो मदद कर सकती है वह है tsconfig.json में फाइलों की संपत्ति को ग्लोब्स स्वीकार करना ...

चर्चा में include संपत्ति है

unional 20 मार्च 2016

प्रश्न और टिप्पणियाँ:

dependencies को पूर्ण tsconfig.json पथ के लिए अनुमति देनी चाहिए क्योंकि tsc इसकी अनुमति देता है
जब files पहले से मौजूद है और ठीक है तो एक नया कीवर्ड ( dependencies ) क्यों पेश करें?
उदाहरण:

{
    "compilerOptions": {
        // ...
    },
    "files": [
        "../common/tsconfig.json", // <== takes the `files` part of the tsconfig.json
        "../common/tsconfig.util.json", // <==
        "core.ts",
        "sys.ts"
    ]
}

~~क्या होगा यदि निर्भरता tsconfig.json भी निर्दिष्ट करती है compilerOptions ?~~

आइए आगे चलते हैं/जंगली :-) और संभवतः (भविष्य में) compilerOptions , exclude ... को किसी अन्य tsconfig.json को संदर्भित करने की अनुमति दें:

// File app/tsconfig.json
{
    "compilerOptions": "../common/tsconfig.compilerOptions.json",
    "files": [
        "../common/tsconfig.json",
        "../common/tsconfig.util.json",
        "core.ts",
        "sys.ts"
    ],
    "exclude": "../common/exclude.json"
}

// File ../common/tsconfig.compilerOptions.json
{
    "compilerOptions": {
        "module": "commonjs",
        "noImplicitAny": true,
        "sourceMap": true
    }
}

// File ../common/exclude.json
{
    "exclude": [
        "node_modules",
        "wwwroot"
    ]
}

// File ../common/tsconfig.util.json
{
    "files": [
        "foo.ts",
        "bar.ts"
    ]
}

आपको तर्क मिला: files , compilerOptions , exclude ... अन्य tsconfig.json फाइलों को संदर्भित कर सकता है और यह केवल अन्य tsconfig से मेल खाने वाले कीवर्ड भाग को "ले" जाएगा .json फ़ाइल => आसान और मापनीय। यदि आप चाहें तो tsconfig.json को कई फाइलों में विभाजित कर सकते हैं और उनका पुन: उपयोग कर सकते हैं।

tkrotoff 4 मई 2016

👍5

आपकी चर्चा का हिस्सा पढ़ना, यह "भाषा सेवा"/गोटो परिभाषा चीज़ को सही करने के लिए सबसे अधिक प्रासंगिक है। जावास्क्रिप्ट डिबगर्स सोर्समैप्स का उपयोग करते हैं। अब, यदि tsc ने sourceMap डेटा न केवल .js में बल्कि .d.ts फ़ाइलों में भी उत्पन्न किया है ...

इसके अलावा मुझे वास्तव में tsconfig.json फ़ाइल के भीतर से बाल परियोजनाओं के निर्माण को ट्रिगर करने में अधिक लाभ नहीं दिखता है। यदि आपको इस मूल प्रकार की बिल्ड टाइम निर्भरता की आवश्यकता है तो एक साधारण शेल स्क्रिप्ट काम करेगी। यदि आपको बुद्धिमान वृद्धिशील भवन की आवश्यकता है, तो दूसरी ओर, प्रस्तावित दृष्टिकोण बहुत सरल लगता है। कई परिदृश्यों में tsc दूसरों के बीच सिर्फ एक निर्माण कदम के रूप में समाप्त होता है। tsconfig.json में tsc के लिए लेखन निर्भरता कितनी अजीब है लेकिन बाकी के लिए कोई अन्य फ़ाइल? दोबारा, टीएससी के साथ साधारण चीजों के लिए एकमात्र निर्माण चरण एक शेल स्क्रिप्ट करेगा।

वैसे भी, .d.ts फाइलों में .js फाइलों की तरह ही सोर्स मैपिंग जेनरेट करने के बारे में कैसे?

t-beckmann 20 अग॰ 2016

हम केवल नोड मॉड्यूल + एनपीएम लिंक का उपयोग करते हैं, केवल एक चीज जो काम नहीं करती है वह यह है कि मॉड्यूल समाधान: नोड ईएस 6 मॉड्यूल के साथ संगत नहीं है, जो इनलाइनिंग / ट्री-शेकिंग ऑप्टिमाइज़ेशन को सक्षम करता है (#11103 भी देखें)

wizzard0 24 सित॰ 2016

विषय से हटकर नहीं, लेकिन कुछ मायनों में, यह स्थानीय स्तर पर कई नोड पैकेज परियोजनाओं के साथ काम करने की चुनौतियों के समानांतर प्रतीत होता है। मुझे नहीं लगता कि यह "एनपीएम लिंक" का उपयोग करने जितना आसान है। उनके पास अलग-अलग बिल्ड स्क्रिप्ट हो सकती हैं, आपको उन सभी को सही क्रम में चलाने की आवश्यकता होगी, ऐसा क्रमिक रूप से करना कठिन है, वॉच मोड का उपयोग करना कठिन है, चीजों को डीबग करना कठिन है और स्रोत मानचित्रों को हल करना कठिन है। आपकी पसंद के संपादक के आधार पर, यह और भी चुनौतीपूर्ण हो सकता है।

आम तौर पर मैं बस छोड़ देता हूं, इसे एक विशाल परियोजना में डाल देता हूं, फिर स्थिर होने के बाद इसे अलग-अलग पैकेजों में विभाजित करता हूं, लेकिन यह केवल इसलिए मदद करता है क्योंकि चुनौती का सामना कम बार किया जा रहा है। मुझे पूरा अनुभव वास्तव में, वास्तव में कष्टप्रद लगता है। क्या मैं कुछ भूल रहा हूँ?

इसलिए, जो कुछ भी हो रहा है, मुझे उम्मीद है कि आखिरकार मेरे पास इस पूरे विकास अनुभव के लिए एक शानदार समाधान हो सकता है।

joelday 9 दिस॰ 2016

👍4

बस इस बात का जिक्र करते हुए कि यह हमारे दिन-प्रतिदिन के काम के लिए बहुत अच्छा होगा!

वेब विकास की प्रकृति के कारण, हमारे पास प्रत्येक प्रोजेक्ट के साथ कई ts प्रोजेक्ट हैं जिनमें एक ही js फ़ाइल ( --outFile ) में संकलित कई ts फ़ाइलें हैं। ये या तो ऐप जैसी परियोजनाएं हैं (वे एक विशिष्ट काम करते हैं या एक विशिष्ट सुविधा जोड़ते हैं) या lib जैसी परियोजनाएं (ऐप्स के लिए पुन: प्रयोज्य कोड)। अक्सर हम एक ही समय में इनमें से कई टीएस-प्रोजेक्ट्स पर काम करते हैं, जिससे ऐप्स पर विकास को सुविधाजनक बनाने के लिए पुस्तकालयों को बढ़ाया जाता है। लेकिन मुझे नहीं लगता कि मेरे किसी भी साथी डेवलपर्स के पास हमारे सभी टीएस-प्रोजेक्ट्स किसी भी समय अपने स्थानीय वातावरण पर हैं।

हमारे कार्यप्रवाह को बेहतर बनाने के लिए, हमारे वर्तमान विकल्प हैं

1 ts प्रोजेक्ट में सब कुछ फेंक दें
- हम .ts फ़ाइलों को सीधे संदर्भित कर सकते हैं, जो d.ts फ़ाइलों का उपयोग करने की तुलना में बहुत अच्छा है
- लेकिन हमें फाइलों के सेट को मैप और संयोजित करने के लिए एक बाहरी टूल की आवश्यकता होती है, क्योंकि हमें ऐप्स की मॉड्यूलरिटी बनाए रखते हुए इंटरवेब पर अनुरोधित जेएस फाइलों को सीमित करने की आवश्यकता होती है (जो फीचर- या पेज विशिष्ट हैं)।
- जैसा कि उल्लेख किया गया है, इन सभी टीएस-प्रोजेक्ट्स को हर समय हर किसी के लिए जरूरी नहीं है, इसलिए यह फाइल सिस्टम में बहुत अधिक ब्लोट जोड़ देगा। प्रोजेक्ट X पर काम करने वाले किसी व्यक्ति को प्रोजेक्ट A, B और D की आवश्यकता हो सकती है, लेकिन Y पर काम करने वाले को A और C की आवश्यकता हो सकती है।
परियोजनाओं को अलग रखें (हमारी वर्तमान स्थिति)
- हमें अन्य ts-प्रोजेक्ट्स से संकलित d.ts फ़ाइलों को संदर्भित करने की आवश्यकता है क्योंकि एक .ts फ़ाइल को सीधे आउटपुट में जोड़ देगा। अगर हम सीधे अपने स्रोत कोड में f12 कर सकते हैं तो यह बहुत तेज़ होगा।
- और हमें एक ही समय में इनमें से कई परियोजनाओं को संकलित करने के लिए टूल/स्क्रिप्ट जोड़ने की आवश्यकता है। वर्तमान में हम या तो कई टर्मिनलों से tsc -d -w कमांड शुरू करते हैं, या एक स्क्रिप्ट को फायर करते हैं जो सभी उपनिर्देशिकाओं के लिए करता है जहां एक tsconfig पाया जाता है।
- मैं समझता हूं कि अन्य उपकरण इसमें मदद कर सकते हैं (जैसे गल्प) या शायद हम tsconfigs में फ़ाइल ग्लोब के साथ कुछ पता लगा सकते हैं, हालांकि यह d.ts फ़ाइलों के पहले अंक में मदद नहीं करेगा।

हमारा प्रोजेक्ट इतना बड़ा नहीं है कि पुस्तकालयों के विकास को ऐप्स से सख्ती से अलग रखा जा सके, लेकिन इतना छोटा नहीं कि हम सब कुछ एक साथ फेंक सकें। हम पाते हैं कि टाइपस्क्रिप्ट के साथ अच्छे विकल्पों की कमी है।

अगर dependencies दोनों दुनिया का सबसे अच्छा विकल्प हो सकता है, तो यह आश्चर्यजनक होगा; की कार्यक्षमताएक निर्भरता की सभी ts फ़ाइलों को टैग करता है, लेकिन उस निर्भरता के अपने tsconfig के अनुसार आउटपुट संकलित करता है।

wardds 21 मार्च 2017

क्या इस विषय पर कोई अपडेट है। हमारे पास कई टाइपस्क्रिप्ट प्रोजेक्ट कैसे हो सकते हैं जो स्वतंत्र रूप से एक दूसरे को संकलित करते हैं? हम tsconfig.json में ऐसी निर्भरता का वर्णन कैसे कर सकते हैं?

llgcode 5 मई 2017

इसे अब भविष्य के खंड में "प्रोजेक्ट संदर्भों के लिए समर्थन" शीर्षक के साथ रोडमैप में शामिल किया गया है। इसलिए, मुझे लगता है कि एक .tsconfig फ़ाइल एक अन्य .tsconfig फ़ाइल को निर्भरता के रूप में लिंक करने में सक्षम होगी।

gulshan 5 मई 2017

❤3

क्या इस विषय पर कोई अपडेट है। हमारे पास कई टाइपस्क्रिप्ट प्रोजेक्ट कैसे हो सकते हैं जो स्वतंत्र रूप से एक दूसरे को संकलित करते हैं? हम tsconfig.json में ऐसी निर्भरता का वर्णन कैसे कर सकते हैं?

बिल्ड निर्भरता को आपके बिल्ड सिस्टम में एन्कोड किया जाना चाहिए। ऐसे मामलों को संभालने के लिए गल्प, ग्रंट, ब्रोकली, एमएसबिल्ड, बेसल, आदि जैसे बिल्ड सिस्टम बनाए गए हैं।
प्रकार की जानकारी के लिए, एक प्रोजेक्ट के आउटपुट में एक .d.ts शामिल होना चाहिए और इसे दूसरे को इनपुट के रूप में पास किया जाना चाहिए।

mhegazy 5 मई 2017

@mhegazy हमारी परियोजना इस तरह काम करती है। हमारे पास एक लर्न मोनोरेपो में कई पैकेज हैं, प्रत्येक पैकेज की package.json में अपनी निर्भरता है, और वही निर्भरता "types" संपत्ति में उनके tsconfig.json । प्रत्येक प्रोजेक्ट को --outFile साथ संकलित किया गया है (यह एक पुरानी परियोजना है जो अभी तक ES मॉड्यूल में नहीं गई है), और "typings" package.json बंडल .d.ts गए प्रमुख बिंदुओं

हम गल्प का उपयोग बंडलिंग/देखने के लिए करते हैं।

यह अधिकांश भाग के लिए काम करता है, लेकिन कुछ मुद्दे हैं:

#15488 और #15487 जैसे मुद्दों के कारण, संदर्भों के सही ढंग से काम करने के लिए हमारे पास एक स्पष्ट लिंक होना चाहिए।
गो-टू-डेफिनिशन आपको एक बंडल की गई .d.ts फ़ाइल में ले जाएगा। आदर्श रूप से यह आपको किसी अन्य प्रोजेक्ट में स्रोत तक ले जाएगा।
पूर्ण निर्माण करने का सबसे तेज़ तरीका lerna run build --sort (प्रभावी रूप से प्रत्येक निर्देशिका में tsc ) है, जिसमें अतिरिक्त ओवरहेड है क्योंकि यह प्रत्येक पैकेज के लिए एक टाइपस्क्रिप्ट कंपाइलर प्रक्रिया को जन्म देगा, बहुत बार दोहराए जाने वाले काम को निष्पादित करेगा। .

azz 6 मई 2017

👍6

मैं इस मुद्दे पर कड़ी नजर रख रहा हूं क्योंकि हम भी उसी स्थिति में हैं जिसका दूसरों ने वर्णन किया है।
एकाधिक "प्रोजेक्ट", प्रत्येक इसकी tsconfig.json फ़ाइल के साथ।

हमारे पास बिल्ड प्रक्रिया काम कर रही है जैसे @mhegazy ने बताया: प्रत्येक प्रोजेक्ट .d.ts फ़ाइल उत्सर्जित करता है और इसका उपयोग निर्भर परियोजनाओं के लिए इनपुट के रूप में किया जाता है।

वास्तविक समस्या आईडीई समर्थन है: संदर्भों की तलाश में, वे केवल एक tsconfig.json के दायरे में पाए जाते हैं। इससे भी बदतर, एक बदली हुई फ़ाइल के कैस्केडिंग प्रभाव पूरे प्रोजेक्ट में नहीं फैलते क्योंकि tsconfig.json दायरे से बाहर की फाइलों के आधार पर पुन: संकलित नहीं किया जाता है। यह हमारी परियोजनाओं के रखरखाव के लिए बहुत बुरा है और कभी-कभी बिल्ड त्रुटियों का कारण बनता है जो आईडीई में पकड़ी जा सकती थीं।

lorenzodallavecchia 26 मई 2017

👍6

It's happening

RyanCavanaugh 11 अक्तू॰ 2017

👍11 😄8 🎉3

हे भगवान

nycdotnet 11 अक्तू॰ 2017

एक अद्यतन परिदृश्य जिसमें मैं इसे प्राप्त करना पसंद करूंगा, इसमें रिएक्ट घटक शामिल हैं। हमारे पास एक घटक रेपो है जिसमें JSX मॉड्यूल (परमाणु, अणु और जीव) शामिल हैं जो हमारी कंपनी के सभी अनुप्रयोगों में UI घटकों को उपयुक्त बनाते हैं। इस घटक रेपो का उपयोग सभी फ्रंट-एंड डेवलपर्स द्वारा किया जाता है क्योंकि वे अपने व्यक्तिगत अनुप्रयोगों पर काम करते हैं। यह बहुत अच्छा होगा यदि मेरे पास टाइपस्क्रिप्ट भाषा सेवा का अनुभव हो जो मुझे अपने विशिष्ट-एप्लिकेशन के UI को संपादित करने और सामान्य UI घटक रेपो में "परिभाषा पर जाएं" की अनुमति देगा। आज हमें इन घटकों को अलग-अलग बंडल करना है और उन्हें कॉपी करना है। यह "अपना खुद का प्रोजेक्ट प्लंबिंग" समस्या है जिसे मैं निश्चित देखना पसंद करूंगा (जिसके लिए समाधान के तहत परियोजनाओं के साथ .NET दुनिया में एक बहुत अच्छी कहानी है)।

nycdotnet 11 अक्तू॰ 2017

परियोजना संदर्भ: टाइपस्क्रिप्ट के लिए अंतर्निहित मापनीयता

परिचय

टाइपस्क्रिप्ट ने सैकड़ों हजारों लाइनों की परियोजनाओं को बढ़ाया है, लेकिन अंतर्निहित व्यवहार के रूप में इस तरह के पैमाने का मूल रूप से समर्थन नहीं करता है। टीमों ने अलग-अलग प्रभावशीलता के वर्कअराउंड विकसित किए हैं और बड़ी परियोजनाओं का प्रतिनिधित्व करने का कोई मानकीकृत तरीका नहीं है। जबकि हमने समय के साथ टाइप-चेकर के प्रदर्शन में बहुत सुधार किया है, TS कितनी तेजी से उचित रूप से प्राप्त कर सकता है, इसके संदर्भ में अभी भी कठिन सीमाएँ हैं,
और 32-बिट एड्रेस स्पेस जैसी बाधाएं जो इंटरएक्टिव परिदृश्यों में भाषा सेवा को "असीम रूप से" स्केल करने से रोकती हैं।

सहज रूप से, JSX की एक लाइन को फ्रंट-एंड कंपोनेंट में बदलने से 500,000 LOC प्रोजेक्ट के संपूर्ण कोर बिजनेस लॉजिक कंपोनेंट को फिर से टाइप करने की आवश्यकता नहीं होनी चाहिए। परियोजना संदर्भों का लक्ष्य डेवलपर्स को अपने कोड को छोटे ब्लॉकों में विभाजित करने के लिए उपकरण देना है। एक समय में काम के छोटे हिस्से पर काम करने के लिए उपकरणों को सक्षम करके, हम प्रतिक्रियात्मकता में सुधार कर सकते हैं और मुख्य विकास लूप को मजबूत कर सकते हैं।

हम मानते हैं कि हमारे वर्तमान आर्किटेक्चर में प्रदर्शन या स्मृति खपत में भारी सुधार के मामले में बहुत कम "मुफ्त लंच" शेष हैं। इसके बजाय, यह विभाजन एक स्पष्ट व्यापार-बंद है जो कुछ अग्रिम कार्य की कीमत पर गति बढ़ाता है। डेवलपर्स को अपने सिस्टम के निर्भरता ग्राफ के बारे में तर्क करने में कुछ समय बिताना होगा, और कुछ इंटरैक्टिव फीचर्स (जैसे क्रॉस-प्रोजेक्ट नाम) अनुपलब्ध हो सकते हैं जब तक कि हम टूलिंग को और बढ़ा नहीं देते।

हम इस प्रणाली द्वारा लगाए गए प्रमुख बाधाओं की पहचान करेंगे और परियोजना आकार, निर्देशिका संरचना और निर्माण पैटर्न के लिए दिशानिर्देश स्थापित करेंगे।

परिदृश्यों

विचार करने के लिए तीन मुख्य परिदृश्य हैं।

सापेक्ष मॉड्यूल

कुछ परियोजनाएं बड़े पैमाने पर सापेक्ष आयात का उपयोग करती हैं। ये आयात स्पष्ट रूप से डिस्क पर किसी अन्य फ़ाइल का समाधान करते हैं। ../../core/utils/otherMod जैसे पथ ढूंढना आम होगा, हालांकि इन रेपो में चापलूसी निर्देशिका संरचनाएं आमतौर पर पसंद की जाती हैं।

उदाहरण

यहाँ खान अकादमी के पर्सियस प्रोजेक्ट का एक उदाहरण दिया गया है:

https://github.com/Khan/perseus/blob/master/src/components/graph.jsx से अनुकूलित

const Util = require("../util.js");
const GraphUtils = require("../util/graph-utils.js");
const {interactiveSizes} = require("../styles/constants.js");
const SvgImage = require("../components/svg-image.jsx");

टिप्पणियों

जबकि निर्देशिका संरचना एक परियोजना संरचना का तात्पर्य है, यह आवश्यक रूप से निश्चित नहीं है। ऊपर खान अकादमी के नमूने में, वसीयत यह अनुमान लगा सकती है कि util , styles , और components शायद उनका अपना प्रोजेक्ट होगा। लेकिन यह भी संभव है कि ये निर्देशिकाएं काफी छोटी हों और वास्तव में उन्हें एक निर्माण इकाई में समूहीकृत किया जाएगा।

मोनो-रेपो

एक मोनो-रेपो में कई मॉड्यूल होते हैं जो गैर-सापेक्ष पथों के माध्यम से आयात किए जाते हैं। उप-मॉड्यूल से आयात (जैसे import * as C from 'core/thing ) आम हो सकता है। आमतौर पर, लेकिन हमेशा नहीं, प्रत्येक रूट मॉड्यूल वास्तव में एनपीएम पर प्रकाशित होता है।

उदाहरण

https://github.com/angular/angular/blob/master/packages/forms/src/validators.ts से अनुकूलित

import {InjectionToken, ɵisObservable as isObservable, ɵisPromise as isPromise} from '@angular/core';
import {forkJoin} from 'rxjs/observable/forkJoin';
import {map} from 'rxjs/operator/map';
import {AbstractControl, FormControl} from './model';

टिप्पणियों

विभाजन की इकाई जरूरी नहीं कि मॉड्यूल नाम का प्रमुख भाग हो। rxjs , उदाहरण के लिए, वास्तव में इसके उप-भागों ( observable , operator ) को अलग से संकलित करता है, जैसा कि कोई भी स्कोप्ड पैकेज (जैसे @angular/core ) करता है।

आउटफाइल

टाइपस्क्रिप्ट अपनी इनपुट फ़ाइलों को एकल आउटपुट जावास्क्रिप्ट फ़ाइल में समाप्‍त कर सकता है। संदर्भ निर्देश, या tsconfig.json में फ़ाइल क्रम, परिणामी फ़ाइल के लिए एक नियतात्मक आउटपुट क्रम बनाएँ। यह शायद ही कभी नई परियोजनाओं के लिए उपयोग किया जाता है, लेकिन अभी भी पुराने कोडबेस (टाइपस्क्रिप्ट सहित) के बीच प्रचलित है।

उदाहरण

https://github.com/Microsoft/TypeScript/blob/master/src/compiler/tsc.ts

/// <reference path="program.ts"/>
/// <reference path="watch.ts"/>
/// <reference path="commandLineParser.ts"/>

https://github.com/Microsoft/TypeScript/blob/master/src/harness/unittests/customTransforms.ts

/// <reference path="..\..\compiler\emitter.ts" />
/// <reference path="..\harness.ts" />

टिप्पणियों

इस कॉन्फ़िगरेशन का उपयोग करने वाले कुछ समाधान प्रत्येक outFile को एक अलग script टैग (या समकक्ष) के माध्यम से लोड कर रहे होंगे, लेकिन अन्य (जैसे टाइपस्क्रिप्ट स्वयं) को पूर्व फ़ाइलों के संयोजन की आवश्यकता होती है क्योंकि वे मोनोलिथिक आउटपुट बना रहे हैं .

परियोजना संदर्भ: अलगाव की एक नई इकाई

वास्तविक परियोजनाओं के साथ बातचीत से कुछ महत्वपूर्ण अवलोकन:

टाइपस्क्रिप्ट आमतौर पर "तेज़" (< 5-10s) होता है जब कार्यान्वयन के 50,000 LOC (गैर-.d.ts) कोड के तहत परियोजनाओं की जाँच करता है
.d.ts फाइलें, विशेष रूप से skipLibCheck तहत, उनकी टाइपचेकिंग और मेमोरी लागत के मामले में लगभग "मुक्त" हैं
लगभग सभी सॉफ़्टवेयर को 50,000 LOC से छोटे घटकों में उप-विभाजित किया जा सकता है
लगभग सभी बड़ी परियोजनाएं पहले से ही निर्देशिका द्वारा अपनी फाइलों की कुछ संरचना को इस तरह से लागू करती हैं जो मध्यम आकार के उप-घटकों का उत्पादन करती हैं
अधिकांश संपादन लीफ-नोड या नियर-लीफ-नोड घटकों में होते हैं जिन्हें संपूर्ण समाधान की पुन: जांच या पुन: उत्सर्जन की आवश्यकता नहीं होती है

इन्हें एक साथ रखते हुए, यदि एक बार में कार्यान्वयन कोड के केवल एक 50,000 LOC खंड को टाइप करना संभव था, तो एक इंटरैक्टिव परिदृश्य में लगभग कोई "धीमी" बातचीत नहीं होगी, और हम लगभग कभी भी स्मृति से बाहर नहीं होंगे।

हम एक नई अवधारणा, एक परियोजना संदर्भ पेश करते हैं , जो दो टाइपस्क्रिप्ट संकलन इकाइयों के बीच एक नई तरह की निर्भरता की घोषणा करता है जहां आश्रित इकाई के कार्यान्वयन कोड की जाँच नहीं की जाती है; इसके बजाय हम बस इसके .d.ts आउटपुट को एक नियतात्मक स्थान से लोड करते हैं।

वाक्य - विन्यास

एक नया references विकल्प (कार्यसूची:! Bikeshed) में जोड़ा जाता है tsconfig.json :

{
  "extends": "../tsproject.json",
  "compilerOptions": {
    "outDir": "../bin",
    "references": [
      { "path": "../otherProject" }
    ]
  }
}

references सरणी इस परियोजना से संदर्भ के लिए अन्य परियोजनाओं का एक सेट निर्दिष्ट करती है।
प्रत्येक references ऑब्जेक्ट का path एक tsconfig.json फ़ाइल या tsconfig.json फ़ाइल वाले फ़ोल्डर की ओर इशारा करता है।
इस वस्तु में अन्य विकल्प जोड़े जा सकते हैं क्योंकि हम उनकी आवश्यकताओं की खोज करते हैं।

अर्थ विज्ञान

परियोजना संदर्भ निम्नलिखित व्यवहार को बदलते हैं:

जब मॉड्यूल रिज़ॉल्यूशन किसी प्रोजेक्ट के rootDir की उपनिर्देशिका में .ts फ़ाइल का समाधान करेगा, तो इसके बजाय यह उस प्रोजेक्ट के outDir .d.ts फ़ाइल का समाधान करता है
- यदि यह समाधान विफल हो जाता है, तो हम शायद इसका पता लगा सकते हैं और एक बेहतर त्रुटि जारी कर सकते हैं, उदाहरण के लिए Referenced project "../otherProject" is not built बजाय एक साधारण "फ़ाइल नहीं मिली"
और कुछ नहीं (TODO: अब तक?)

संदर्भित परियोजनाओं के प्रदर्शन के लिए प्रतिबंध

बिल्ड प्रदर्शन को सार्थक रूप से बेहतर बनाने के लिए, हमें टाइपस्क्रिप्ट के व्यवहार को प्रतिबंधित करना सुनिश्चित करना होगा जब वह प्रोजेक्ट संदर्भ देखता है।

विशेष रूप से, निम्नलिखित बातें सत्य होनी चाहिए:

किसी संदर्भित प्रोजेक्ट की इनपुट .ts फ़ाइलों को कभी भी पढ़ें या पार्स
किसी संदर्भित प्रोजेक्ट के केवल tsconfig.json को डिस्क से पढ़ा जाना चाहिए
अप-टू-डेट जाँच के लिए उपरोक्त बाधाओं का उल्लंघन करने की आवश्यकता नहीं होनी चाहिए

इन वादों को पूरा करने के लिए, हमें आपके द्वारा संदर्भित परियोजनाओं पर कुछ प्रतिबंध लगाने की आवश्यकता है।

declaration स्वचालित रूप से true सेट हो जाता है। इस सेटिंग को ओवरराइड करने का प्रयास करना एक त्रुटि है
rootDir डिफ़ॉल्ट रूप से "." ( tsconfig.json फ़ाइल वाली निर्देशिका), इनपुट फ़ाइलों के सेट से अनुमानित होने के बजाय
यदि files सरणी प्रदान की जाती है, तो उसे सभी इनपुट फ़ाइलों के नाम प्रदान करने होंगे
- अपवाद: प्रकार के संदर्भों के भाग के रूप में शामिल फ़ाइलें (उदाहरण के लिए node_modules/@types ) निर्दिष्ट करने की आवश्यकता नहीं है
संदर्भित किसी भी परियोजना में स्वयं references सरणी होनी चाहिए (जो खाली हो सकती है)।

क्यों `"declaration": true` ?

प्रोजेक्ट संदर्भ अपनी कार्यान्वयन फ़ाइलों (.ts) के स्थान पर घोषणा फ़ाइलों (.d.ts) का उपयोग करके निर्माण गति में सुधार करते हैं।
तो, स्वाभाविक रूप से, किसी भी संदर्भित परियोजना में declaration सेटिंग चालू होनी चाहिए।
यह "project": true द्वारा निहित है

`rootDir` क्यों बदलें?

rootDir नियंत्रित करता है कि इनपुट फ़ाइलें आउटपुट फ़ाइल नामों के साथ कैसे मैप करती हैं। टाइपस्क्रिप्ट का डिफ़ॉल्ट व्यवहार इनपुट फ़ाइलों के संपूर्ण ग्राफ़ की सामान्य स्रोत निर्देशिका की गणना करना है। उदाहरण के लिए, इनपुट फ़ाइलों का सेट ["src/a.ts", "src/b.ts"] आउटपुट फ़ाइलों का उत्पादन करेगा ["a.js", "b.js"] ,
लेकिन इनपुट फाइलों का सेट ["src/a.ts", "b.ts"] आउटपुट फाइलों का उत्पादन करेगा ["src/a.js", "b.js"] ।

इनपुट फ़ाइलों के सेट की गणना करने के लिए प्रत्येक रूट फ़ाइल और उसके सभी संदर्भों को पुनरावर्ती रूप से पार्स करने की आवश्यकता होती है,
जो एक बड़े प्रोजेक्ट में महंगा होता है। लेकिन हम मौजूदा परियोजनाओं को खराब तरीके से तोड़े बिना आज इस व्यवहार को नहीं बदल सकते हैं, इसलिए यह परिवर्तन केवल तब होता है जब references सरणी प्रदान की जाती है।

कोई परिपत्र नहीं

स्वाभाविक रूप से, परियोजनाएं किसी भी परिपत्र के साथ एक ग्राफ नहीं बना सकती हैं। (TODO: ऑर्केस्ट्रेशन दुःस्वप्न बनाने के अलावा, यह वास्तव में किन समस्याओं का कारण बनता है?) यदि ऐसा होता है, तो आपको एक त्रुटि संदेश दिखाई देगा जो कि बनने वाले वृत्ताकार पथ को इंगित करता है:

TS6187: Project references may not form a circular graph. Cycle detected:
    C:/github/project-references-demo/core/tsconfig.json ->
    C:/github/project-references-demo/zoo/tsconfig.json ->
    C:/github/project-references-demo/animals/tsconfig.json ->
    C:/github/project-references-demo/core/tsconfig.json

`tsbuild`

यह प्रस्ताव जानबूझकर अस्पष्ट है कि इसका उपयोग "वास्तविक" निर्माण प्रणाली में कैसे किया जाएगा। .ts कोड को संकलित करने के लिए tsc के अलावा कुछ और पेश किए बिना बहुत कम परियोजनाएं 50,000 LOC "तेज" सीमा को पार करती हैं।

"आप foo निर्माण नहीं कर सकते क्योंकि bar अभी तक नहीं बनाया गया है" का उपयोगकर्ता परिदृश्य एक स्पष्ट "गो फ़ेच दैट" एक प्रकार का कार्य है जिसका कंप्यूटर को ध्यान रखना चाहिए, बल्कि डेवलपर्स पर मानसिक बोझ की तुलना में।

हम उम्मीद करते हैं कि gulp , webpack , आदि, (या उनके संबंधित TS प्लगइन्स) जैसे उपकरण परियोजना संदर्भों की समझ में निर्माण करेंगे और अप-टू-डेट जाँच सहित इन बिल्ड निर्भरताओं को सही ढंग से संभालेंगे।

यह सुनिश्चित करने के लिए कि यह संभव है , हम टाइपस्क्रिप्ट बिल्ड ऑर्केस्ट्रेशन टूल के लिए एक संदर्भ कार्यान्वयन प्रदान करेंगे जो निम्नलिखित व्यवहारों को प्रदर्शित करता है:

तेज़ अप-टू-डेट जाँच
प्रोजेक्ट ग्राफ़ ऑर्डरिंग
समानांतर निर्माण
(TODO: अन्य?)

इस उपकरण को केवल सार्वजनिक एपीआई का उपयोग करना चाहिए, और उपकरण लेखकों को परियोजना संदर्भों को लागू करने के सही तरीके को समझने में मदद करने के लिए अच्छी तरह से प्रलेखित होना चाहिए।

करने के लिए

इस प्रस्ताव को पूरी तरह से पूरा करने के लिए भरने के लिए अनुभाग

आप किसी मौजूदा प्रोजेक्ट का संक्रमण कैसे करेंगे
- मूल रूप से केवल tsconfig.json फ़ाइलें छोड़ें और फिर बिल्ड त्रुटियों को ठीक करने के लिए आवश्यक संदर्भ जोड़ें
baseUrl पर प्रभाव
- कार्यान्वयन को कठिन बनाता है लेकिन प्रभावी रूप से कोई अंतिम-उपयोगकर्ता प्रभाव नहीं बनाता है
नेस्टिंग परियोजनाओं की संक्षिप्त चर्चा (टीएल; डीआर इसे अनुमति देने की आवश्यकता है)
उपभोक्ताओं को तोड़े बिना छोटी परियोजनाओं में "बहुत बड़ी" हो गई परियोजनाओं को उप-विभाजित करने का रूपरेखा परिदृश्य
लर्ना परिदृश्य का पता लगाएं
- उपलब्ध डेटा बिंदु (एन = 1) का कहना है कि उन्हें इसकी आवश्यकता नहीं होगी क्योंकि उनका निर्माण पहले से ही इस तरह से प्रभावी ढंग से संरचित है
- लोग इसे कैसे करते हैं, इसे बेहतर ढंग से समझने के लिए और उदाहरण या प्रति-उदाहरण खोजें
क्या हमें उन लोगों के लिए dtsEmitOnly सेटिंग की आवश्यकता है जो अपने जेएस को वेबपैक/बेबेल/रोलअप के माध्यम से पाइप कर रहे हैं?
- शायद references + noEmit इसका अर्थ है

RyanCavanaugh 2 नव॰ 2017

👍19

शानदार!

लर्ना परिदृश्य का पता लगाएं
उपलब्ध डेटा बिंदु (एन = 1) का कहना है कि उन्हें इसकी आवश्यकता नहीं होगी क्योंकि उनका निर्माण पहले से ही इस तरह से प्रभावी ढंग से संरचित है

क्या "यह" प्रस्ताव या संदर्भ निर्माण कार्यान्वयन को संदर्भित करता है? जबकि आप निर्माण करने के लिए लर्न का उपयोग कर सकते हैं (मेरी टीम करती है), यह बहुत ही कम है और यदि टीएस (या इस प्रस्ताव से निर्मित उपकरण) स्वयं का ख्याल रखता है तो यह अधिक कुशल होगा।

azz 2 नव॰ 2017

TODO अनुभाग संपूर्ण प्रस्ताव के लिए TODO है

RyanCavanaugh 2 नव॰ 2017

अच्छा!

संदर्भित की गई किसी भी परियोजना में स्वयं एक संदर्भ सरणी होनी चाहिए (जो खाली हो सकती है)।

क्या ये वाकई जरूरी है? क्या यह पर्याप्त नहीं होगा यदि ऐसे पैकेज में .d.ts फाइलें हों?
(उस स्थिति में, tsconfig.json होने के लिए भी यह आवश्यक नहीं हो सकता है?)

मेरा उपयोग-मामला: एक (जैसे तृतीय-पक्ष) प्रोजेक्ट पर विचार करें जो outDir उपयोग नहीं करता है, इसलिए .ts , .js और .d.ts बगल में होगा एक दूसरे को, और टीएस वर्तमान में संकलित करने के लिए कोशिश करेंगे .ts उपयोग करने के बजाय .d.ts ।

मेरे लिए outDir का उपयोग न करने का कारण import "package/subthing" -स्टाइल आयात को अधिक आसानी से अनुमति देना है, जो अन्यथा import "package/dist/subthing" साथ outDir: "dist" ।
और एनपीएम पैकेज, या इसके स्रोत भंडार का सीधे उपयोग करने में सक्षम होने के लिए (उदाहरण के लिए npm link )।

(यह उपयोगी होगा यदि package.json में एक निर्देशिका निर्दिष्ट करने की अनुमति है main , लेकिन अफसोस...)

poelstra 2 नव॰ 2017

क्या हमें उन लोगों के लिए dtsEmitOnly सेटिंग की आवश्यकता है जो अपने JS को वेबपैक/बेबेल/रोलअप के माध्यम से पाइप कर रहे हैं?

बिल्कुल! यह इस समय एक बड़ा लापता टुकड़ा है। वर्तमान में आप outFile का उपयोग करते समय एक एकल d.ts फ़ाइल प्राप्त कर सकते हैं, लेकिन जब आप मॉड्यूल पर स्विच करते हैं और एक बंडलर का उपयोग करते हैं, तो आप इसे खो देते हैं। एक मॉड्यूल के प्रवेश बिंदु ( export as namespace MyLib ) के लिए एक एकल d.ts फ़ाइल को उत्सर्जित करने में सक्षम होना आश्चर्यजनक होगा। मुझे पता है कि बाहरी उपकरण ऐसा कर सकते हैं लेकिन यह वास्तव में बहुत अच्छा होगा यदि इसे एमिटर और भाषा सेवाओं में एकीकृत किया जाए।

azz 2 नव॰ 2017

क्या ये वाकई जरूरी है? क्या यह पर्याप्त नहीं होगा यदि ऐसे पैकेज में .d.ts फाइलें हों?

हमें लक्ष्य tsconfig में कुछ चाहिए जो हमें बताता है कि आउटपुट फ़ाइलों के होने की उम्मीद कहाँ है। इस प्रस्ताव के पिछले संस्करण में "आपको एक स्पष्ट rootDir निर्दिष्ट करना होगा" जो कि काफी बोझिल था (आपको प्रत्येक tsconfig में "rootDir": "." लिखना था)। चूंकि हम इस दुनिया में विभिन्न प्रकार के व्यवहारों को फ़्लिप करना चाहते हैं, इसलिए यह कहने के लिए और अधिक समझ में आता है कि यदि आपके पास संदर्भ सरणी है तो आपको "प्रोजेक्ट" व्यवहार मिलता है और यह वह चीज है जिसे बंद कर दिया गया है, बजाय एक गुच्छा निर्दिष्ट करने के झंडे आपको स्पष्ट रूप से बताना होगा।

RyanCavanaugh 2 नव॰ 2017

यह प्रस्ताव इस बात से निकटता से मेल खाएगा कि हमने अपनी टाइपस्क्रिप्ट परियोजनाओं को पहले से कैसे संरचित किया है। हमने छोटी इकाइयों में उप-विभाजित किया है कि प्रत्येक में tsconfig.json है और गल्प के माध्यम से स्वतंत्र रूप से निर्मित होते हैं। डी.टीएस फाइलों को संदर्भित करके परियोजनाएं एक दूसरे को संदर्भित करती हैं।

एक आदर्श दुनिया में, संदर्भित परियोजना को पूर्व-निर्मित करने की आवश्यकता नहीं होगी। अर्थात। टाइपस्क्रिप्ट संदर्भित प्रोजेक्ट का "बिल्ड" करता है और भाषा सेवा में मेमोरी में "d.ts" के बराबर रखता है। यह "स्रोत" परियोजना में किए गए परिवर्तनों को पुनर्निर्माण की आवश्यकता के बिना "आश्रित" परियोजना में दिखाने की अनुमति देगा।

michaelaird 2 नव॰ 2017

👍3

हमें लक्ष्य tsconfig में कुछ चाहिए जो हमें बताता है कि आउटपुट फ़ाइलों के होने की उम्मीद कहाँ है।

यह केवल तभी सच होता है जब outDir का उपयोग किया जाता है, है ना?

जैसे: अगर मेरे पास tsconfig है कि:

outDir उपयोग नहीं करता है (लेकिन निश्चित रूप से declaration: true ), तो हमें rootDir आवश्यकता नहीं है, न ही references
करता है outDir , तो आपको सेट करने के लिए references और/या rootDir (और declaration: true ) की आवश्यकता होगी

पूछने का कारण यह है कि मैं किसी भी टीएस पैकेज के लिए 'प्रोजेक्ट मोड' को केवल संदर्भित करके सक्षम कर सकता हूं, यानी यह मेरे नियंत्रण में है।

उस स्थिति में, यह भी अच्छा होगा यदि यह .d.ts फ़ाइल मिलते ही काम करता है जिसे वह ढूंढ रहा है (यानी कोई .ts फ़ाइलें या tsconfig फ़ाइलें नहीं होने पर शिकायत नहीं करेगा)। क्योंकि यह आवश्यक होने पर इसके स्रोत संस्करण द्वारा एनपीएम संस्करण (जिसमें केवल .d.ts फाइलें हो सकती हैं) को 'प्रतिस्थापित' करने का एक और मामला सक्षम करेगा।

उदाहरण के लिए, NPM पैकेज MyApp और SomeLib पर विचार करें।
SomeLib में tsconfig: declaration: true ।

जैसे:

package.json
tsconfig.json
index.ts
sub.ts

संकलित, यह बन जाता है:

package.json
tsconfig.json
index.ts
index.d.ts
index.js
sub.ts
sub.d.ts
sub.js

यह संरचना सक्षम बनाती है उदा

// somewhere in MyApp
import something from "SomeLib/sub";

प्रकाशित एनपीएम पैकेज में, मुझे वर्तमान में हमेशा .ts फाइलों को हटाना पड़ता है, अन्यथा टीएस द्वारा सभी स्रोतों को फिर से संकलित किया जाएगा यदि MyApp SomeLib का उपयोग करता है:

तो, एनपीएम पर, यह बन जाता है:

package.json
index.d.ts
index.js
sub.d.ts
sub.js

अब, अगर मैं MyApp के tsconfig में references: ["SomeLib"] डालता हूं, तो यह अच्छा होगा यदि यह NPM संस्करण और SomeLib के स्रोत संस्करण दोनों के लिए 'जैसा है' काम करता है , यानी यह शिकायत नहीं करेगा जैसे tsconfig गुम होना, जब तक यह सही जगह पर sub.d.ts पाता है।

संबंधित, लेकिन अलग प्रश्न:

मुझे अब एहसास हुआ, कि यदि SomeLib के लेखक अपने tsconfig में references डालते हैं, तो यह भविष्य में .ts फ़ाइलों के साथ NPM पैकेज प्रकाशित करने की अनुमति देगा। लेकिन फिर, मुझे लगता है कि टीएस अभी भी इन्हें हमेशा पुन: संकलित करेगा जब कोई आश्रित पैकेज स्पष्ट रूप से references: ["SomeLib"] को उनके tsconfig में नहीं डालता है।

या यह भी इरादा है कि MyLib में references स्वचालित रूप से एक 'प्रोजेक्ट सीमा' भी पेश करेगा जब इसे केवल import 'इन करना होगा (यानी references इसे नहीं करना)?

आईआईआरसी, प्रारंभिक विचारों में से एक यह था कि यदि एक मॉड्यूल उदाहरण के लिए node_modules माध्यम से स्थित था, तो .d.ts फाइलों को .ts फाइलों पर प्राथमिकता दी जाएगी, लेकिन बाद में इसे वापस बदल दिया गया था , क्योंकि अनुमानी (" node_modules माध्यम से") सामान्य रूप से बहुत समस्याग्रस्त था। ऐसा हो सकता है कि एक स्पष्ट 'प्रोजेक्ट सीमा' होने से यह हल हो जाएगा (उदाहरण के लिए projectRoot: true के बजाय या इसके अलावा references )?

poelstra 3 नव॰ 2017

👍2

लर्न मामले के लिए, मैं एक आसान समाधान की उम्मीद कर रहा था।

अलग-अलग पैकेज निर्देशिकाओं में, संकुल को मोनोरेपो संरचना के बारे में कुछ भी नहीं पता होना चाहिए। व्यक्तिगत tsconfig json फ़ाइलों में कोई संदर्भ नहीं होना चाहिए।
- यह आपको अलग-अलग पैकेजों को अलग-अलग रिपॉजिटरी में विभाजित करने की अनुमति देता है और बस मुख्य रेपो टूलिंग उन्हें क्लोन करता है जैसे ProseMirror: https://github.com/ProseMirror/prosemirror
रूट "वर्कस्पेस" रेपो में (जिसमें सभी कोड हो सकते हैं, लेकिन अन्य रेपो को भी क्लोन कर सकते हैं), इसके tsconfig.json में संदर्भ हैं
- यह सिर्फ इसलिए किया जाता है ताकि टूलिंग .d.ts फाइलों में जाने के बजाय स्रोत के सभी तरह के संदर्भों को पहचान सके और उनका पालन कर सके।

मेरी पूरी चिंता यह है कि एक बार जब आप अलग-अलग प्रोजेक्ट कॉन्फ़िगरेशन फ़ाइलों के सापेक्ष अवरोही "../xx" पथ का उपयोग करके संदर्भ जोड़ते हैं, तो वे अब स्टैंड-अलोन मॉड्यूल के रूप में उपयोग करने योग्य

एक "कार्यक्षेत्र" tsconfig.json की नई अवधारणा को जोड़ने से यह समस्या हल हो जाती है। इस तरह यदि आप व्यक्तिगत पैकेज को "गिट क्लोन" कहते हैं, तो इसकी निर्भरता को सामान्य तरीके से स्थापित करना (जैसे npm या यार्न का उपयोग करना) आपको इस पर अलग से काम करने देना चाहिए, क्योंकि संकलित निर्भरता उनकी परिभाषा फाइलों में लाएगी। यदि आप पूरे कार्यक्षेत्र को क्लोन करते हैं और सभी पैकेजों को लाने के लिए कमांड चलाते हैं, तो कार्यक्षेत्र कॉन्फ़िगरेशन आपको सभी स्रोतों के माध्यम से नेविगेट करने देगा।

spion 4 नव॰ 2017

👍6

ध्यान दें कि एक कार्यक्षेत्र tsconfig.json भी यार्न के कार्यक्षेत्र के साथ पूरी तरह से संरेखित होता है package.json https://yarnpkg.com/lang/en/docs/workspaces/

spion 4 नव॰ 2017

मैंने यहाँ अवधारणा का एक छोटा सा प्रमाण दिया है

https://github.com/spion/typescript-workspace-plugin

बस अपने सभी tsconfig.json व्यक्तिगत रिपोज की फाइलों में प्लगइन जोड़ें

{
  "plugins": [{"name": "typescript-workspace-plugin"}]
}

फिर ऊपरी स्तर package.json पर यार्न की "कार्यस्थान" प्रविष्टि के साथ, "कार्यस्थान-स्रोत" प्रविष्टि जोड़ें:

{
  "workspaces": ["packages/*"],
  "workspace-sources": {
    "*": ["packages/*/src"]
  }
}

फ़ील्ड tsconfig.json में "पथ" फ़ील्ड की तरह काम करता है, लेकिन यह केवल व्यक्तिगत परियोजनाओं की भाषा सेवा को प्रभावित करता है, उन्हें पैकेज स्रोतों की ओर इशारा करता है। उचित "परिभाषा / प्रकार पर जाएं" कार्यक्षमता और समान को पुनर्स्थापित करता है।

spion 5 नव॰ 2017

👍4

यह केवल तभी सच है जब outDir का उपयोग किया जाता है, है ना?

सही। हमने अनुमान लगाया था कि बड़ी परियोजना वाले लगभग सभी लोग outDir का उपयोग कर रहे हैं। मुझे उन परियोजनाओं के बारे में सुनने में दिलचस्पी होगी जो नहीं हैं

अब, अगर मैं MyApp के tsconfig में संदर्भ: ["SomeLib"] डालता हूं, तो यह अच्छा होगा यदि यह NPM संस्करण और SomeLib के स्रोत संस्करण दोनों के लिए 'जैसा है' काम करता है

बड़े प्रशंसक, मुझे यह विचार बहुत पसंद है। मुझे यह सोचने की ज़रूरत है कि क्या यह वास्तव में आवश्यक है या नहीं।

यहां एक चेतावनी यह है कि मुझे लगता है कि पैकेज लेखकों को या तो ए) दोनों .ts और tsconfig फ़ाइलों को एक साथ प्रकाशित करने की आवश्यकता है जहां टीएस उन्हें ढूंढता है, या बी) न तो प्रकाशित करें और केवल .d.ts फाइलें पहुंच योग्य हों। (ए) मामले में हम परियोजना संदर्भों का पुनरावर्ती रूप से पालन करेंगे और सही बात होगी और (बी) में हम गलत जगहों पर नहीं जाएंगे।

या इरादा यह भी है कि MyLib में संदर्भ स्वचालित रूप से इसे आयात करते समय 'प्रोजेक्ट सीमा' भी पेश करेंगे (यानी इसे संदर्भ नहीं दे रहे हैं)?

@mhegazy के साथ बात की और हमें लगता है कि प्रोजेक्ट संदर्भ व्यवहार के लिए वास्तव में एक सरल मॉडल है: references सरणी वाला कोई भी प्रोजेक्ट प्रोजेक्ट फ़ोल्डर के बाहर .ts फ़ाइल को कभी भी "देखता" exclude d निर्देशिकाओं के अंतर्गत। यह परिवर्तन अकेले लर्न परिदृश्य को काम करता है ("कार्य" जिसका अर्थ है "मॉड्यूल संदर्भ हमेशा .d.ts के लिए हल होते हैं") बॉक्स से बाहर, साथ ही साथ अन्य।

मुझे "कार्यक्षेत्र" मॉडल को और अधिक देखने की आवश्यकता है।

RyanCavanaugh 8 नव॰ 2017

यह केवल तभी सच है जब outDir का उपयोग किया जाता है, है ना?

सही। हमने अनुमान लगाया था कि बड़ी परियोजना वाले लगभग सभी लोग आउटडियर का उपयोग कर रहे हैं। मुझे उन परियोजनाओं के बारे में सुनने में दिलचस्पी होगी जो नहीं हैं

हमारे पास विजुअल स्टूडियो समाधान में 67 टीएस परियोजनाएं हैं जो बिना outdir संकलित हैं और आउटपुट निर्देशिका संरचना (और बदसूरत और अन्य पोस्टप्रोसेसिंग) बनाने के लिए पोस्टबिल्ड ग्रंटटास्क हैं।

अधिकांश परियोजनाओं में ऐसा tsconfig.json होता है

 "include": [
    "../baseProj/Lib/jquery.d.ts",
    "../baseProj/baseProj.d.ts"
  ]

HolgerJeromin 8 नव॰ 2017

मुझे संदर्भ प्रस्ताव के माध्यम से पढ़ने में कुछ समय लगा, और सही - AFAICT lerna और यार्न कार्यक्षेत्र उपयोगकर्ताओं को यहां प्रस्तावित किसी भी कार्यक्षेत्र की कार्यक्षमता की आवश्यकता नहीं है:

हमारे पास पहले से ही package.json पर आधारित एक निर्भरता ग्राफ है, इसलिए हम उस क्रम को जानते हैं जिसमें बिल्ड को चलाना है। वास्तव में, लर्न के पास एक सामान्य रन कमांड है जो इसे क्रम में चला सकता है, और एक उपकरण लिखना मुश्किल नहीं है जो लागू होने पर समानता भी जोड़ता है। skipLibCheck को प्रदर्शन प्रभाव को नगण्य बनाना चाहिए, लेकिन मैंने इसकी जाँच नहीं की है।
Lerna और Yarn पहले से ही उपयुक्त node_modules स्थान में अन्य मॉड्यूल के लिए सिम्लिंक बनाते हैं। परिणामस्वरूप, सभी आश्रित दूसरे मॉड्यूल के package.json का अनुसरण करने में सक्षम होते हैं, प्रकार/टाइपिंग फ़ील्ड को पढ़ते हैं और संदर्भित मॉड्यूल.d.ts प्रकार परिभाषा फ़ाइल ढूंढते हैं।

हमारे पास जो नहीं है, और जो प्लगइन मैंने लिखा है, वह एक ही समय में सभी स्रोतों को लोड करने का एक तरीका है। जब मुझे एक ही समय में दो या दो से अधिक मॉड्यूल में परिवर्तन करने की आवश्यकता होती है, तो मैं नहीं चाहता कि मुझे .d.ts फ़ाइल में भेजने के लिए "परिभाषा पर जाएं" और "टाइप परिभाषा पर जाएं"। मैं चाहता हूं कि यह मुझे मूल स्रोत कोड स्थान पर भेजे, ताकि शायद मैं इसे संपादित कर सकूं। अन्यथा, मैं केवल व्यक्तिगत परियोजना निर्देशिका को लोड करूंगा और लर्न/यार्न द्वारा बनाए गए नोड_मॉड्यूल्स सिम्लिंक बस काम करेंगे।

spion 8 नव॰ 2017

👍3

हमारे लिए वही। लर्न के बजाय, हम अपने निर्भरता ग्राफ की गणना करने के लिए रश का उपयोग करते हैं, लेकिन प्रभाव समान है। जब हम प्रोजेक्ट बनाते हैं, तो tsc कई कार्यों में से एक है जिसे चलाने की आवश्यकता होती है। हमारे कंपाइलर विकल्पों की गणना एक बड़े बिल्ड सिस्टम द्वारा की जाती है, और हम एक ऐसे मॉडल की ओर बढ़ रहे हैं जहाँ tsconfig.json एक इनपुट फ़ाइल नहीं है, बल्कि एक उत्पन्न आउटपुट है (मुख्य रूप से VS कोड के लाभ के लिए)।

हमारे पास जो नहीं है, और जो प्लगइन मैंने लिखा है, वह एक ही समय में सभी स्रोतों को लोड करने का एक तरीका है। जब मुझे एक ही समय में दो या दो से अधिक मॉड्यूल में परिवर्तन करने की आवश्यकता होती है, तो मैं नहीं चाहता कि मुझे .d.ts फ़ाइल में भेजने के लिए "परिभाषा पर जाएं" और "टाइप परिभाषा पर जाएं"। मैं चाहता हूं कि यह मुझे मूल स्रोत कोड स्थान पर भेजे, ताकि शायद मैं इसे संपादित कर सकूं।

+1 यह कमाल होगा।

अगर हम बेहतर बहु-परियोजना समर्थन के बारे में सपना देख रहे हैं, तो मेरा पहला अनुरोध एक कंपाइलर सेवा होगा, कुछ ऐसा जैसे वीएस कोड इंटेलिसेन्स कैसे काम करता है। यदि रश कंपाइलर इंजन को 100 बार स्पिन किए बिना tsc 100 बार आह्वान कर सकता है तो हमारा निर्माण काफी तेज होगा। कंपाइलर हमारे सबसे महंगे बिल्ड स्टेप्स में से एक है। एक मोनोरेपो में, निर्माण का समय वास्तव में महत्वपूर्ण होता है।

@iclanton @nickpape-msft @qz2017

octogonz 10 नव॰ 2017

जी बोलिये!

SalvatorePreviti 10 नव॰ 2017

मुझे लगता है कि परियोजना प्रणाली के सबसे उपयोगी परिणामों में से एक होगा यदि
'गो टू डेफिनिशन' d.ts फाइल के बजाय सोर्स फाइल में गया और
प्रोजेक्ट रेफरेंस ट्री के माध्यम से खोजे गए 'सभी संदर्भ खोजें'।

संभवतः यह 'वैश्विक नाम बदलें' प्रकार के रिफैक्टरिंग को भी अनलॉक करेगा।

गुरु, 9 नवंबर, 2017 को रात 9:30 बजे सल्वाटोर प्रीविटी नोटिफिकेशन @github.com
लिखा था:

जी बोलिये!
-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/Microsoft/TypeScript/issues/3469#issuecomment-343356868 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AANX6d19Zz7TCd_GsP7Kzb-9XJAisG6Hks5s07VXgaJpZM4E-oPT
.

michaelaird 10 नव॰ 2017

👍6

@mhegazy के साथ बात की और हमें लगता है कि प्रोजेक्ट संदर्भ व्यवहार के लिए वास्तव में एक सरल मॉडल है: संदर्भ सरणी वाला कोई भी प्रोजेक्ट प्रोजेक्ट फ़ोल्डर के बाहर .ts फ़ाइल को कभी भी "देखता" नहीं है - इसमें बहिष्कृत निर्देशिकाओं के तहत फ़ाइलें शामिल हैं।

अच्छा, और उस स्थिति में, किसी को कोई विशिष्ट संदर्भ क्यों निर्दिष्ट करना होगा?
ऐसा प्रतीत होता है कि एक ध्वज होना पर्याप्त होगा (जैसे projectRoot: true )।
उदाहरण के लिए, तब references: ["foo"] और केवल references: [] बीच क्या अंतर होगा?
क्योंकि अगर मैं import "foo" या import "bar" , तो दोनों किसी भी .ts फाइलों को अनदेखा कर देंगे।

तो, उस स्थिति में, प्रस्ताव बन जाता है:

इसे देखते हुए tsconfig.json ( projectRoot पर TODO बाइकशेड):

{
  "extends": "../tsproject.json",
  "compilerOptions": {
    "projectRoot": true
   }
}

जब tsc तब प्रोजेक्ट फ़ोल्डर के बाहर कुछ हल करने की आवश्यकता होती है (बहिष्कृत निर्देशिकाओं के तहत फ़ाइलों सहित), यह केवल .d.ts फ़ाइलों को देखेगा (वैकल्पिक रूप से, यह केवल _prefer_ .d.ts फ़ाइलें, और tsconfig और/या .ts यदि यह केवल यही देखता है)।

यह संकलन के दौरान तेजी से और सरल संकल्प करता है।
यह मोनोरेपो संदर्भों (यानी import "../foo" ) और पैकेज-आधारित संदर्भों (यानी import "foo" ) के लिए काम करता है।
यह एनपीएम पैकेज और उनके स्रोत कोड प्रतिनिधित्व के लिए काम करता है।
और यह संकलन के दौरान tsconfig.json मशीनरी को हल करने की आवश्यकता को हटा देता है, हालांकि त्रुटि संदेश अगर इसे .d.ts नहीं मिल रहा है तो यह कम सहायक होगा।

यह सच होने के लिए थोड़ा अच्छा लगता है, अगर यह वास्तव में इतना आसान है, तो शायद मैं कुछ महत्वपूर्ण देख रहा हूं :)

जैसा कि अन्य भी बताते हैं, यह अभी भी बहुत महत्वपूर्ण है कि 'IntelliSense' .ts फाइलों के साथ काम करता रहे।

तो, अगर, 'संदर्भ लगता है' आदि के लिए 'परिभाषा पर जाएं,' अनुरोध तब किया जाता है, यह कुछ रिवर्स मानचित्रण इसी का पता लगाने का उपयोग करना चाहिए .ts से फ़ाइल .d.ts फ़ाइल यह इतना इस्तेमाल किया दूर।

यह मानचित्रण उदाहरण का उपयोग करके किया जा सकता है:

की तरह एक एम्बेडेड टिप्पणी स्ट्रिंग का उपयोग //# sourceURL = ../src/foo.ts में .d.ts
- एक अधिक विस्तृत सोर्समैप का उपयोग 'रोल अप' .d.ts से मूल .ts वापस मैप करने के लिए किया जा सकता है
.js फ़ाइल को हल करना, और `.ts . का पता लगाने के लिए इसके स्रोत मानचित्र का उपयोग करना

यह .d.ts के पुनर्निर्माण के विषय का परिचय देता है जब उस .ts को बदल दिया जाता है, लेकिन मुझे यकीन नहीं है कि इसे इस प्रस्ताव द्वारा हल किया जाना चाहिए। उदाहरण के लिए, आज यह मामला पहले से ही है कि .js फ़ाइलों के पुनर्निर्माण के लिए कुछ प्रक्रिया की आवश्यकता है, यहां तक कि रूट प्रोजेक्ट से भी। इसलिए मुझे लगता है कि यह मान लेना सुरक्षित होगा कि यदि वह मौजूद है, तो निर्भरता के पुनर्निर्माण के लिए भी कुछ होगा। प्रत्येक पैकेज के लिए समानांतर tsc का एक गुच्छा हो सकता है, tsbuild हो सकता है, compileOnSave -समान व्यवहार आदि के साथ एक स्मार्ट आईडीई हो सकता है।

poelstra 10 नव॰ 2017

@pgonzal @michaelaird https://github.com/spion/typescript-workspace-plugin केवल यही करता है - यह परिभाषा पर जाता है और एक बहु-tsconfig यार्न/लेर्ना/आदि कार्यक्षेत्र परियोजना के लिए सभी संदर्भ ढूंढता है।

spion 10 नव॰ 2017

दिलचस्प... मुझे आश्चर्य है कि क्या हम रश के साथ यह काम कर सकते हैं। हम देख लेंगे।

octogonz 10 नव॰ 2017

👍2

एफवाईआई इस प्रयास के हिस्से के रूप में हमने बनाया एक और आसान उपकरण wsrun

lerna run , यह कार्यक्षेत्र के सभी पैकेजों के लिए एक कमांड चलाता है।

चूंकि टाइपस्क्रिप्ट निर्भरता को क्रम में संकलित करने की आवश्यकता होती है, wsrun उनके package.json निर्भरता के आधार पर एक टोपोलॉजिकल ऑर्डरिंग में पैकेज कमांड चलाने में सक्षम है। यह निर्माण के दौरान समानता का समर्थन करता है। यह बेहतर समानांतर नहीं है, लेकिन बाद में इसमें सुधार किया जा सकता है।

spion 30 नव॰ 2017

बस एक नोट, ओओ यार्न के लिए एक और मोनोरेपो उपकरण है। इसने हाल ही में कमांड के 'टोपोलॉजिकल' ऑर्डरिंग के लिए भी समर्थन जोड़ा है।

cherrydev 4 दिस॰ 2017

मैं यहां "रीफैक्टरिंग" शब्द पोस्ट करना चाहता हूं क्योंकि यह हमारे लिए एक महत्वपूर्ण लक्ष्य है, हालांकि शायद वर्तमान प्रस्ताव के लिए स्पर्शरेखा (https://github.com/Microsoft/TypeScript/issues/3469#issuecomment-341317069) और इस मुद्दे में बहुत बार उल्लेख नहीं किया गया है।

हमारा उपयोग मामला कई टीएस परियोजनाओं के साथ एक मोनोरेपो है, इसे मूल रूप से common-library प्लस कुछ ऐप्स तक घटाया जा सकता है: app1 और app2 । आईडीई में काम करते समय, उन्हें एक ही परियोजना के रूप में माना जाना चाहिए, उदाहरण के लिए, नाम बदलें रिफैक्टरिंग को सभी तीन मॉड्यूल में काम करना चाहिए, लेकिन app1 और app2 भी दो अलग-अलग निर्माण लक्ष्य हैं। जबकि मैं मानता हूं कि बिल्ड आम तौर पर एक अलग चिंता है, सच्चाई यह है कि हमारे ऐप्स काफी छोटे हैं और cd app1 && tsc जैसा कुछ करना हमारे लिए बिल्कुल ठीक होगा।

यदि टाइपस्क्रिप्ट इसका समर्थन करने का एक अच्छा तरीका लेकर आता है, तो यह बहुत अच्छा होगा।

borekb 8 दिस॰ 2017

मोनोरेपो क्रॉस-प्रोजेक्ट रिफैक्टरिंग/संदर्भों के लिए मुझे यह सेटअप मेरे लिए काम कर रहा है यदि आप बनाम कोड में काम कर रहे हैं:

रूट tsconfig:

"compilerOptions": {
   "baseUrl": ".",
   // global types are different per project
   "types": [],
   "paths": {
      "lib": ["packages/lib/src"],
      "xyz1": ["packages/xyz1/src"],
      "xyz2": ["packages/xyz2/src"],
   }
},
"include": ["./stub.ts"], // empty file with export {} to stop vscode complaining about no input files
"exclude": ["node_modules"]

संकुल/xyz1/tsconfig.json

{
  "extends": "../../tsconfig",
   "compilerOptions": {
      "types": ["node"],
   },
   "include": ["src/**/*"]
}

संकुल/xyz2/tsconfig.json

{
  "extends": "../../tsconfig",
   "compilerOptions": {
      "types": ["webpack-env"]
   },
  "include": ["src/**/*"]
}

संकुल/lib/tsconfig.json

{
   "extends": "../../tsconfig",
    "compilerOptions": { ... },
    "include": ["src/**/*"],
    // special file to load referenced projects when inside in lib package, without it they won't be 
    // visible until you open some file in these projects 
    "files": ["./references.ts"],
}

संकुल/lib/tsconfig-build.json

{
   "extends": "./tsconfig",
    // exclude referenced projects when building
   "files": []
}

संकुल/lib/references.ts

import "xyz1";
import "xyz2";

export {};

आपको पैकेज के package.json सही main संपत्ति की आवश्यकता है और उदाहरण के लिए नो-लिब पैकेज के लिए भी types हो सकता है:

  "main": "src/main.tsx",
  "types": "src/main.tsx",

इस तरह lib में किसी चीज़ को रीफैक्टरिंग/नाम बदलने से xyz1 और xyz2 में संदर्भों को भी रिफैक्टर किया जाएगा। इसके अलावा परियोजनाओं में इस तरह से अलग-अलग ग्लोबल/लक्षित libs हो सकते हैं।

asvetliakov 8 दिस॰ 2017

ग्रैडल में, वे बस इसे - समग्र निर्माण कहते हैं ।

वैसे, अगर मैं टाइपस्क्रिप्ट कंपाइलर में योगदान देना चाहता हूं, तो क्या मुझे शुरू करना चाहिए? मैंने रेपो को क्लोन किया है और यह कोई छोटी बात नहीं है (मैं स्रोत पढ़ने के लिए उपयोग करता हूं: कोणीय, आयनिक, एक्सप्रेस जब मैं इसे दस्तावेज़ों से प्राप्त नहीं कर सकता या इंटरनेट से दूर हूं ...) मुझे वास्तव में एक से मदद की ज़रूरत है मुझे जाने का रास्ता बताने के लिए, कृपया।

धन्यवाद!
टाइपस्क्रिप्ट के लिए उज्ज्वल भविष्य।

SalathielGenese 2 जन॰ 2018

मेरे पास एक प्रोटोटाइप है जो मैं चाहता हूं कि लोग कोशिश करें कि वे सापेक्ष मॉड्यूल पथ का उपयोग कर रहे हैं या नहीं। https://github.com/RyanCavanaugh/project-references-demo पर एक नमूना रेपो है जो मूल परिदृश्य को रेखांकित करता है और दिखाता है कि यह कैसे काम करता है।

स्थानीय रूप से प्रयास करने के लिए:

git clone https://github.com/RyanCavanaugh/TypeScript
git checkout pr-lkg
npm install
npm run build
npm link

फिर अपने दूसरे फ़ोल्डर में:

npm link typescript

जैसे-जैसे चीजें बदलती हैं, मैं pr-lkg टैग को नवीनतम वर्किंग कमिट पर इंगित करता रहूंगा। मेरे todos पर अगला:

[x] आश्रित परियोजनाओं के निर्माण न होने पर बेहतर त्रुटि संदेश जोड़ें
[ ] पुनर्निर्देशन व्यवहार को गैर-सापेक्ष मॉड्यूल पथों पर लागू करें
[ ] उपभोग करने के लिए उपकरण बनाने के लिए एक एपीआई का पर्दाफाश करें

RyanCavanaugh 5 जन॰ 2018

@RyanCavanaugh मैं वास्तव में del मॉड्यूल या Error: Cannot find module 'C:\github\TypeScript\built\local\tsc.js' (शायद आपका स्थानीय पथ?)

क्या यह केवल tsc या यह भाषा सर्वर के साथ VSCode में प्रोजेक्ट-वाइड रिफैक्टरिंग के लिए भी जिम्मेदार होगा?

borekb 5 जन॰ 2018

...भी pr-lkg टैग गायब है।

KostyaTretyak 6 जन॰ 2018

टैग वहाँ है (यह एक शाखा नहीं है)। देखें https://github.com/RyanCavanaugh/TypeScript/tree/pr-lkg

billti 6 जन॰ 2018

👍2

references में tsconfig.json ऑप्ट-इन प्रति-निर्भरता है, क्या इसे rootDir बाहर हल होने वाली हर चीज़ पर लागू करने का कोई मतलब नहीं होगा?

मैं sandbox संपत्ति की तरह कुछ कल्पना कर रहा हूं जो इस तरह दिख सकता है:

# tsconfig.json
{
  "compilerOptions": {
    "outDir": "lib",
    "sandbox": "."
  },
  "include": ["src/index.ts"]
}

सैंडबॉक्स भी उसी मान पर rootDir सेट करेगा। tsconfig.json निर्देशिकाओं को स्पष्ट रूप से पथ प्रदान करने के बजाय, सामान्य मॉड्यूल रिज़ॉल्यूशन लागू होगा, और आप tsconfig.json स्वचालित रूप से खोजने के लिए FS ट्री खोज सकते हैं।

# package.json
{
  "name": "animals",
  "module": "src",
  "typings": "lib",
  "dependencies": {
    "core": "*"
  }
}

इस तरफ:

दो समन्वयित सूचियों ( references और dependencies ) को बनाए रखने की आवश्यकता नहीं है।
पैकेज को अपने से बाहर फाइल सिस्टम का कोई ज्ञान नहीं है।
कस्टम पथों के बजाय नोड मॉड्यूल रिज़ॉल्यूशन रणनीति का उपयोग करें।

azz 6 जन॰ 2018

@RyanCavanaugh , जहाँ तक मैं समझता हूँ, मैं केवल इन परिवर्तनों के साथ स्थानीय रूप से काम कर सकता हूँ और मैं ऐसी परियोजनाओं को परीक्षण के लिए नहीं भेज पाऊँगा, उदाहरण के लिए, travis-ci.org पर। सही?

KostyaTretyak 6 जन॰ 2018

@billti / @mhegazy . के साथ आज की बैठक के नोट्स

संदर्भ खोजें/नाम बदलें काम करना है, कम से कम उन परिदृश्यों के लिए जहां परियोजनाओं को बंद करने का निर्धारण करने के लिए आवश्यक संकलन संदर्भ स्मृति में फिट बैठता है
समाधान-विस्तृत नाम बदलकर "समाधान" फ़ाइल ढूँढ़ने के लिए चलेंगे, संदर्भ परियोजनाओं को खोजने के लिए पीछे की ओर काम करेंगे, और फिर ग्राफ़ के उन अनुभागों को लागू-लोड करेंगे जिनसे प्रतीक दिखाई दे रहा है। वास्तविक मूल घोषणा को खोजने के लिए यह एक पुनरावृत्त प्रक्रिया हो सकती है
tsbuild को -w मोड को संभालने की जरूरत है
समाधान में समाधान फ़ोल्डर के बाहर उत्पन्न होने वाले उपप्रोजेक्ट नहीं हो सकते हैं
उदाहरण के लिए स्पष्ट दस्तावेज़ीकरण की आवश्यकता है गल्प, वेबपैक

साइडबार: यह नाम आज काम नहीं करता

function f() {
  if (Math.random() > 0.5) {
    return { foo: 10 };
  } else {
    return { foo: 20 };
}
// rename foo here doesn't rename *both* instances in the function body
f().foo;

RyanCavanaugh 9 जन॰ 2018

❤2

धन्यवाद रयान, मोहम्मद और बिल। परियोजनाओं में काम कर रहे संदर्भ खोजें/नाम बदलें परिदृश्य प्राप्त करना मेरे दिमाग में मुख्य उपयोग के मामलों में से एक था जब मैंने टाइपस्क्रिप्ट के बारे में मूल शिकायत की थी जो मध्यम आकार की परियोजनाओं का समर्थन नहीं कर रहा था। मध्यम आकार की परियोजनाएं मॉड्यूलर हैं लेकिन बड़ी नहीं हैं। मैंने यहां अब तक जो प्रस्ताव और काम देखा है, वह एक स्केलेबिलिटी प्ले की तरह लगता है। यह टाइपस्क्रिप्ट के दीर्घकालिक स्वास्थ्य के लिए बहुत महत्वपूर्ण है, लेकिन यह ज्यादातर बड़ी परियोजनाओं के लिए फायदेमंद है, मध्यम नहीं। रेयान की इस टिप्पणी में मैंने जो कुछ सुना है, वह टाइपस्क्रिप्ट में मध्यम आकार की परियोजनाओं के विकास के एर्गोनॉमिक्स को बेहतर बनाने के लिए आवश्यक है।

हमेशा की तरह, आपके प्रयासों के लिए पूरी टाइपस्क्रिप्ट टीम को बहुत-बहुत धन्यवाद! आप कमाल का काम कर रहे हैं।

nycdotnet 9 जन॰ 2018

लर्न/यार्न कार्यक्षेत्र के साथ एक तरकीब है जो आपके जीवन को बहुत आसान बना देगी।
अपने पैकेज में main और types प्रविष्टियों को अपने src/index पर इंगित करें। ts फ़ाइल, और संदर्भ खोजें/नाम बदलें परिदृश्य बस काम करेगा।
और आप अपने पूरे प्रोजेक्ट को एक tsc रनिंग के साथ संकलित करने में सक्षम होंगे।
आप अपने कुछ पैकेजों के लिए ऐसा कर सकते हैं, आप सभी के लिए कर सकते हैं। आपका फोन।

कुछ कमियां और नुकसान हैं (यदि आपके पास एक पैकेज में वृद्धि है, या किसी वैश्विक प्रतीकों का आयात है, तो यह आपके पूरे कार्यक्रम को प्रदूषित करेगा), लेकिन सामान्य तौर पर यह बहुत अच्छी तरह से काम करता है।
जब आप एनपीएम को प्रकाशित करना चाहते हैं तो आप मुख्य और प्रकारों को उचित मानों पर सेट कर रहे हैं (आपके निर्माण के हिस्से के रूप में, या तो)

उपरोक्त सेटअप के साथ, मुझे कमोबेश सभी अपेक्षित सुविधाएँ मिलीं

Bnaya 18 जन॰ 2018

👍2

यहाँ लर्न/यार्न कार्यक्षेत्र के साथ एक तरकीब है जो आपके जीवन को बहुत आसान बना देगी।
उप परियोजनाओं के अपने package.json में मुख्य और प्रकार की प्रविष्टियों को अपनी src/index.ts फ़ाइल पर इंगित करें, और संदर्भ खोजें/नाम बदलें परिदृश्य बस काम करेगा।

मेरे अनुभव में, उस सेटअप के साथ समस्या यह है कि टाइपस्क्रिप्ट _external_ पैकेज की ts फ़ाइलों का इलाज करना शुरू कर देगा जैसे कि वे उस पैकेज के _sources_ थे जिसकी उन्हें आवश्यकता है, बाहरी पुस्तकालयों के रूप में नहीं। यह कई मुद्दों का कारण बनता है।

बाहरी पैकेज कई बार संकलित किए जाते हैं, हर बार _requiring_ पैकेज के tsconfig का उपयोग करते हुए। यदि आवश्यक पैकेज में अलग-अलग tsconfigs (उदाहरण के लिए अलग-अलग libs) हैं, तो यह फिर से संकलित होने तक आवश्यक पैकेज पर झूठी संकलन त्रुटियों को प्रकट करने का कारण बन सकता है।
संकुल की आवश्यकता भी धीमी गति से संकलित होती है क्योंकि उनमें आवश्यकता से अधिक फाइलें शामिल होती हैं।
सभी पैकेजों का rootDir शीर्ष-स्तरीय निर्देशिका बन जाता है, संभावित रूप से किसी भी पैकेज से किसी भी TS फ़ाइल को सीधे शामिल करने की अनुमति देता है, बजाय केवल index । यदि डेवलपर्स सावधान नहीं हैं, तो वे आवश्यक पैकेज एपीआई को बायपास कर सकते हैं। इसके अलावा, यदि निर्माण प्रक्रिया मजबूत नहीं है, तो पैकेज की आवश्यकता समाप्त हो सकती है जिसमें आवश्यक पैकेज से डुप्लिकेट कोड शामिल हो सकता है जो बाहरी होने के लिए था।

हमारी परियोजनाओं में हमने कमियों के कारण टीएस फाइलों के आधार पर इनकार किया है। सभी इंटर-पैकेज निर्भरताएं index.d.ts फाइलों पर हैं, इसलिए कंपाइलर उन्हें बाहरी मानता है और सब अच्छा है।

बेशक .d.ts आधार पर एक बहु-चरण निर्माण की आवश्यकता की समस्या है (वेबपैक जैसे टूल के साथ आउट-ऑफ-द-बॉक्स संभव नहीं है) और खराब आईडीई अनुभव की समस्या (नाम बदलें, संदर्भ पैकेज सीमाओं को पार नहीं कर रहे हैं) )

lorenzodallavecchia 18 जन॰ 2018

मैं कुछ अन्य भावनाओं से सहमत हूं - टाइपस्क्रिप्ट एक कंपाइलर है, बिल्ड सिस्टम नहीं। बेहतर मल्टी प्रोजेक्ट बिल्ड का समर्थन करने के लिए हमें अपने टूलिंग की आवश्यकता है। मुझे पता है कि ऐसा करने के लिए समुदाय में कुछ विकल्प हैं। उदाहरण के तौर पर, सी # में रोसलिन नामक एक कंपाइलर और एमएसबिल्ड नामक एक बिल्ड टूल है।

mikehaas763 18 जन॰ 2018

आज @mhegazy के साथ चर्चा करें कि नाम बदलने के तरीके को व्यावहारिक रूप से कम दर्द के साथ कैसे काम किया जाए।

नाम बदलने के लिए गैर-पतित सबसे खराब स्थिति इस तरह दिखती है:

// alpha.ts
const v = { a: 1 };
export function f() { return v; }
export function g() { return v; }

// alpha.d.ts (generated)
export function f(): { a: number };
export function g(): { a: number };

// beta.ts (in another project)
import { f } from '../etc/alpha';
f().a;

// gamma.ts (in yet another project)
import { g } from '../etc/alpha';
g().a;

कुंजी अवलोकन है कि यह पता चला है कि नाम बदलने असंभव है f().a नाम बदलने चाहिए g().a जब तक आप देख सकते हैं alpha.ts दो मेल खाते हैं।

कार्यान्वयन योजना का एक मोटा स्केच:

"समृद्ध" और "दुबला" इन-मेमोरी सोर्सफाइल .d.ts फाइलों का प्रतिनिधित्व है। "लीन" फ़ाइलें डिस्क से पढ़ी जाती हैं; इन-मेमोरी .d.ts जनरेशन के परिणामस्वरूप "अमीर" उत्पन्न होते हैं
"रिच" .d.ts SourceFiles में उनके पहचानकर्ता नोड्स से मूल स्रोत फ़ाइल में मूल नाम [s] के संदर्भ हैं
नाम बदलने के दौरान, हम पहले हमेशा की तरह विचाराधीन प्रतीक पर जाते हैं। यदि यह प्रोजेक्ट-संदर्भित .d.ts में उत्पन्न होता है, तो हम इसे लागू करते हैं-लोड करते हैं और इसकी "रिच" .d.ts फ़ाइल बनाते हैं
- नोट: यह प्रक्रिया पुनरावृत्त है, यानी इसे वास्तविक कार्यान्वयन फ़ाइल में आने तक कई स्तरों का पता लगाने की आवश्यकता हो सकती है (एक जो एक परियोजना संदर्भ के कारण .d.ts रीडायरेक्ट नहीं है)
अब यह पता लगाने के लिए "रिच" पॉइंटर्स का उपयोग करें कि प्रोजेक्ट के .d.ts में कौन से अन्य पहचानकर्ता समान स्रोत फ़ाइल पहचानकर्ता से उत्पन्न होते हैं
प्रत्येक बहाव परियोजना में, पाठ स्कैन नाम बदली गई पहचानकर्ता के लिए और अगर देखना अपने "जाना-टू-def" परिणाम .d.ts में "एक ही प्रतीक से शुरू कर दिया" स्थानों में से किसी है
कार्यान्वयन फ़ाइल में नाम बदलें

RyanCavanaugh 9 फ़र॰ 2018

@RyanCavanaugh परिभाषा पर जाएगा / इस मॉडल के साथ काम करने वाले सभी संदर्भों को

Bnaya 9 फ़र॰ 2018

बड़ी संख्या में खुले प्रश्नों के इर्द-गिर्द एंडर्स और मोहम्मद के साथ पहले की चर्चा के नोट्स

क्या prepend भी .d.ts लागू होता है? हां
हम dogfood शाखा में @internal साथ क्या करते हैं? हमें आंतरिक घोषणाओं को स्थानीय .d.ts फ़ाइलों में रखने की आवश्यकता है, लेकिन वे नहीं चाहते कि वे आउटपुट संस्करणों में दिखाई दें
- --stripInternal निकालें
- लेकिन इसे बहिष्कृत न करें (अभी तक...?)
- रयान remove-internal टूल लिखेंगे (डोनिश)
- निर्मित -> एलकेजी प्रक्रिया @internal घोषणाओं को हटा देती है
यदि आप .d.ts फ़ाइल को @types से बदलते हैं तो क्या होगा?
- यदि आप संभावित नई त्रुटियां देखना चाहते हैं तो मैन्युअल रूप से पुनर्निर्माण के लिए बाध्य करने की आवश्यकता है ️
- अगर यह वास्तव में समस्याग्रस्त हो जाता है तो अंततः आउटपुट फ़ोल्डर में "फाइलें मैंने देखा। txt" फ़ाइल लिख सकता है
क्या noEmitOnError अनिवार्य है? हां।
- अन्यथा पुनर्निर्माण त्रुटियों को छुपाएगा!
referenceTarget -> composable
लीफ-नोड परियोजनाओं के बारे में क्या है जो घोषणा नहीं करना चाहते हैं, लेकिन तेजी से पुनर्निर्माण करना चाहते हैं?
- tsbuild या समकक्ष composable की गैर-अपस्ट्रीम-प्रासंगिक आवश्यकताओं के अनुपालन को देखने के लिए जांच कर सकते हैं
परिपत्र संदर्भ, (कैसे) वे काम करते हैं?
- डिफ़ॉल्ट रूप से, नहीं
- यदि आप ऐसा करना चाहते हैं तो आप उदाहरण के लिए { path: "../blah", circular: true } निर्दिष्ट कर सकते हैं
- यदि आप करते हैं, तो यह सुनिश्चित करने के लिए आप पर निर्भर हो जाता है कि आपका निर्माण नियतात्मक है और हमेशा एक निश्चित बिंदु तक पहुंचता है (संभवतः यह नहीं हो सकता है ?!)
- सर्कुलर का रीमैपिंग वैकल्पिक (लेकिन प्राथमिकता वाला) रीमैप है

मिश्रण

@weswigham का नाम बदलने के लिए एक वैकल्पिक विचार है कि हमें @mhegazy . के साथ चर्चा करने की आवश्यकता है

RyanCavanaugh 28 फ़र॰ 2018

👍1

मैं पहले ही हार चुका हूं। मैं ज्यादातर सिर्फ संकलक (अलग उपकरणों के लिए अलग जिम्मेदारियों) के स्रोतमैप की व्याख्या रखना चाहता था, लेकिन जब आप दूर थे तो मैंने इसे वैसे भी जोड़ने पर काम किया (क्योंकि स्पष्ट रूप से निर्बाध गो-टू डिफ वांछनीय है)।

weswigham 28 फ़र॰ 2018

👍3

@RyanCavanaugh
#२३९४४ को मर्ज करने के बाद सभी संदर्भित परियोजनाओं का नाम बदलना/ढूंढना चाहिए? क्या हमें composite: true और projectReferences: [] का उपयोग करना चाहिए यदि केवल भाषा सेवाओं (लेकिन tsbuild नहीं) की आवश्यकता है?

asvetliakov 11 मई 2018

#२३९४४ को मर्ज करने के बाद सभी संदर्भित परियोजनाओं का नाम बदलना/ढूंढना चाहिए?

अभी तक नहीं। लेकिन हम इस पर आगे काम कर रहे हैं।

क्या हमें समग्र: सत्य और प्रोजेक्ट संदर्भ: [] का उपयोग करना चाहिए यदि केवल भाषा सेवाओं (लेकिन tsbuild नहीं) की आवश्यकता है?

मुझे यकीन नहीं है कि मैं इस सवाल को समझता हूं .. आपका क्या मतलब है "भाषा सेवा" और "निर्माण" नहीं?

mhegazy 11 मई 2018

मुझे यकीन नहीं है कि मैं इस सवाल को समझता हूं .. आपका क्या मतलब है "भाषा सेवा" और "निर्माण" नहीं?

मैं केवल मोनोरेपो में कई परियोजनाओं में संपादक समर्थन (नाम बदलें/सभी संदर्भ/आदि...) में दिलचस्पी रखता हूं, नए बिल्ड टूल में नहीं (उर्फ build mode ) (#22997) क्योंकि मैं उपयोग कर रहा हूं मेरे संकलन के लिए बेबल।

asvetliakov 11 मई 2018

बस यही काम करना चाहिए। बिल्ड एक ऑप्ट-इन सुविधा है, यदि आप नहीं चाहते हैं तो आपको इसका उपयोग करने की आवश्यकता नहीं है .. उदाहरण के लिए VSCode में आपके भाषा सेवा अनुभव के लिए tsc समान कैसे आवश्यक नहीं है।

mhegazy 11 मई 2018

हालांकि, क्रॉस प्रोजेक्ट रेफरी के कार्य करने के लिए आवश्यक मेटाडेटा का उत्पादन करने के लिए, आपको घोषणाओं और घोषणा मानचित्रों के साथ निर्माण करने की आवश्यकता होगी।

weswigham 11 मई 2018

मुझे यकीन नहीं है कि मैं प्रस्ताव के सभी पहलुओं को सही ढंग से समझता हूं, लेकिन क्या यह संभव होगा कि अलग-अलग प्रोजेक्ट दूसरों को पथ से संदर्भित न करें, बल्कि इसके बजाय नाम से? वर्कस्पेस प्रोजेक्ट में प्रत्येक प्रोजेक्ट पथ को निर्दिष्ट करने का एक तरीका होना चाहिए, ग्लब्स के माध्यम से यार्न वर्कस्पेस के समान, या शायद प्रत्येक व्यक्तिगत प्रोजेक्ट नाम सूचीबद्ध करके:

मूल रूप से, इसके बजाय:

"dependencies": [
    "../common", 
    "../util"
],

क्या हम कृपया कर सकते हैं

"dependencies": [
    "common", 
    "util"
],

और एक कार्यक्षेत्र है tsconfig.json

"workspace": {
  "common": "packages/common",
  "util": "packages/util"
}

या बेहतर अभी तक, पथ सिंटैक्स:

"workspace": {
  "*":"packages/*"
}

लाभ:

मॉड्यूल सिस्टम के आधार पर विभिन्न लुकअप नियमों को निर्दिष्ट करने की क्षमता
कार्यस्थान के बाहर पैकेज डाउनलोड होने पर नोड_मॉड्यूल्स पर वापस जाने की क्षमता
एकाधिक रेपो को क्लोन करके और पथों के लिए एक अलग कॉन्फ़िगरेशन होने पर काम करने के लिए कई कार्यस्थानों को स्वतंत्र रूप से एकत्रित करने की क्षमता, ताकि आप समानांतर में और भी अधिक पैकेज पर काम कर सकें।

spion 16 मई 2018

या कम से कम, क्या हमारे पास गैर-पथ नाम हो सकते हैं (जो './' या '../' से शुरू नहीं होते हैं) भविष्य में उपयोग के लिए आरक्षित हैं ...

spion 16 मई 2018

मुझे यकीन नहीं है कि यह कितना संबंधित है लेकिन यार्न 1.7 ने हाल ही में "केंद्रित कार्यक्षेत्र" की अवधारणा पेश की, यह ब्लॉग पोस्ट देखें ।

क्या यहां कोई व्यक्ति दोनों कार्यक्षेत्रों और काम के साथ पर्याप्त रूप से परिचित है @RyanCavanaugh टाइपस्क्रिप्ट प्रोजेक्ट संदर्भ/बिल्ड मोड के आसपास कर रहा है, शायद एक टिप्पणी छोड़ने के लिए कि क्या वे बिल्कुल संबंधित हैं? मेरी आंत की भावना यह है कि यार्न कार्यक्षेत्रों के बीच _somewhere_ (एनपीएम उन्हें इस वर्ष भी मिलेगा) और भविष्य के टाइपस्क्रिप्ट संस्करण कई परियोजनाओं और साझा पुस्तकालयों के साथ मोनोरेपो के लिए एक अच्छा समर्थन है। (वर्तमान में हम दर्द महसूस करते हैं।)

borekb 24 मई 2018

मुझे इस सुविधा की प्रगति के बारे में अपडेट प्राप्त करना वाकई अच्छा लगेगा। हम अगले एक महीने में ऑरेलिया वीनेक्स्ट को एक मोनोरेपो में स्थानांतरित करने की योजना बना रहे हैं। हमारा नया संस्करण 100% टाइपस्क्रिप्ट है और यदि हम कर सकते हैं तो हम Lerna के बजाय एक आधिकारिक TS प्रोजेक्ट सिस्टम का उपयोग करना पसंद करेंगे। हम नई सुविधाओं के शुरुआती अपनाने वाले/परीक्षक बनकर भी खुश हैं :)

EisenbergEffect 15 जून 2018

👍3

स्रोत मानचित्र समर्थन कोर समर्थन और गोटो डीईएफ़ को अंतिम रिलीज़ (टीएस 2.9) जोड़ा गया था। tsc --b बिल्ड सपोर्ट के लिए पहले से ही है और TS 3.0 के लिए बाध्य है। टाइपप्रति कोड आधार इसका उपयोग करने के लिए स्थानांतरित हो गया है। हम वर्तमान में टाइपस्क्रिप्ट रेपो का उपयोग करके इस समर्थन का परीक्षण कर रहे हैं।

इस बिंदु पर अभी भी क्या करने की आवश्यकता है: 1. बहु परियोजना परिदृश्यों पर काम करने के लिए सभी संदर्भ खोजें/नाम बदलें। 2. संपादक में पृष्ठभूमि में .d.ts फ़ाइलों को अद्यतन करना, और 3. बहु-परियोजना परिदृश्यों के लिए --watch समर्थन। बहुत सारे और बहुत सारे परीक्षण भी।

mhegazy 19 जून 2018

🎉11 👍3

यह टिकट 3 साल से उसकी किताबों पर है। अभी भी 3/6 बकाया आइटम?

claudeduguay 20 जून 2018

@claudeduguay यह एक मौलिक परिवर्तन है कि टाइपस्क्रिप्ट किन परियोजनाओं का समर्थन करता है, जश्न मनाने का समय क्या आपको नहीं लगता? मैं इसके लिए बेहद खुश हूं!

borekb 20 जून 2018

👍2

@mhegazy यह बहुत अच्छी खबर है। मुझे यह सुनकर बहुत खुशी हुई कि TS टीम इसे अपने प्रोजेक्ट पर भी डॉगफूड कर रही है। पिछली कुछ चीजों के पूरा होने और इसे ऑरेलिया के लिए एक विकल्प के रूप में रखने की प्रतीक्षा कर रहे हैं :) जैसे ही इसे स्थापित करने पर कुछ दस्तावेज होंगे, हम अपने vNext को नए प्रोजेक्ट सिस्टम में स्थानांतरित करेंगे। इंतजार नहीं कर सकता!

EisenbergEffect 20 जून 2018

@mhegazy क्या आप इस पर कुछ प्रकाश @aurelia/kernel , @aurelia/runtime , @aurelia/jit आदि जैसे पैकेज हैं। वे मॉड्यूल नाम हैं जिनका उपयोग import विभिन्न परियोजनाओं के दौरान बयान। TS कंपाइलर कैसे समझेगा कि ये मॉड्यूल नाम विभिन्न संदर्भित फ़ोल्डरों को मैप करते हैं? क्या यह प्रत्येक संदर्भित फ़ोल्डर में रखी package.json फाइलों को उठाएगा? यह Lerna या Yarn Workspaces से किस प्रकार भिन्न होगा? ऊपर दिए गए लिंक में मेरा प्रारंभिक रूप मुझे लगता है कि मुझे एक कामकाजी समाधान प्राप्त करने के लिए लर्ना (डिप लिंकिंग और प्रकाशन) के संयोजन में टीएस परियोजनाओं (बिल्ड) का उपयोग करने की आवश्यकता होगी, लेकिन मैं नहीं देख रहा हूं कि टीएस कैसे ठीक से निर्माण करने जा रहा है अगर यह package.json और node_modules के साथ एकीकृत नहीं हो सकता है। TS रेपो स्रोत आपके औसत Lerna प्रोजेक्ट (वास्तव में ऐसा कुछ नहीं) से काफी अलग है, इसलिए मुझे आश्चर्य होने लगा है कि क्या यह हमारी आवश्यकताओं को पूरा करने में सक्षम होगा। कोई और जानकारी जो आप प्रदान कर सकते हैं, और esp। मैंने यहां जो वर्णन किया है, उसके समान एक कार्यशील डेमो समाधान सेटअप बहुत उपयोगी होगा। धन्यवाद!

EisenbergEffect 20 जून 2018

मैं @EisenbergEffect के समान प्रश्न साझा करता हूं। विशेष रूप से मैं यह भी उम्मीद कर रहा हूं कि यह lerna -प्रबंधित मोनोरेपो के साथ अच्छी तरह से काम करेगा।

yortus 20 जून 2018

👍1

विचार करने के लिए दो मोनोरेपो परिदृश्य

आइए एक सेटअप से शुरू करें जहां आपने लर्न के साथ सब कुछ सिम्लिंक किया है:

/packages
  /a
    /node_modules
      /b -> symlink to b with package.json "types" pointing to dist/index.d.ts
  /b
    /dist
      /index.d.ts -> built output of entry point declaration file

हम यहां जो महत्वपूर्ण चीज करना चाहते हैं, वह है b का पुनर्निर्माण करना, हमने a यदि a पुराना हो गया है। इसलिए हम "references": [ { "path": "../b" } ] को a के tsconfig.json जोड़ देंगे और tsc --build में a चलाएंगे ताकि b का सही अपस्ट्रीम बिल्ड प्राप्त हो सके। package.json निर्भरता को tsconfig.json प्रतिबिंबित कर सकते हैं जहां उपयुक्त हो।

एक और परिदृश्य (शायद कम आम) होगा यदि आप सिम्लिंकिंग नहीं कर रहे थे लेकिन फिर भी "कार्य करना चाहते थे" जैसे आप पैकेज के लाइव सेट पर काम कर रहे थे। आप इसे आज कुछ काफी कठिन पथ मानचित्रण के साथ कर सकते हैं, और कुछ लोग करते हैं। यहां प्रोजेक्ट संदर्भ समान रूप से ऑर्डरिंग बनाने में मदद करेंगे, लेकिन जब भी इसे संदर्भित किया गया था, तो स्वचालित रूप से पथ मैपिंग बनाने के लिए संदर्भ tsconfig फ़ाइल में किसी संपत्ति के लिए समर्थन होना बहुत वांछनीय होगा; उदाहरण के लिए यदि आपके पास था

{
  "compilerOptions": { "outDir": "bin" },
  "package": "@RyanCavanaugh/coolstuff"
}

फिर "references": [{ "path": "../cool" }] जोड़ने से स्वचालित रूप से @RyanCavanaugh/coolstuff -> ../cool/bin/ से पथ मैपिंग जुड़ जाएगी। हमने इसे अभी तक नहीं जोड़ा है, लेकिन अगर यह अधिक सामान्य परिदृश्य हो तो इस पर गौर कर सकते हैं।

RyanCavanaugh 20 जून 2018

👍2

आदर्श रूप से लर्न और टीएस यहां सहयोग कर सकते हैं और जहां उपयुक्त हो, package.json निर्भरता को tsconfig.json में प्रतिबिंबित कर सकते हैं

बाहरी टूलिंग पर भरोसा करने के बजाय, हम आपके package.json (बशर्ते यह आपके tsconfig के साथ हो) को संभावित संदर्भों के रूप में पढ़ने का विकल्प चुन सकते हैं यदि composite: true सेट है (यह देखने के लिए जांचें कि क्या प्रत्येक हल किए गए पैकेज में tsconfig.json , अगर इसमें एक है, तो इसे एक बिल्ड करने योग्य प्रोजेक्ट नोड और पुनरावृत्ति पर विचार करें)। चूंकि सब कुछ जगह में सिम्लिंक है, इसलिए हमें कार्यक्षेत्र को संभालने के लिए संकल्प (बहुत? कोई?) को बदलने की भी आवश्यकता नहीं है। लर्न वास्तव में किसी भी टीएस-विशिष्ट (या बिल्ड-स्पेसिफिक) सामान को सेट नहीं करता है जैसा कि afaik है, यह सिर्फ सब कुछ जगह में सिम्लिंक करता है और वर्जनिंग का प्रबंधन करता है। यह आज हम जो करते हैं उस पर एक अनुकूलन होगा, जो ts फाइलों को लोड करता है (चूंकि हम उन घोषणाओं को पसंद करते हैं) और पुरानी होने की परवाह किए बिना सब कुछ पुन: संकलित करते हैं।

weswigham 20 जून 2018

👍2 🎉1

@RyanCavanaugh यह बहुत रोमांचक लगता है। कोई विचार अगर यह रश की सिम्लिंकिंग रणनीति सामान्य/temp/package.json सिंथेटिक पैकेज बनाता है जिसमें रेपो में सभी पैकेजों के लिए सभी निर्भरताओं का सुपरसेट होता है। फिर हम इस सिंथेटिक पैकेज के लिए सिंगल इंस्टाल ऑपरेशन करने के लिए pnpm का उपयोग करते हैं। (पीएनपीएम एनपीएम की ट्री संरचना के बजाय एक निर्देशित-एसाइक्लिक-ग्राफ बनाने के लिए सिम्लिंक का उपयोग करता है, जो डुप्लिकेट लाइब्रेरी इंस्टेंस को समाप्त करता है)। फिर रश रेपो में प्रत्येक प्रोजेक्ट के लिए एक नोड_मॉड्यूल फ़ोल्डर बनाता है, जो सामान्य/अस्थायी के तहत उपयुक्त फ़ोल्डरों में इंगित करने वाले सिम्लिंक से बना होता है। परिणाम टाइपस्क्रिप्ट और मानक NodeJS रिज़ॉल्यूशन एल्गोरिथ्म के साथ पूरी तरह से संगत है। यह बहुत तेज़ है क्योंकि पूरे रेपो के लिए एक सिकुड़न फ़ाइल और एक संस्करण समीकरण है, जबकि अभी भी प्रत्येक पैकेज को अपनी निर्भरताओं को निर्दिष्ट करने की इजाजत है।

हम इस मॉडल के लिए tsconfig.json में कुछ खास नहीं डालते हैं। यदि गोटो-डेफिनिशन फीचर के लिए कुछ विशेष टाइपस्क्रिप्ट कॉन्फ़िगरेशन की आवश्यकता होती है, तो हम आदर्श रूप से इसे गिट में संग्रहीत करने के बजाय इंस्टॉल के दौरान स्वत: उत्पन्न करना चाहते हैं।

octogonz 20 जून 2018

@pgonzal रश के लिंक के लिए धन्यवाद! मैंने इसे अभी तक नहीं देखा था। मैं आज रात इसे देख लूंगा।

@RyanCavanaugh स्पष्टीकरण के लिए धन्यवाद। लर्न के साथ आपका पहला परिदृश्य हमारे पास सबसे करीब है। यहाँ TS और lerna के साथ हमारा UX रेपो है जिसे हम https://github.com/aurelia/ux पर नए प्रोजेक्ट समर्थन का उपयोग करना चाहते हैं।

@weswigham लगता है कि आप जो वर्णन कर रहे हैं वह हमारे परिदृश्य में भी फिट होगा। उदाहरण रेपो ऊपर।

EisenbergEffect 21 जून 2018

बस ध्यान दें कि यार्न कार्यक्षेत्र के मामले में, मॉड्यूल प्रत्येक व्यक्तिगत पैकेज की निर्देशिका में सिमलिंक नहीं होते हैं, इसके बजाय वे शीर्ष स्तर के कार्यक्षेत्र में सिमलिंक होते हैं node_modules ।

यही कारण है कि मुझे लगता है कि संदर्भ जो एक बिंदु ('./' या '../') से शुरू नहीं होते हैं उन्हें भविष्य के लिए आरक्षित किया जाना चाहिए। उम्मीद है कि वे "नामित संदर्भ" होंगे, जिन्हें सापेक्ष पथ के रूप में व्यवहार करने के बजाय सक्रिय मॉड्यूल रिज़ॉल्यूशन रणनीति के माध्यम से संभाला जाएगा।

spion 21 जून 2018

👍2

@spion हम जरूरत path अलावा किसी संपत्ति के नाम का उपयोग करेंगे (उदाहरण के लिए "references": [ { "module": "@foo/baz" } ] ); मैं भ्रम पैदा नहीं करना चाहता जिसमें "bar" और "./bar" मतलब files में एक ही बात है लेकिन references में एक अलग बात है

RyanCavanaugh 21 जून 2018

👍2

परियोजना संदर्भ

एक उदाहरण परियोजना

/src/converter.ts
/src/units.ts
/test/converter-tests.ts
/test/units-tests.ts
/tsconfig.json

// converter-tests.ts
import * as converter from "../converter";

assert.areEqual(converter.celsiusToFahrenheit(0), 32);

कार्यान्वयन फ़ाइलों के लिए परीक्षण फ़ाइलों को आयात करना संभव था
आउटपुट फ़ोल्डर नाम में src दिखाई दिए बिना एक ही समय में test और src बनाना संभव नहीं था, जो आप शायद नहीं चाहते
कार्यान्वयन फ़ाइलों में केवल आंतरिक को बदलने के लिए परीक्षणों को फिर से टाइप करना आवश्यक है, भले ही यह कभी भी नई त्रुटियों का कारण न बने
केवल परीक्षणों को बदलने के लिए कार्यान्वयन को फिर से टाइप करना आवश्यक है, भले ही कुछ भी न बदला हो

कोई अंतर्निहित अप-टू-डेट जाँच नहीं है, इसलिए आप हमेशा tsc दो बार चलते हैं
tsc दो बार आमंत्रित करने से स्टार्टअप समय अधिक लगता है
tsc -w एक साथ कई कॉन्फिग फाइलों पर नहीं चल सकता

परियोजना संदर्भ इन सभी समस्याओं और बहुत कुछ को हल कर सकते हैं।

एक परियोजना संदर्भ क्या है?

{
    "compilerOptions": {
        // The usual
    },
    "references": [
        { "path": "../src" }
    ]
}

जब आप किसी प्रोजेक्ट का संदर्भ देते हैं, तो नई चीज़ें होती हैं:

किसी संदर्भित प्रोजेक्ट से मॉड्यूल आयात करने के बजाय इसकी आउटपुट घोषणा फ़ाइल ( .d.ts ) लोड होगी
यदि संदर्भित प्रोजेक्ट outFile उत्पन्न करता है, तो आउटपुट फ़ाइल .d.ts फ़ाइल की घोषणाएं इस प्रोजेक्ट में दिखाई देंगी
बिल्ड मोड (नीचे देखें) जरूरत पड़ने पर स्वचालित रूप से संदर्भित प्रोजेक्ट का निर्माण करेगा

`composite`

rootDir सेटिंग, यदि स्पष्ट रूप से सेट नहीं है, तो tsconfig फ़ाइल वाली निर्देशिका के लिए डिफ़ॉल्ट है
सभी कार्यान्वयन फ़ाइलों का मिलान include पैटर्न से होना चाहिए या files सरणी में सूचीबद्ध होना चाहिए। यदि इस बाधा का उल्लंघन किया जाता है, तो tsc आपको सूचित करेगा कि कौन-सी फ़ाइलें निर्दिष्ट नहीं की गई थीं
declaration चालू होना चाहिए

`declarationMaps`

`prepend` साथ `outFile`

   "references": [
       { "path": "../utils", "prepend": true }
   ]

  ^ ^ 
 /   \
B     C
 ^   ^
  \ /
   D

परियोजना संदर्भों के लिए चेतावनी

परियोजना संदर्भों में कुछ ट्रेड-ऑफ हैं जिनके बारे में आपको अवगत होना चाहिए।

टाइपस्क्रिप्ट के लिए बिल्ड मोड

tsc --build ( tsc -b संक्षेप में) चलाना निम्नलिखित कार्य करेगा:

सभी संदर्भित प्रोजेक्ट खोजें
पता लगाएँ कि क्या वे अप-टू-डेट हैं
पुरानी परियोजनाओं को सही क्रम में बनाएं

`tsc -b` कमांडलाइन

आप किसी भी संख्या में कॉन्फिग फाइल निर्दिष्ट कर सकते हैं:

 > tsc -b                                # Build the tsconfig.json in the current directory
 > tsc -b src                            # Build src/tsconfig.json
 > tsc -b foo/release.tsconfig.json bar  # Build foo/release.tsconfig.json and bar/tsconfig.json

tsc -b लिए विशिष्ट कुछ झंडे भी हैं:

--verbose : क्या हो रहा है यह समझाने के लिए वर्बोज़ लॉगिंग को प्रिंट करता है (किसी अन्य ध्वज के साथ जोड़ा जा सकता है)
--dry : दिखाता है कि क्या किया जाएगा लेकिन वास्तव में कुछ भी नहीं बनाता है
--clean : निर्दिष्ट परियोजनाओं के आउटपुट को हटाता है ( --dry के साथ जोड़ा जा सकता है)
--force : ऐसा व्यवहार करें जैसे कि सभी प्रोजेक्ट पुराने हैं
--watch : वॉच मोड ( --verbose को छोड़कर किसी भी ध्वज के साथ जोड़ा नहीं जा सकता है)

चेतावनियां

एमएसबिल्ड

    <TypeScriptBuildMode>true</TypeScriptBuildMode>

दिशा निर्देश

समग्र संरचना

सापेक्ष मॉड्यूल के लिए संरचना

आउटफाइल के लिए संरचना

monorepos . के लिए संरचना

RyanCavanaugh 26 जून 2018

👍26 ❤15

#25164 . पर भी प्रतिक्रिया की तलाश में

RyanCavanaugh 26 जून 2018

@RyanCavanaugh बहुत अच्छा लेखन, और उत्कृष्ट विशेषता, इसे आज़माना वाकई अच्छा होगा, esp। कॉन्फ़िगरेशन फ़ाइल संदर्भों के साथ उप-परियोजनाओं में हमारी बड़ी परियोजना को व्यवस्थित करने के बाद मैंने दिन बिताए।

मेरे पास कुछ नोट हैं:

एक मोनोरेपो क्या है? इस उपयोग-मामले का थोड़ा और वर्णन करना अच्छा होगा।
ज्यादातर मामलों में (विशेष रूप से बड़ी परियोजनाओं के लिए सच), निर्माण के दौरान कई अतिरिक्त कलाकृतियां उत्पन्न होती हैं। हमारे मामले में ये सीएसएस, एचटीएमएल, इमेज फाइल आदि हैं, गल्प के माध्यम से। मुझे आश्चर्य है कि इस तरह के निर्माण उपकरणों का उपयोग चीजों को करने के इस नए तरीके को कैसे अपनाएगा। कहो, मैं न केवल *.ts फाइलों पर, बल्कि हमारी सभी अन्य फाइलों (शैलियों, मार्कअप आदि) पर घड़ी चलाना चाहता हूं। उसको कैसे करे? समानांतर में gulp watch और tsc -b -w चलाने की आवश्यकता है?

vvs 26 जून 2018

@vvs a monorepo आमतौर पर रश या लर्न जैसे टूल द्वारा प्रबंधित NPM पैकेजों का एक संग्रह है

यदि आप गल्प का उपयोग कर रहे हैं, तो आप एक लोडर का उपयोग करना चाहेंगे जो सर्वोत्तम अनुभव प्राप्त करने के लिए प्रोजेक्ट संदर्भों को मूल रूप से समझता हो। @rbuckton ने यहां कुछ काम किया है क्योंकि हमारे पास कुछ डेवलपर्स आंतरिक रूप से एक गल्पफाइल का उपयोग कर रहे हैं; हो सकता है कि वह इस बात का वजन कर सके कि वहां कौन से अच्छे पैटर्न दिखते हैं

RyanCavanaugh 26 जून 2018

@RyanCavanaugh यह अच्छा लग रहा है। मुझे लर्न मार्गदर्शन में बहुत दिलचस्पी है :)

EisenbergEffect 27 जून 2018

👍1

@RyanCavanaugh यह बहुत अच्छा लग रहा है, मैं वर्तमान में इसे अपने लर्न मोनोरेपो के साथ आज़माने पर काम कर रहा हूँ।

आपके लेखन में मेरे लिए एकमात्र अस्पष्ट बात prepend विकल्प थी। मुझे यह नहीं पता था कि यह किस समस्या का समाधान कर रहा है, आप किस स्थिति में इसका उपयोग करना चाहेंगे, और यदि आप इसका उपयोग नहीं करते हैं तो क्या होगा।

yortus 27 जून 2018

👍1

यह कमाल का है! मैं ts-loader और संबंधित परियोजनाओं पर काम करता हूं। क्या टाइपस्क्रिप्ट के LanguageServiceHost / WatchHost उपयोग करने वाली परियोजनाओं में इसका समर्थन करने के लिए परिवर्तन आवश्यक होने की संभावना है?

(मेरे मतलब के उदाहरण के लिए https://github.com/TypeStrong/ts-loader/blob/master/src/servicesHost.ts देखें।)

यदि हां, तो सभी मार्गदर्शन / जनसंपर्क कृतज्ञतापूर्वक प्राप्त होते हैं! वास्तव में यदि आप चाहते हैं कि वेबपैक की दुनिया में इसका परीक्षण किया जाए तो मुझे इसका समर्थन करने वाले ts-loader के एक संस्करण को आगे बढ़ाने में मदद करने में खुशी होगी।

बेशक अगर यह "बस काम करता है" तो यह और भी बेहतर है: मुस्कान:

महान काम!

johnnyreilly 27 जून 2018

👍3

@yortus @EisenbergEffect मैंने https://github.com/RyanCavanaugh/learn-a पर एक नमूना लर्न रेपो स्थापित किया है जिसमें एक README है जो मैंने इसे काम करने के लिए उठाए गए कदमों को रेखांकित किया है।

RyanCavanaugh 27 जून 2018

🎉3

अगर मैं सही ढंग से समझ रहा हूं, तो tsc -b X कुछ भी नहीं करेगा यदि सब कुछ (एक्स और इसकी सभी निर्भरताएं और ट्रांजिटिव निर्भरता) अद्यतित है? आश्चर्य है कि क्या ऐसा कुछ है जो हम बिना संदर्भ के व्यक्तिगत परियोजनाओं के लिए -b ध्वज के बिना भी प्राप्त कर सकते हैं? (उस मामले में ऋण निर्भरता, निश्चित रूप से)

spion 28 जून 2018

👍1

यह बहुत अच्छा है। मैं एक Lerna का उपयोग इस तरह की कॉन्फ़िगरेशन (फ़ंक्शन द्वारा मोनो रेपो को अलग करने के लिए) का उपयोग करने की ओर करता हूं। मुझे लगता है कि यह भी काम करेगा।

{
"लर्न": "2.11.0",
"पैकेज": [
"पैकेज/घटक/ ","पैकेज/पुस्तकालय/ ",
"पैकेज/ढांचे/ ","पैकेज/अनुप्रयोग/ ",
"पैकेज/उपकरण/*"
],
"संस्करण": "0.0.0"
}

claudeduguay 28 जून 2018

तो यह typescript@next ?

मैं अपने यार्न वर्कस्पेस रेपो के साथ इसका परीक्षण करूंगा। हमें कुछ मॉड्यूल के लिए nohoist का उपयोग करना होगा जो अभी तक कार्यक्षेत्र का समर्थन नहीं करते हैं, इसलिए यह देखना अच्छा होगा कि यह इसे कैसे संभालता है।

timfish 28 जून 2018

@RyanCavanaugh मैंने आज रात टेस्ट रन के लिए रेपो लिया। मेरे पास कुछ मुद्दों की रिपोर्ट करने के लिए मैंने रेपो पर एक मुद्दा खोला। इसे एक साथ रखने के लिए फिर से धन्यवाद। मैं जल्द ही इसका उपयोग करने के लिए उत्सुक हूं।

EisenbergEffect 28 जून 2018

बहुत दिलचस्प! वर्तमान में मेरी कंपनी में, हम एक ही समय में कई परियोजनाओं के वॉच मोड का समर्थन करने के लिए एमटीएससी नामक अपने स्वयं के टूल का उपयोग करते हैं। हमारे पास लगभग 5 परियोजनाएं हैं जिन्हें एक ही रेपो में संकलित और देखने की आवश्यकता है।

परियोजनाओं की तरह अलग विन्यास है; ECMA लक्ष्यीकरण (es5, es6), प्रकार (नोड, जेस्ट, DOM आदि), एमिट (कुछ वेबपैक का उपयोग करते हैं और कुछ स्वयं को js के लिए संकलित करते हैं)। वे सभी एक चीज साझा करते हैं, और वह है tslint प्लगइन , बाकी सभी अलग हो सकते हैं। मेरा टूल प्रोजेक्ट संकलन के बाद tslint भी चलाता है (प्रति प्रोजेक्ट और अगर कोई प्रोजेक्ट tslint से पहले पुन: संकलित हो जाता है तो बंद हो जाता है)।

वर्तमान प्रस्ताव के साथ मेरी मुख्य चिंता यह है कि आप यह नहीं कह सकते कि कौन सी परियोजनाएँ किन संसाधनों को साझा करती हैं। हमारे पास एक सर्वर और क्लाइंट प्रोजेक्ट है, जो दोनों एक विशेष उपयोगिता फ़ोल्डर का उपयोग करते हैं, लेकिन हम दो बार संकलन त्रुटियों को नहीं देखना चाहते हैं। लेकिन यह एक फिल्टर के साथ तय किया जा सकता है, इसलिए यह कोई बड़ी बात नहीं है :)

guidsdo 28 जून 2018

मैंने अपने लर्न मोनोरेपो के साथ नया --build मोड आज़माया है, जिसमें वर्तमान में 17 अन्योन्याश्रित पैकेज शामिल हैं। सब कुछ काम करने में थोड़ा समय लगा, लेकिन अब यह सब काम करता है, और वृद्धिशील रूप से निर्माण करने में सक्षम होना हमारे लिए एक बड़ा सुधार है।

मुझे कुछ मुद्दों का सामना करना पड़ा जिनका मैं नीचे वर्णन करता हूं। मुझे आशा है कि यह TS टीम के लिए उपयोगी प्रतिक्रिया है और दूसरों को उनकी परियोजनाओं के लिए काम करने वाला --build मोड प्राप्त करने में मदद कर सकता है।

`tsc --build` मोड के लिए प्रतिक्रिया

1. नकली "\पुराना है क्योंकि आउटपुट फ़ाइल '2.map' मौजूद नहीं है"

मुझे यह संदेश हर बिल्ड पर हर पैकेज के लिए मिला है, इसलिए कुछ भी नहीं बदले जाने पर भी हर बिल्ड एक पूर्ण री-बिल्ड बन गया। मैंने देखा कि @RyanCavanaugh ने इसे #25281 में पहले ही ठीक कर लिया है, इसलिए यदि आप 20180628 या बाद में रात में अपडेट करते हैं तो यह अब कोई समस्या नहीं है। निम्नलिखित मुद्दे मानते हैं कि आपने कम से कम 20180628 रात में अपडेट किया है।

2. "\इसकी निर्भरता से .d.ts फ़ाइलों के साथ अद्यतित है" जब यह नहीं है

संपादित करें: #25337 पर सूचना दी।

इस समस्या को पुन: उत्पन्न करने के लिए, @RyanCavanaugh के learn-a नमूना रेपो को उनके निर्देशों के अनुसार सेट tsc -b packages --verbose चलाएं। अब लाइन 1 को pkg1/src/index.ts से import {} from "./foo"; में बदलें और इसे सेव करें। tsc -b packages --verbose फिर से चलाएँ। pkg2 लिए बिल्ड को छोड़ दिया गया है, भले ही pkg1 को इस तरह से बदल दिया गया हो जो pkg2 के स्रोत को तोड़ देता है। अब आप pkg2/src/index.ts में एक लाल रंग की झिलमिलाहट देख सकते हैं। tsc -b packages --force साथ फिर से निर्माण करें और बिल्ड त्रुटि दिखाई गई है। निम्नलिखित मुद्दे इसके समाधान के लिए --force साथ निर्माण मान लेते हैं।

3. जेनरेट की गई `.d.ts` फाइलें 'डुप्लिकेट आइडेंटिफायर' के कारण डाउनस्ट्रीम पैकेज में त्रुटियां पैदा करती हैं

संपादित करें: #25338 पर सूचना दी।

इस समस्या को पुन: उत्पन्न करने के लिए, @RyanCavanaugh के learn-a नमूना रेपो को उनके निर्देशों के अनुसार सेट lerna add @types/node चलाएँ। यह पुष्टि करने के लिए tsc -b packages --force चलाएँ कि यह अभी भी ठीक है। अब निम्नलिखित कोड को pkg1/src/index.ts :

// CASE1 - no build errors in pkg1, but 'duplicate identifier' build errors in pkg2
// import {parse} from 'url';
// export const bar = () => parse('bar');

// CASE2 - no build errors in pkg1 or in downstream packages
// import {parse, UrlWithStringQuery} from 'url';
// export const bar = (): UrlWithStringQuery => parse('bar');

// CASE3 - no build errors in pkg1 or in downstream packages
// export declare const bar: () => import("url").UrlWithStringQuery;

// CASE4 - no build errors in pkg1, but 'duplicate identifier' build errors in pkg2
// import {parse} from 'url';
// type UrlWithStringQuery = import("url").UrlWithStringQuery;
// export const bar = (): UrlWithStringQuery => parse('bar');

एक बार में एक केस को अनकम्मेंट करें और tsc -b packages --force चलाएं। केस 1 और 4 के कारण pkg2 में बिल्ड एरर की बाढ़ आ जाती है। मामलों 2 और 3 के साथ, कोई बिल्ड त्रुटियाँ नहीं हैं। मामलों 1 और 4 के साथ महत्वपूर्ण अंतर उत्पन्न pkg1/lib/index.d.ts में पहली पंक्ति प्रतीत होता है:

/// <reference path="../node_modules/@types/node/index.d.ts" />

केस 2 और 3 इस लाइन को उत्पन्न नहीं करते हैं। जब pkg2 1 और 4 के मामले में बनाया जाता है, तो इसमें अलग-अलग रास्तों पर @types/node घोषणाओं की दो समान प्रतियां शामिल होती हैं, और इससे 'डुप्लिकेट पहचानकर्ता' त्रुटियां होती हैं।

शायद यह डिज़ाइन द्वारा है क्योंकि केस 2 और 3 काम करते हैं। हालांकि यह काफी भ्रमित करने वाला लगता है। इन 4 मामलों में से किसी के लिए pkg1 में कोई बिल्ड त्रुटि या चेतावनियां नहीं हैं, लेकिन डाउनस्ट्रीम बिल्ड व्यवहार निर्यात की गई घोषणाओं की सटीक शैली के प्रति बहुत संवेदनशील है। मुझे लगता है कि या तो (ए) pkg1 मामलों 1 और 4 के लिए त्रुटि होनी चाहिए, या (बी) सभी चार मामलों में समान डाउनस्ट्रीम बिल्ड व्यवहार होना चाहिए, या (सी) टीएस टीम से कुछ स्पष्ट मार्गदर्शन होना चाहिए इस समस्या से बचने के लिए डिक्लेरेशन कैसे लिखें।

4. यार्न कार्यक्षेत्रों का उपयोग करते समय उत्पन्न `.d.ts` फ़ाइलों में `import` प्रकार की समस्याएं

हमारे 17 पैकेज मोनोरेपो के साथ काम करने वाले बिल्ड मोड को प्राप्त करने का प्रयास करते समय, मैंने उत्पन्न .d.ts फाइलों में import प्रकारों में सापेक्ष पथों के कारण कई बिल्ड त्रुटियों के माध्यम से काम किया। मैंने अंत में काम किया कि मॉड्यूल उत्थापन से संबंधित समस्या। यही है, यार्न कार्यक्षेत्र का उपयोग करते समय, सभी स्थापित मॉड्यूल मोनोरेपो-रूट node_modules निर्देशिका में फहराए जाते हैं, जिसमें मोनोरेपो में सभी पैकेजों के लिए सिम्लिंक शामिल हैं। मैंने packages संपत्ति का उपयोग करने के लिए मोनोरेपो को बदल दिया lerna.json , जिसके कारण lerna अपने स्वयं के गैर-उत्थापन बूटस्ट्रैपिंग एल्गोरिदम का उपयोग करता है, और इससे समस्या हल हो जाती है। वैसे भी यह एक बेहतर/सुरक्षित दृष्टिकोण है, हालांकि धीमा है।

मुझे यकीन नहीं है कि टीएस मॉड्यूल-होस्टेड सेटअप का समर्थन करना चाहता है, इसलिए मैंने जिन समस्याओं का सामना किया है, उनके लिए मैंने एक रेप्रो विकसित नहीं किया है, लेकिन अगर दिलचस्पी है तो मैं एक बनाने की कोशिश कर सकता हूं। मुझे लगता है कि समस्या यह हो सकती है कि कुछ बिल्ड शीर्ष-स्तरीय packages निर्देशिका (tsconfig सेटिंग्स के अनुसार) और शीर्ष-स्तर node_modules निर्देशिका ( import अनुसार) दोनों के माध्यम से समान प्रकार प्राप्त कर रहे हैं। .d.ts फाइलों में)। यह कभी-कभी संरचनात्मक टाइपिंग के कारण काम करता है, लेकिन निर्यात किए गए अद्वितीय प्रतीकों जैसी चीज़ों के लिए विफल रहता है।

5. दोहराव विन्यास

लर्न का उपयोग करने के लिए एक मोनोरेपो स्थापित करने के लिए मूल रूप से केवल "packages": ["packages/*"] जैसे कुछ डालने की आवश्यकता होती है lerna.json । Lerna ग्लोबस्टार का विस्तार करके सटीक पैकेज सूची तैयार करता है, और फिर प्रत्येक पैकेज के package.json में घोषित निर्भरता को देखकर सटीक निर्भरता ग्राफ तैयार करता है। आप अपनी मर्जी से पैकेज और निर्भरता को जोड़ और हटा सकते हैं, और lerna इसके कॉन्फिगर को छूने की आवश्यकता के बिना जारी रहता है।

टाइपस्क्रिप्ट --build मोड में थोड़ा और समारोह शामिल है। ग्लोब पैटर्न को पहचाना नहीं जाता है, इसलिए सभी पैकेजों को स्पष्ट रूप से सूचीबद्ध और बनाए रखा जाना चाहिए (उदाहरण के लिए packages/tsconfig.json ) @RyanCavanaugh के learn-a नमूना रेपो में। बिल्ड मोड package.json निर्भरताओं को नहीं देखता है, इसलिए प्रत्येक पैकेज को अन्य पैकेजों की सूची को बनाए रखना चाहिए जो इसकी package.json फ़ाइल ( "dependencies" तहत) और साथ ही दोनों पर निर्भर करता है। यह tsconfig.json फ़ाइल है ( "references" तहत)।

यह एक छोटी सी असुविधा है, लेकिन मैं इसे यहां शामिल करता हूं क्योंकि मुझे lerna's दृष्टिकोण की तुलना में रिगमारोल ध्यान देने योग्य लगा।

6. `tsc` वैश्विक मॉड्यूल संवर्द्धन के साथ क्रैश

संपादित करें: #25339 पर सूचना दी।

इस समस्या को पुन: उत्पन्न करने के लिए, @RyanCavanaugh के learn-a नमूना रेपो को उनके निर्देशों के अनुसार सेट lerna add @types/multer जोड़ने के लिए multer तीनों संकुल को typings। यह पुष्टि करने के लिए tsc -b packages --force चलाएँ कि यह अभी भी ठीक है। अब निम्न पंक्ति को pkg1/src/index.ts :

export {Options} from 'multer';

tsc -b packages --force फिर से चलाएँ। उल्लंघन किए गए दावे के कारण संकलक दुर्घटनाग्रस्त हो जाता है। मैंने संक्षेप में स्टैक ट्रेस और अभिकथन को देखा, और ऐसा लगता है कि यह Express नेमस्पेस के वैश्विक संवर्द्धन के साथ कुछ करना है।

yortus 29 जून 2018

👍8

प्रतिक्रिया के लिए धन्यवाद @yortus । भरोसा करें इसकी सराहना करें। 3 के लिए, मुझे लगता है कि यह https://github.com/Microsoft/TypeScript/issues/25278 है।

4 के लिए, मैं एक अवधारणा के रूप में मॉड्यूल उत्थापन से परिचित नहीं हूँ। क्या आप विस्तृत कर सकते हैं, और/या एक रेप्रो साझा कर सकते हैं?

mhegazy 29 जून 2018

@mhegazy कई जो लर्न और यार्न का उपयोग करते हैं वे कार्यक्षेत्रों (स्वयं सहित) का उपयोग करते हैं। अधिक जानकारी यहाँ: https://yarnpkg.com/lang/en/docs/workspaces/

मैं वर्तमान में यार्न वर्कस्पेस, लर्न, विस्तारित tsconfigs का उपयोग कर रहा हूं जहां आधार tsconfig paths घोषित करता है जो सभी पैकेजों के लिए होस्टेड मॉड्यूल के साथ साझा किया जाता है root/node_modules । जब मैं yarn और monorepo सुनता हूं, तो मुझे लगता है कि workspaces क्योंकि यह सुविधा का बहुत ही उद्देश्य है - उपयोग को आसान बनाने और दोहराव को कम करने के लिए। मैं उम्मीद कर रहा था कि यह परिवर्तन मेरे आधार tsconfig में घोषित मेरे लंबे/दर्दनाक paths को सरल रूप से हटा देगा।

यहाँ हमारे मूल monorepo tsconfig का एक नमूना है (यदि यह किसी भी मदद का है):

{
  "extends": "./packages/build/tsconfig.base.json",
  "compilerOptions": {
    "baseUrl": "./packages",
    "paths": {
      "@alienfast/build/*": ["./build/src/*"],
      "@alienfast/common-node/*": ["./common-node/src/*"],
      "@alienfast/common/*": ["./common/src/*"],
      "@alienfast/concepts/*": ["./concepts/src/*"],
      "@alienfast/faas/*": ["./faas/src/*"],
      "@alienfast/math/*": ["./math/src/*"],
      "@alienfast/notifications/*": ["./notifications/src/*"],
      "@alienfast/ui/*": ["./ui/src/*"],
      "@alienfast/build": ["./build/src"],
      "@alienfast/common-node": ["./common-node/src"],
      "@alienfast/common": ["./common/src"],
      "@alienfast/concepts": ["./concepts/src"],
      "@alienfast/faas": ["./faas/src"],
      "@alienfast/math": ["./math/src"],
      "@alienfast/notifications": ["./notifications/src"],
      "@alienfast/ui": ["./ui/src"],
    }
  },
  "include": ["./typings/**/*", "./packages/*/src/**/*"],
  "exclude": ["node_modules", "./packages/*/node_modules"]
}

मैं एक नमूने के लिए फोर्किंग पर एक शॉट लूंगा:
https://github.com/RyanCavanaugh/learn-a

rosskevin 29 जून 2018

यार्न कार्यक्षेत्रों के साथ @RyanCavanaugh के रेपो में विलय के लिए एक गैर-विलय पीआर यहां दिया गया है:
https://github.com/RyanCavanaugh/learn-a/pull/3/files

rosskevin 29 जून 2018

हमने जुपिटरलैब में लर्न और यार्न के साथ मॉड्यूल उत्थापन का भी उपयोग किया। यह हमें मूल रूप से हमारे सभी पैकेजों के बीच हमारी स्थापित निर्भरता को साझा करने की अनुमति देता है, इसलिए वे रूट प्रोजेक्ट पर फाइल सिस्टम में केवल एक बार मौजूद होते हैं।

मैं कार्यक्षेत्रों को सभी पैकेजों के बीच link कमांड का उपयोग करने की तुलना में थोड़ा साफ होने के रूप में समझता हूं ताकि वे एक-दूसरे तक पहुंच सकें (या कम से कम उनकी निर्भरता तक पहुंच सकें)।

saulshanabrook 29 जून 2018

ऊपर के रूप में, मॉड्यूल होस्टिंग सभी निर्भरताओं को रूट node_modules निर्देशिका में ले जाता है। यह इस तथ्य का लाभ उठाता है कि नोड मॉड्यूल रिज़ॉल्यूशन हमेशा डायरेक्टरी ट्री को पार करेगा और सभी node_modules निर्देशिकाओं के माध्यम से तब तक खोज करेगा जब तक कि उसे आवश्यक मॉड्यूल नहीं मिल जाता। आपके मोनोरेपो में अलग-अलग मॉड्यूल तब इस रूट node_modules में सिमलिंक हो जाते हैं और सब कुछ बस काम करता है। यार्न ब्लॉग पोस्ट शायद इसे मुझसे बेहतर तरीके से समझाता है।

उत्थापन होने की गारंटी नहीं है। यदि आपके पास एक ही पैकेज के बेमेल संस्करण हैं तो उन्हें फहराया नहीं जाएगा। साथ ही, कई मौजूदा उपकरण उत्थापन का समर्थन नहीं करते हैं क्योंकि वे अनुमान लगाते हैं कि node_modules कहां होगा या वे नोड मॉड्यूल रिज़ॉल्यूशन का सही ढंग से पालन नहीं करते हैं। इस वजह से एक nohoist सेटिंग है जो विशिष्ट मॉड्यूल या निर्भरता के लिए उत्थापन को अक्षम कर सकती है।

timfish 29 जून 2018

मैंने अपनी पिछली प्रतिक्रिया में छठा आइटम जोड़ा है। tsc वहां वर्णित परिदृश्य में क्रैश हो जाता है।

@mhegazy मुझे यकीन नहीं है कि आइटम 3 # 25278 से संबंधित है। #25278 अमान्य घोषणा उत्सर्जन का वर्णन करता है। मेरी जेनरेट की गई घोषणा फाइलें वाक्य-रचना और शब्दार्थ रूप से मान्य थीं, लेकिन डाउनस्ट्रीम परियोजनाओं को नोड टाइपिंग की दो प्रतियों के साथ बनाया गया, जिसके परिणामस्वरूप 'डुप्लिकेट आइडेंटिफायर' त्रुटियां हुईं।

yortus 30 जून 2018

ऊपर के रूप में, मॉड्यूल उत्थापन सभी निर्भरताओं को रूट नोड_मॉड्यूल निर्देशिका में ले जाता है। यह इस तथ्य का लाभ उठाता है कि नोड मॉड्यूल रिज़ॉल्यूशन हमेशा डायरेक्टरी ट्री को पार करेगा और सभी नोड_मॉड्यूल्स निर्देशिकाओं के माध्यम से खोज करेगा जब तक कि यह आवश्यक मॉड्यूल नहीं पाता।

बीटीडब्ल्यू इस मॉडल के लिए एक नकारात्मक पहलू है, कि यह "प्रेत निर्भरता" की ओर जाता है जहां एक परियोजना एक निर्भरता आयात कर सकती है जिसे स्पष्ट रूप से इसकी package.json फ़ाइल में घोषित नहीं किया गया था। जब आप अपनी लाइब्रेरी प्रकाशित करते हैं, तो यह परेशानी पैदा कर सकता है जैसे (1) निर्भरता का एक अलग संस्करण जो परीक्षण/अपेक्षित था, या (2) निर्भरता पूरी तरह से गायब है क्योंकि इसे एक असंबंधित परियोजना से फहराया गया था जो स्थापित नहीं है इस संदर्भ में। पीएनपीएम और रश दोनों के पास प्रेत निर्भरता से बचाने के लिए वास्तुशिल्प विकल्प हैं।

octogonz 1 जुल॰ 2018

👍2

मेरे पास tsc --build के बारे में एक सामान्य प्रश्न है: क्या टाइपस्क्रिप्ट कंपाइलर एक मोनोरेपो में परियोजनाओं के लिए निर्माण को व्यवस्थित करने की भूमिका निभाने की मांग कर रहा है? आम तौर पर टूलचेन में कार्यों की पूरी पाइपलाइन होने वाली होती है, जैसे सामान:

पूर्व प्रसंस्करण
स्थानीयकृत तार उत्पन्न करना
संपत्ति को जावास्क्रिप्ट में परिवर्तित करना (सीएसएस, चित्र, आदि)
संकलन (टाइप चेकिंग / ट्रांसपिलिंग)
.js फ़ाइलों को रोल अप करना (उदा. वेबपैक)
.d.ts फाइलों को रोल अप करना (जैसे एपीआई एक्सट्रैक्टर)
यूनिट परीक्षण और प्रलेखन पीढ़ी सहित पोस्ट प्रोसेसिंग

आम तौर पर एक सिस्टम जैसे कि गल्प या वेबपैक इस पाइपलाइन का प्रबंधन करता है, और कंपाइलर श्रृंखला के बीच में सिर्फ एक कदम है। कभी-कभी एक द्वितीयक टूल बिल्ड को दूसरे तरीके से भी चलाता है, जैसे Jest+ts-jest jest --watch ।

क्या tsc लक्ष्य इन चीजों को स्वयं प्रबंधित करना है? और यदि नहीं, तो निर्भरता ग्राफ को हल करने के लिए पारंपरिक निर्माण ऑर्केस्ट्रेटर के लिए कोई तरीका है, और उदाहरण के लिए बार-बार प्रत्येक प्रोजेक्ट फ़ोल्डर में सही क्रम में टीएससी का आह्वान करें (प्रीप्रोसेसिंग अपडेट होने के बाद)?

या, यदि डिज़ाइन एक ही पास में पूरे मोनोरेपो को संसाधित करना है (जबकि आज हम प्रत्येक प्रोजेक्ट को एक अलग NodeJs प्रक्रिया में बनाते हैं), मैं यह भी उत्सुक हूं कि अन्य निर्माण कार्य कैसे भाग लेंगे: उदाहरण के लिए, क्या हम वेबपैक चलाएंगे एक बार में सभी परियोजनाएं? (अतीत में जो स्मृति से बाहर हो गए थे।) क्या हम बहु-प्रक्रिया समरूपता का फायदा उठाने की क्षमता खो देंगे?

ये आलोचनाएँ BTW नहीं हैं। मैं सिर्फ बड़ी तस्वीर और इच्छित उपयोग को समझने की कोशिश कर रहा हूं।

octogonz 1 जुल॰ 2018

👍2

@pgonzal ठीक है, वास्तविक दुनिया मोनोरेपो बनाने के लिए कई गैर-tsc भाग हैं। हमारे लर्न मोनोरेपो के लिए मैंने निम्नलिखित दृष्टिकोण अपनाया:

मोनोरेपो में प्रत्येक पैकेज वैकल्पिक रूप से एक prebuild स्क्रिप्ट और/या एक postbuild स्क्रिप्ट को अपने package.json परिभाषित करता है। इनमें बिल्ड के गैर-tsc पहलू शामिल हैं।
मोनोरेपो के package.json , ये स्क्रिप्ट हैं:
"prebuild": "lerna run prebuild", "build": "tsc --build monorepo.tsconfig.json --verbose", "postbuild": "lerna run postbuild",
बस, इतना ही। मोनोरेपो स्तर पर yarn build चलाना प्रत्येक पैकेज के लिए prebuild स्क्रिप्ट चलाता है जो उन्हें परिभाषित करता है, फिर यह tsc --build चरण चलाता है, फिर यह सभी postbuild चलाता है स्क्रिप्ट (एनपीएम और यार्न दोनों में सम्मेलन द्वारा, npm run foo निष्पादित करना लगभग npm run prefoo && npm run foo && npm run postfoo जैसा ही है।)

yortus 1 जुल॰ 2018

आप jest --watch या webpack-dev-server कैसे संभालते हैं? उदाहरण के लिए जब कोई स्रोत फ़ाइल संशोधित की जाती है, तो क्या प्रीबिल्ड/पोस्टबिल्ड चरण फिर से चलते हैं?

octogonz 1 जुल॰ 2018

क्या इसका ts-node और संबंधित कार्यप्रवाहों पर कोई प्रभाव पड़ता है? हमारे कुछ सहायक ऐप्स टाइपस्क्रिप्ट से "सीधे" चलते हैं, जैसे "start": "ts-node ./src/app.ts" या "start:debug": "node -r ts-node/register --inspect-brk ./src/app.ts" ।

borekb 1 जुल॰ 2018

#25355 पर बिल्ड मोड के साथ एक और समस्या की सूचना दी।

yortus 2 जुल॰ 2018

अब तक की सभी अच्छी प्रतिक्रिया और जांच के लिए धन्यवाद। मैं वास्तव में उन सभी की सराहना करता हूं जिन्होंने चीजों को आजमाने और टायरों को लात मारने के लिए समय निकाला।

@yortus पुनः https://github.com/Microsoft/TypeScript/issues/3469#issuecomment -400439520

बढ़िया लेखन, इसे उपलब्ध कराने के लिए एक बार फिर धन्यवाद. आपके मुद्दे क्रम में -

फिक्स्ड
#25370 . पर पीआर अप
लॉग किए गए मुद्दे पर चर्चा करना - तुरंत स्पष्ट नहीं होता कि सही समाधान क्या है, लेकिन हम कुछ करेंगे
जांच (नीचे)
लॉग किया गया #25376
तकनीकी रूप से --build AFAICT से असंबंधित। यह एक नया अभिकथन है जिसे हमने हाल ही में जोड़ा है; नाथन की जांच

learn-a रेपो पर पीआर के लिए @rosskevin ! मैं इसे एक शाखा में विलय करने जा रहा हूं ताकि हम तुलना और तुलना बेहतर तरीके से कर सकें।

@pgonzal पुनः https://github.com/Microsoft/TypeScript/issues/3469#issuecomment -401577442

मेरे पास tsc --build के बारे में एक सामान्य प्रश्न है: क्या टाइपस्क्रिप्ट कंपाइलर एक मोनोरेपो में परियोजनाओं के निर्माण के लिए ऑर्केस्ट्रेटिंग की भूमिका निभाने की मांग कर रहा है?

महान प्रश्न; मैं इसका बहुत स्पष्ट उत्तर देना चाहता हूं: निश्चित रूप से नहीं ।

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

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

@borekb पुनः https://github.com/Microsoft/TypeScript/issues/3469#issuecomment -401593804

क्या इसका ts-नोड और संबंधित कार्यप्रवाहों पर कोई प्रभाव पड़ता है? हमारे कुछ सहायक ऐप्स टाइपस्क्रिप्ट से "सीधे" चलते हैं

एकल-फ़ाइल स्क्रिप्ट के लिए, जिसमें परोक्ष रूप से परियोजना संदर्भ नहीं हो सकते हैं, शून्य प्रभाव होता है।

@EisenbergEffect के पास क्रॉस-प्रोजेक्ट नाम बदलने और अन्य भाषा सेवा सुविधाओं के बारे में learn-a रेपो में कुछ प्रश्न थे। यहां बड़ा खुला प्रश्न यह है कि क्या हम इस सुविधा को 3.0 के लिए प्रयोग करने योग्य स्थिति में प्राप्त कर पाएंगे या नहीं। यदि ऐसा है, तो क्रॉस-प्रोजेक्ट का नाम बदलना "बस काम करेगा", इस चेतावनी के अधीन कि हमारे लिए सभी डाउनस्ट्रीम परियोजनाओं को निर्णायक रूप से ढूंढना और उन्हें अपडेट करना स्पष्ट रूप से असंभव है - यह अन्य की तलाश के लिए कुछ अनुमानों के आधार पर "सर्वश्रेष्ठ प्रयास" होगा। परियोजनाओं.

अगर हमें नहीं लगता कि क्रॉस-प्रोजेक्ट का नाम बदलना स्वीकार्य रूप से स्थिर है+3.0 के लिए पूर्ण है, तो हम केवल नाम बदलने के संचालन को ब्लॉक करेंगे, जब नामित प्रतीक किसी अन्य प्रोजेक्ट की .d.ts आउटपुट फ़ाइल में होगा - आपको ऐसा करने की अनुमति होगी बहुत भ्रमित करने वाला क्योंकि .d.ts फ़ाइल अपस्ट्रीम प्रोजेक्ट के बाद के निर्माण पर अपस्ट्रीम प्रोजेक्ट को संशोधित करने के बाद अपडेट हो जाएगी, जिसका अर्थ है कि यह आसानी से उन दिनों के बीच हो सकता है जब आप स्थानीय नाम बदलते हैं और जब आपको पता चलता है कि घोषणा कोड वास्तव में अद्यतन नहीं किया गया था।

गो टू डेफिनिशन जैसी सुविधाओं के लिए, ये आज वीएस कोड में काम कर रहे हैं और विजुअल स्टूडियो के भविष्य के संस्करणों में आउट-ऑफ-द-बॉक्स काम करेंगे। इन सभी सुविधाओं को सक्षम करने के लिए .d.ts.map फ़ाइलों की आवश्यकता होती है ( declarationMap चालू करें)। इसे प्रकाश में लाने के लिए कुछ प्रति-सुविधा कार्य हैं, इसलिए यदि आप देखते हैं कि कुछ अपेक्षित रूप से काम नहीं कर रहा है, तो एक बग लॉग करें क्योंकि हम कुछ मामलों को याद कर सकते हैं।

खुली समस्याएं जिन्हें मैं इस समय ट्रैक कर रहा हूं:

क्रॉस-प्रोजेक्ट का नाम बदलें - @ एंडी-एमएस लागू हो रहा है
फहराए गए मॉड्यूल सेटअप का विश्लेषण करने और उनके निहितार्थों को समझने की आवश्यकता है - मुझ पर
नमूना learn-a रेपो का एक संस्करण होना चाहिए जो yarn का उपयोग करता है, और दूसरा जो pnpm का उपयोग करता है, और दूसरा जो फहराए गए मोड में से एक का उपयोग करता है

प्रश्न खोलें

क्या हमें प्रोजेक्ट संदर्भों का अनुमान लगाने के लिए package.json s पढ़ने के लिए तर्क लागू करना चाहिए? लॉग किया गया #25376
क्या .d.ts.map उत्सर्जन composite परियोजनाओं के लिए परोक्ष रूप से होना चाहिए?

RyanCavanaugh 2 जुल॰ 2018

👍1

@RyanCavanaugh में जोड़ने के लिए

खुली समस्याएं जिन्हें मैं इस समय ट्रैक कर रहा हूं

हमने एलएस में पृष्ठभूमि में घोषणाओं को अद्यतन करने जैसी चीजों को संभालने के लिए वास्तविक परियोजना आउटपुट स्थान से अलग एक वृद्धिशील आउटपुट कैश होने का भी उल्लेख किया है (आज, जब तक आप निर्माण नहीं करते हैं, तब तक परिवर्तन संपादक में प्रोजेक्ट सीमाओं में प्रचारित नहीं होते हैं), stripInternal , और उत्परिवर्तित निर्माण प्रक्रियाएं (जहां हमारे निर्माण आउटपुट जगह में उत्परिवर्तित होते हैं और इसलिए एलएस संचालन के लिए उपयुक्त नहीं होते हैं)।

weswigham 2 जुल॰ 2018

👍3

गूंगा प्रश्न के लिए खेद है, चूंकि यह रोडमैप में चेक किया गया है, मैं इस सुविधा को कैसे सक्षम करूं?

zpdDG4gta8XKpMCd 9 जुल॰ 2018

@ एलेक्सी-बायकोव आप इसे टाइपस्क्रिप्ट @ अगले में उपयोग कर सकते हैं

मैंने अभी इसे हमारे यार्न वर्कस्पेस संचालित मोनोरेपो पर आजमाया है और यह अच्छी तरह से काम करता है।

एक बात मैंने नोटिस की थी कि tsc --build --watch त्रुटियों की रिपोर्ट करता है लेकिन फिर यह कहने के लिए कुछ भी आउटपुट नहीं करता है कि बिल्ड अब तय हो गया है। 2.9 में मानक tsc घड़ी मोड ने एक त्रुटि गणना देना शुरू कर दिया है और वहां एक शून्य देखना अच्छा है ताकि आप जान सकें कि भवन पूरा हो गया है।

timfish 10 जुल॰ 2018

मेरे पास *.d.ts से भरा एक फ़ोल्डर है और इसके अलावा मुझे इसके बारे में क्या करना चाहिए:

इसे एक प्रोजेक्ट बनाएं और इसका संदर्भ लें (कोशिश की, काम नहीं किया)
इसके लिए "शामिल करें" का प्रयोग करें

zpdDG4gta8XKpMCd 10 जुल॰ 2018

@timfish कि प्रतिक्रिया मेरे द्वारा सुनी गई किसी अन्य से मेल खाती है; लॉग किया गया #25562

@aleksey-bykov https://github.com/Microsoft/TypeScript/issues/3469#issuecomment -400439520 कुछ अवधारणाओं को समझाने में मदद करनी चाहिए

RyanCavanaugh 10 जुल॰ 2018

👍1

@RyanCavanaugh ऐसा लगता है कि प्रोजेक्ट रेफरिंग केवल कॉमनज और नोड मॉड्यूल रिज़ॉल्यूशन के लिए काम करता है, है ना?

आप में उदाहरण:

import * as p1 from "@ryancavanaugh/pkg1";
import * as p2 from "@ryancavanaugh/pkg2";

p1.fn();
p2.fn4();

@ryancavanaugh मॉड्यूल क्या है, क्या इसका इससे कोई लेना-देना है कि TS मॉड्यूल को कैसे हल करता है?
क्या यह उदाहरण एएमडी (क्लासिक मॉड्यूल रिज़ॉल्यूशन) के साथ काम करने वाला है?
परिभाषाओं को खोजने के लिए outFile आवश्यक है?
जहां d.ts फाइलें प्रोजेक्ट को संदर्भित करने के लिए उन्हें खोजने के लिए माना जाता है (क्या मैं अभी भी आउटडियर का उपयोग कर सकता हूं? क्या टीएस उन्हें वहां ढूंढेगा?)

मेरे पास 2 सरल परियोजनाएं हैं essentials और common और सामान्य चीजें अनिवार्य रूप से संकलित सामग्री को हल नहीं कर सकती हैं:

zpdDG4gta8XKpMCd 10 जुल॰ 2018

@ अलेक्सी-बायकोव

यह केवल एक स्कोप्ड मॉड्यूल नाम है, जिसे सामान्य नोड मॉड्यूल रिज़ॉल्यूशन एल्गोरिथम के तहत हल किया गया है
आप क्लासिक सहित किसी भी मॉड्यूल सिस्टम के साथ प्रोजेक्ट संदर्भों का उपयोग कर सकते हैं, लेकिन उदाहरण के नाम (स्कोप्ड मॉड्यूल) नोड के बाहर उपयोग करने के लिए बहुत अनुकूल नहीं हैं
नहीं
टाइपस्क्रिप्ट .d.ts फ़ाइलों को उस स्थान पर ढूंढता है जहां संदर्भित प्रोजेक्ट उन्हें बनाता है

यदि आपके पास नमूना रेपो या कुछ और है तो मैं निदान कर सकता हूं कि आपको वह त्रुटि क्यों मिल रही है

RyanCavanaugh 10 जुल॰ 2018

@RyanCavanaugh कृपया करें
उदाहरण.ज़िप

zpdDG4gta8XKpMCd 10 जुल॰ 2018

@RyanCavanaugh , ऐसा लगता है कि tsc --build --watch प्रारंभ में किसी भी फाइल को तब तक आउटपुट नहीं करता जब तक कि यह किसी स्रोत फ़ाइल में संशोधन न देखे।

timfish 11 जुल॰ 2018

धागा बहुत लंबा (समय और स्थान दोनों में); आइए लकी इश्यू नंबर 100 * 2^8 : #25600 . पर चर्चा करें

RyanCavanaugh 12 जुल॰ 2018

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

Typescript: "मध्यम आकार" परियोजनाओं का समर्थन करें

समस्या

प्रस्ताव

लक्ष्य

गैर-लक्ष्य

डिज़ाइन

यह काम किस प्रकार करता है

सीमाओं

वैकल्पिक अनुकूलन/सुधार

सबसे उपयोगी टिप्पणी

परियोजना संदर्भ

एक उदाहरण परियोजना

एक परियोजना संदर्भ क्या है?

composite

declarationMaps

prepend साथ outFile

परियोजना संदर्भों के लिए चेतावनी

टाइपस्क्रिप्ट के लिए बिल्ड मोड

tsc -b कमांडलाइन

चेतावनियां

एमएसबिल्ड

दिशा निर्देश

समग्र संरचना

सापेक्ष मॉड्यूल के लिए संरचना

आउटफाइल के लिए संरचना

monorepos . के लिए संरचना

सभी 147 टिप्पणियाँ

परियोजना संदर्भ: टाइपस्क्रिप्ट के लिए अंतर्निहित मापनीयता

परिचय

परिदृश्यों

सापेक्ष मॉड्यूल

उदाहरण

टिप्पणियों

मोनो-रेपो

उदाहरण

टिप्पणियों

आउटफाइल

उदाहरण

टिप्पणियों

परियोजना संदर्भ: अलगाव की एक नई इकाई

वाक्य - विन्यास

अर्थ विज्ञान

संदर्भित परियोजनाओं के प्रदर्शन के लिए प्रतिबंध

क्यों "declaration": true ?

rootDir क्यों बदलें?

कोई परिपत्र नहीं

tsbuild

करने के लिए

परियोजना संदर्भ

एक उदाहरण परियोजना

एक परियोजना संदर्भ क्या है?

composite

declarationMaps

prepend साथ outFile

परियोजना संदर्भों के लिए चेतावनी

टाइपस्क्रिप्ट के लिए बिल्ड मोड

tsc -b कमांडलाइन

चेतावनियां

एमएसबिल्ड

दिशा निर्देश

समग्र संरचना

सापेक्ष मॉड्यूल के लिए संरचना

आउटफाइल के लिए संरचना

monorepos . के लिए संरचना

tsc --build मोड के लिए प्रतिक्रिया

1. नकली "\पुराना है क्योंकि आउटपुट फ़ाइल '2.map' मौजूद नहीं है"

2. "\इसकी निर्भरता से .d.ts फ़ाइलों के साथ अद्यतित है" जब यह नहीं है

3. जेनरेट की गई .d.ts फाइलें 'डुप्लिकेट आइडेंटिफायर' के कारण डाउनस्ट्रीम पैकेज में त्रुटियां पैदा करती हैं

4. यार्न कार्यक्षेत्रों का उपयोग करते समय उत्पन्न .d.ts फ़ाइलों में import प्रकार की समस्याएं

5. दोहराव विन्यास

6. tsc वैश्विक मॉड्यूल संवर्द्धन के साथ क्रैश

संबंधित मुद्दों

`composite`

`declarationMaps`

`prepend` साथ `outFile`

`tsc -b` कमांडलाइन

क्यों `"declaration": true` ?

`rootDir` क्यों बदलें?

`tsbuild`

`composite`

`declarationMaps`

`prepend` साथ `outFile`

`tsc -b` कमांडलाइन

`tsc --build` मोड के लिए प्रतिक्रिया

3. जेनरेट की गई `.d.ts` फाइलें 'डुप्लिकेट आइडेंटिफायर' के कारण डाउनस्ट्रीम पैकेज में त्रुटियां पैदा करती हैं

4. यार्न कार्यक्षेत्रों का उपयोग करते समय उत्पन्न `.d.ts` फ़ाइलों में `import` प्रकार की समस्याएं

6. `tsc` वैश्विक मॉड्यूल संवर्द्धन के साथ क्रैश