[ऊपर दिए गए मुद्दे के विवरण में package.json में typescript.main पर ले जाया गया]

:+1:
मुझे लगता है कि http://nodejs.org/api/modules.html#modules_folders_as_modules Node.js का बहुत लोकप्रिय नियम है।

अन्य उदाहरण।

./test/index.ts

export function hello() { return "Hello, world"; }

./main.ts

import test = require("./test/");
console.log(test.hello()); // print "Hello, world"

[उपरोक्त समस्या विवरण में package.json में typescript.definition पर ले जाया गया]

एक उपाय यह होगा कि इसे बेहतर टूलींग से हल किया जाए। उदाहरण के import foo = require('foo') आपको कुछ स्थानीय नोड_मॉड्यूल+पैकेज.जेसन (फू एक टीएस प्रोजेक्ट है) या डीटी परिभाषा देखने के लिए एक संकेत देता है (फू एक जेएस प्रोजेक्ट है जहां पुस्तकालय लेखक टीएस डीईएफ़ को बनाए रखना नहीं चाहते हैं) .

एफवाईआई; मैं वास्तव में टीएसडी में इसके समान कुछ परीक्षण कर रहा हूं; एनपीएम (या बोवर) पैकेज में बंडल की गई परिभाषाओं को उजागर करने और लिंक करने का एक तरीका।

यह 0.6 के लिए मेरे देव संस्करण में है, और यह पैकेज में typescript definition जोड़कर काम करता है। दिन source भी होगा, या जो भी हो)।

{
    ...
    "main": "./index.js",
    "typescript": {
        "definition": "./foo.d.ts"
    }
    ...
},

फिर आप टीएसडी पर एक कमांड चला सकते हैं, वर्तमान में tsd link और यह सभी package.json फाइलों को node_modules (या बोवर या जो कुछ भी) में स्कैन करेगा, परिभाषित होने पर उस संपत्ति को ढूंढें और केंद्रीय tsd.d.ts में इसका संदर्भ जोड़ें आपके प्रोजेक्ट में

उदाहरण: यहां परिभाषित और यहां उपयोग करें

@Bartvds यह बहुत अच्छा है। npm संकुल में .d.ts रखने के लिए पहला कदम हो सकता है। मुझे "टाइपस्क्रिप्ट" में "परिभाषा" के साथ package.json संरचना पसंद है, यह बहुत अधिक व्यवस्थित है।

यदि टाइपस्क्रिप्ट कंपाइलर स्वयं इसे स्वचालित रूप से पढ़ सकता है, तो यह बहुत अच्छा होगा।

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

#207 पर भी चर्चा करें - 'सूचकांक' के अंतर्गत देख रहे हैं

:+1:

@chanon tsMain यदि हम डिक्लेरेशन जनरेशन का उपयोग करते हैं तो यह आवश्यक नहीं है।

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

:+1:

इस क्षेत्र में पहले से ही कोडप्लेक्स रेपो में कुछ काम हो चुका है, एक लीबरॉन द्वारा एक पुल अनुरोध और एक kayahr द्वारा ।

मैं उनमें से एक को नए भंडार में रखने और पोर्ट करने का अर्थ रहा हूं, लेकिन ऐसा लगता है कि संबंधित कोड को फिर से व्यवस्थित किया गया है।

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

समझदार लगता है। क्या यह क्लैशिंग प्रकार की निर्भरता वाले मॉड्यूल को कवर करेगा? मेरा मतलब है कि यदि कोई ऐप ए और बी आयात करता है, और बी भी ए पर निर्भर है। बाहरी घोषणाओं की दो प्रतियां होने पर डुप्लिकेट प्रकार की त्रुटियों में पड़ना आसान है।

ऐसा नहीं होना चाहिए, उन्हें अलग-अलग बाहरी मॉड्यूल नामों को हल करना चाहिए, इसलिए अलग-अलग मॉड्यूल में समान रूप से नामित स्वतंत्र प्रकार घोषित करें। संरचनात्मक प्रकार की जाँच के बाद विभिन्न मॉड्यूल को बिना मुद्दों के बातचीत करने की अनुमति देनी चाहिए।

यह मौजूदा tsd परिभाषाओं के साथ प्रमुख मुद्दों में से एक है जिसे यह हल करने का प्रयास कर रहा है, बाहरी परिवेश मॉड्यूल को परिभाषित करके उनके लिए समान नाम वाले पुस्तकालय के कई संस्करणों को संभालने का कोई तरीका नहीं है, लेकिन थोड़ा अलग प्रकार .

@joewood भी A . के विभिन्न संस्करणों के बीच परेशानी होगी

├── [email protected]
└── [email protected]
    └── [email protected]

उनके पास समान रूप से नामित, लेकिन थोड़े अलग प्रकार के पुस्तकालय के कई संस्करणों को संभालने का कोई तरीका नहीं है।

उसी के समाधान सुनने के इच्छुक हैं। टाइपस्क्रिप्ट में परिवेशी घोषणाओं के लिए global स्तर चर गुंजाइश है

भले ही संस्करण मेल खाते हों, फिलहाल मुझे दो अलग-अलग मुद्दों के साथ समस्याएं दिखाई देती हैं, लेकिन परिवेश घोषणा फाइलों से मेल खाने से डुप्लिकेट प्रतीक त्रुटियां होती हैं। स्थानीय रूप से परिभाषित /// reference निर्देश को किसी एक फ़ाइल में वापस हल करने की आवश्यकता है। या तो वह, या प्रकार की पहचान में पथ शामिल करने की आवश्यकता है और संरचनात्मक टाइपिंग संस्करण बेमेल आदि का ख्याल रखेगी।

@joewood हाँ, मुझे आशा है कि require को बदलकर, जहाँ भी संभव हो /// reference से बचने के लिए, सही परिभाषाओं को लोड करने के लिए अधिकांश मामलों में तय किया जाएगा। बाहरी मॉड्यूल को परिवेश घोषणाओं के बजाय उनके पूर्ण पथ से पहचाना जाएगा, इसलिए विभिन्न पथों और विभिन्न संस्करणों से एक ही नाम के एकाधिक लोड करना संभव होना चाहिए।

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

:+1:

:+1: धन्यवाद @ Nemo157 और चर्चा के लिए सभी।

मैंने package.json परिवर्धन को मर्ज करने के लिए टॉप इश्यू टेक्स्ट को अपडेट किया है और @ Nemo157 के प्रस्ताव से लिंक किया है।

:+1:

मैंने यह दिखाने के लिए मॉड्यूल का एक उदाहरण सेट बनाने के साथ-साथ अपने प्रस्ताव का प्रारंभिक कार्यान्वयन किया है कि मॉड्यूल बनाने के सभी अलग-अलग तरीके काम करेंगे। विभिन्न उप-मॉड्यूल में एक ही पुस्तकालय के विभिन्न संस्करणों का उपयोग करना शामिल है।

:+1:

index.ts के साथ मॉड्यूल के रूप में फ़ोल्डर: +1:

:+1:

:+1:

:+1:

:+1:

:+1: :+1: :+1:

:+1: :+1: :+1: :+1:

हमारे रडार पर इसे वापस टक्कर देने के लिए टिप्पणी करना।

मुझे @Bartvds के सुझाव से अच्छी सफलता मिली है:

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

तो निश्चित रूप से typescript में package.json का समर्थन करने पर विचार करें क्योंकि इस तरह समुदाय चला गया है।

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

• नोड_मॉड्यूल्स से सीधे आयात करें, जो गलत दिखता है: import Foo = require("node_modules/mymodule/Foo");
• घोषणा फ़ाइलों को उत्पन्न करने के लिए tsc प्राप्त करें और फिर मैन्युअल रूप से बनाए रखा मॉड्यूल घोषणा फ़ाइल का उपयोग करके उन्हें एक साथ सिलाई करें जो स्ट्रिंग मॉड्यूल नामों पर स्विच करता है

क्या टीएससी आयात घोषणाओं में बाहरी मॉड्यूल नाम की जांच कर सकता है और फिर पथ संकल्प के दौरान भी node_modules उसी तरह लागू होता है जैसे नोड.जेएस रनटाइम करता है? एक कंपाइलर विकल्प इसे चालू या बंद भी कर सकता है।

:+1: :+1: :+1:

टीएससी आयात घोषणाओं में बाहरी मॉड्यूल नाम की जांच कर सकता है और फिर पथ संकल्प के दौरान भी नोड_मॉड्यूल्स को उसी तरह लागू करता है जैसे कि नोड.जेएस रनटाइम करता है

इसे इस तरह का होना चाहिए है। उक्त नाम वाली फ़ाइल को खोजने के लिए निर्देशिका ट्री को देखने का वर्तमान तरीका JS निष्पादन संदर्भों से कोई समानता नहीं रखता है।

यह कुछ समय से मेरी सूची में है। अगली रिलीज में इसे प्राप्त करने का प्रयास करेंगे।

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

समाधान (हमारे लिए सबसे खराब से हमारे लिए सबसे अच्छे के क्रम में):

1. node_modules . में हार्ड-कोडेड लुकअप के माध्यम से शीर्ष-स्तरीय बाहरी मॉड्यूल नामों का समाधान
2. शीर्ष-स्तरीय बाहरी मॉड्यूल नामों के समाधान पर कोई नियंत्रण नहीं
3. node_modules निर्देशिका में शीर्ष-स्तरीय बाहरी मॉड्यूल नामों के वैकल्पिक रिज़ॉल्यूशन को नियंत्रित करने के लिए एक कंपाइलर ध्वज
4. दिए गए पथ (पथों) में शीर्ष-स्तरीय बाहरी मॉड्यूल नामों के वैकल्पिक रिज़ॉल्यूशन को नियंत्रित करने के लिए एक कंपाइलर "मॉड्यूल खोज पथ" पैरामीटर
5. एक कंपाइलर "मॉड्यूल रिज़ॉल्वर" पैरामीटर एक जेएस प्लगइन के साथ कंपाइलर प्रदान करने के लिए जो सभी (न केवल शीर्ष-स्तर) बाहरी मॉड्यूल नामों को हल करेगा
6. भाषा सेवाओं में उपयुक्त हुक जैसे कि बाहरी मॉड्यूल नाम संकल्प नियंत्रणीय है

विकल्प 1 भयानक है, मैं इसके बजाय विकल्प 2 पसंद करूंगा।

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

मुझे खुशी होगी अगर विकल्प 4 लागू किया गया था, अगर विकल्प 6 लागू किया गया था और विकल्प 4 और विकल्प 6 दोनों को लागू किया गया था, तो खुशी होगी।

आपके मॉड्यूल खोज रूट के लिए --basePath के बारे में, सभी मॉड्यूल आयात उस पथ के सापेक्ष देखे जाएंगे। यह केवल एएमडी के लिए लागू होता है।

मुझे लगता है कि नोड मुद्दा बहुत आसान है, हमें बस इसे लागू करने की जरूरत है :)

ध्यान दें कि हमें वास्तव में बहुत पहले @ Nemo157 से एक कार्यान्वयन (और परीक्षण) मिला था https://github.com/Microsoft/TypeScript/issues/247#issuecomment -57422329

@ मार्क-ब्यूर और @mhegazy से सहमत हैं, विकल्प 4 एक खोज पथ एक साधारण फिक्स होना चाहिए। भाषा सेवा में एक अधिक विस्तृत समाधान (विकल्प 6) निश्चित रूप से लंबी अवधि की आवश्यकता है।

_वर्थ जोड़ने_: यह अकेले टाइपस्क्रिप्ट पुन: उपयोग समस्या को npm में ठीक नहीं करेगा क्योंकि सामान्य प्रकार के संदर्भों के लिए डुप्लिकेट प्रतीक समस्या #1125 है। हमें वास्तव में बचने की जरूरत है ///.tsconfig फाइलों का उपयोग करके और पैकेजों को एक बाहरी टाइप किए गए मॉड्यूल में बंडल करके इसे ठीक से प्राप्त करें जैसा कि #17 में सुझाया गया है

टाइपस्क्रिप्ट कंपाइलर द्वारा नोड_मॉड्यूल्स फ़ोल्डर को मान्यता प्राप्त करने के लिए एक और वोट।

कॉमनजेएस मॉड्यूल के लिए, टाइपस्क्रिप्ट को आदर्श रूप से उसी फ़ाइलनाम रिज़ॉल्यूशन का पालन करना चाहिए, जो आवश्यकता है ।

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

node_modules निर्देशिका को स्रोतों के सापेक्ष कहाँ होना चाहिए?

एटम-टाइपस्क्रिप्ट अब बॉक्स से बाहर typescript.definition का समर्थन करता है। विवरण: https://github.com/Microsoft/TypeScript/issues/2829

आप एटम-टाइपस्क्रिप्ट का उपयोग करके आसानी से ऐसे पैकेज भी बना सकते हैं:गुलाब: फिर से देखें #2829

परिसीमन

यदि आप ऐसा पैकेज साझा करते हैं जो किसी बाहरी लाइब्रेरी पर निर्भर नहीं है तो यह _flawless_ काम करेगा। यदि ऐसा होता है तो हमें एक मॉड्यूल संघर्ष समाधान एल्गोरिदम की आवश्यकता होती है।

मैं इस मामले के लिए सुझावों के लिए तैयार हूं, लेकिन मेरी योजना है:

• हम ऐसे d.ts को पढ़ने में कुछ स्मार्ट चीजें करते हैं जो टाइपस्क्रिप्ट को बाहरी reference टिप्पणियां नहीं देते हैं (उदाहरण के लिए यहां node.d.ts https://github.com/TypeStrong/atom-typescript-examples /blob/master/node/node_modules/example-typescript-b/definition/sample-bdts) और इसके बजाय हमारे अपने .d.ts की ओर इशारा करते हुए अगर हमारे पास यह हमारी टाइपिंग में है।

क्या यह 2.0 के लिए ट्रैक पर रहने वाला है? यह Node.js अपनाने के लिए एक महत्वपूर्ण विशेषता की तरह लगता है, जो अभी दर्दनाक है, यहां तक ​​​​कि निश्चित रूप से टाइप और पसंद के साथ भी।

यह Node.js अपनाने के लिए एक महत्वपूर्ण विशेषता की तरह लगता है, जो अभी दर्दनाक है, यहां तक ​​​​कि निश्चित रूप से टाइप और पसंद के साथ भी।

@LPGhatguy कृपया https://github.com/Microsoft/TypeScript/issues/2338 देखें। @व्लादिमा इस पर काम कर रही है, लेकिन ऐसा नहीं लगता कि इसे अभी तक कोई मील का पत्थर सौंपा गया है: गुलाब:

@LPGhatguy हम इसे अगली रिलीज में लाने की कोशिश कर रहे हैं। उम्मीद है कि जल्द ही।

@mhegazy आपका मतलब 1.6 है? यह कमाल का होगा!

क्या यह #2338 से संबंधित है?

हाँ टाइपस्क्रिप्ट 1.6 के लिए (कम से कम हम यही करने की कोशिश कर रहे हैं), #2338 के लिए हाँ; इसके आस-पास कुछ अन्य परिवर्तन और मुद्दे हैं जिनमें #3147 और #4154 . शामिल हैं

फिर, इसे एक मील का पत्थर के रूप में टाइपस्क्रिप्ट 2.0 के रूप में क्यों टैग किया गया?

धन्यवाद @heycalmdown , मील का पत्थर हटा दिया। हम आम तौर पर सुझावों के लिए मील के पत्थर टैग नहीं करते हैं। उम्मीद है कि हमारे पास इस मुद्दे पर एक या दो सप्ताह के भीतर एक अपडेट होगा। बने रहें।

मैं इसका पालन करने के लिए ES6 मॉड्यूल समर्थन के लिए पूछने में झंकार करना चाहूंगा (जो मुझे लगता है कि यह होगा?)

के लिए टाइपिंग

import mylib = require('mylib');
mylib.foo(mylib.bar);

जैसा व्यवहार करना चाहिए

import { foo, bar } from 'mylib';
foo(bar);

मैं इसका पालन करने के लिए ES6 मॉड्यूल समर्थन के लिए पूछने में झंकार करना चाहूंगा (जो मुझे लगता है कि यह होगा?

@ डेविड साउथर यह _स्वचालित रूप से _ मामला होगा। दोनों के बीच लुकअप सुसंगत है :गुलाब:

इसे #4154 द्वारा नियंत्रित किया जाता है।

अगर मैं रात का उपयोग कर रहा हूं, तो कल से मुझे "बस काम" करने के लिए नोड मॉड्यूल आयात करने की उम्मीद करनी चाहिए?

प्रश्न:
मुझे लगता है कि फाइलों का नाम रखना एक आम परंपरा है
कॉमनजेएस में "इंडेक्स" और
एएमडी में "मुख्य"
छोटे रास्तों के लिए।
शीर्ष पर प्रश्न में लेखक आयात करता है
/node_modules/concator/index.ts के रूप में
import concator = require('concator');

कृपया मुझे क्षमा करें - मैं वर्तमान में यह पता लगा रहा हूं कि क्या अभी भी सूचकांक संकल्प समर्थित है और एएमडी में index.ts या main.ts के बारे में कैसे समाधान की आवश्यकता है?
मैं यह जानने के लिए @basarat को भी पिंग कर रहा हूं कि क्या यह https://github.com/TypeStrong/atom-typescript द्वारा समर्थित है / होगा क्योंकि अब यह मुझे ऊपर बताए अनुसार किसी भी index.ts की आवश्यकता नहीं है।

@sebilasse , अगर आप आज typescript@next का उपयोग कर रहे हैं, तो इसे --module commonjs के साथ काम करना चाहिए

import concator = require('concator'); // resolves to node_modules/concator/index.ts

पिछले रिलीज से एएमडी रिज़ॉल्यूशन में कोई बदलाव नहीं आया है।

@ डेविड साउथर यह आज typescript@next में होना चाहिए। इसे आज़माएं और हमें बताएं कि इसका किराया कैसा है।

@mhegazy @basarat : +1: ठीक है। लेकिन आप main.ts या index.ts के लिए AMD रिज़ॉल्यूशन के बारे में क्या सोचते हैं - क्या यह भविष्य में संगत नहीं होना चाहिए?

@sebilasse , AMD के लिए मुझे लगता है कि हमें #2338 में @vladima द्वारा बताए गए अनुसार कुछ करने की आवश्यकता है (अनुभाग के लिए: RequJS/ES6 मॉड्यूल लोडर)।

बहुत अच्छा!! \o/

@mhegazy अभी भी मेरी अपेक्षा के अनुरूप काम नहीं कर रहा है।

मैंने अपने "आदर्श" उपयोग के मामले के साथ https://github.com/DavidSouther/typescript-example-using-node एक साथ रखा। tslib एक साधारण पुस्तकालय है जो एकल फ़ंक्शन को निर्यात करता है। tsclient tslib पर निर्भर करता है, साथ ही readline नोड पैकेज से। सेटअप स्क्रिप्ट स्थापित करने, लिंक करने और निष्पादित करने की सुविधा है। मैंने एक रन शामिल किया है, और इनलाइन टिप्पणियों के साथ अनपेक्षित भागों को एनोटेट किया है।

% ./setup
...
> [email protected] build ~/ts-node/tslib
> tsc --version ; tsc -p src/

message TS6029: Version 1.7.0-dev.20150831
...
> [email protected] build /Users/southerd/devel/tmp/ts-node/tsclient
> tsc --version ; tsc -p src/

message TS6029: Version 1.7.0-dev.20150831
# Expect this to find tslib, but fail type checking.
# See tsclient/app.ts for details
src/app.ts(4,21): error TS2307: Cannot find module 'tslib'.

+ node ./dist/app.js # This works as expected!
What would you ask? What is the meaning of life?
42
+ set +x

मुझे tsclient (VSCode संस्करण 0.7.0 (0.7.0)) में tslib आयात के लिए भाषा समर्थन भी नहीं मिल रहा है, हालांकि मुझे पूरी तरह से यकीन नहीं है कि यह किस TSC का उपयोग कर रहा है, या इसे कैसे बदला जाए।

@DavidSouther टाइपस्क्रिप्ट कंपाइलर '.d.ts' फ़ाइलों को खोजने के लिए package.json में 'टाइपिंग' फ़ील्ड की जाँच करें। इस परिवर्तन के साथ मुझे src/app.ts(13,7): error TS2322: Type 'string' is not assignable to type 'number'. मिल रहा है जो एक वैध त्रुटि की तरह दिखता है

आह, मैंने डॉक्स के उस टुकड़े को याद किया होगा। मेरे पास अभी भी दूसरा मुद्दा है - मैं VSCode tsc संस्करण कैसे बदल सकता हूँ?

आप "typescript.tsdk" सेटिंग के माध्यम से VSCode को कस्टम टाइपस्क्रिप्ट SDK स्थान प्रदान कर सकते हैं - यह tsserver.js और मानक '.d.ts' फ़ाइलों वाले फ़ोल्डर को इंगित करना चाहिए। मामले में अगर टाइपस्क्रिप्ट को npm पैकेज के रूप में स्थापित किया गया है तो यह कुछ इस तरह होगा

// Place your settings in this file to overwrite the default settings
{   
    "typescript.tsdk": "C:\\Sources\\bugs\\node\\typescript-example-using-node\\tslib\\node_modules\\typescript\\lib"       
}

क्या किसी को काम करने का नमूना मिला? मैंने पूरी दोपहर इसके साथ खेलने की कोशिश की, लेकिन मैं हमेशा इसके साथ समाप्त होता हूं

error TS2307: Cannot find module

फिलहाल कोड node_modules/my-module/ में है। और मैंने एक index.ts परिभाषित किया जो सब कुछ निर्यात करने का ख्याल रखता है, और मैंने इसे typescript.main के तहत package.json में संदर्भित किया। उपभोक्ता परियोजना में मैंने 'my-module' से {AClass} आयात करने का प्रयास किया; और my-module आयात करें = आवश्यकता ('my-module'); वे दोनों टाइपस्क्रिप्ट 1.7.0-dev.20150901 के साथ एक ही त्रुटि की ओर ले जाते हैं।

--module commonjs के साथ गैर-रिश्तेदार नाम वाले मॉड्यूल को हल करते समय, कंपाइलर .d.ts की तलाश करेगा जो node_modules\name\index.d.ts में नाम से मेल खाता है या package.json में दिखता है एक संपत्ति के लिए typings , और .d.ts को यह इंगित करता है लोड करें।

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

मैंने कार्यान्वयन को दर्शाने के लिए नोड मॉड्यूल रिज़ॉल्यूशन एल्गोरिदम में चरणों को अपडेट किया है: https://github.com/Microsoft/TypeScript/issues/2338

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

/// <reference path="index.ts" />

declare module 'my_module' {
    export * from 'index';
}

साथ ही, यह किसी भी तरह से ts को node_modules से संकलित करता है, इसलिए मुझे संकलन के बाद इसे हटाने के लिए एक साफ कार्य जोड़ना चाहिए। क्या उस सुविधा का वर्णन कहीं है जो प्रक्रिया को सारांशित करता है?

संपादित करें: मुझे यह काम करने के लिए मिला है, लेकिन यह सुपर हैकी है और अभी भी त्रुटियों को आउटपुट करता है। मैंने डीटीएस-जनरेटर के साथ एक डीटीएस बनाया, और फिर मैंने अपनी कक्षाओं को इस तरह आयात किया:

import MyClass from '../../node_modules/my_module/dist/MyClass';

अगर मैं 'my_module/MyClass' से आयात MyClass का उपयोग करता हूं, तो मैं इसे बिना किसी त्रुटि के संकलित करने के लिए प्राप्त करता हूं, लेकिन रनटाइम पर मुझे त्रुटि मिलती है कि मॉड्यूल 'my_module/MyClass' नहीं मिल रहा है। उपरोक्त समाधान के साथ यह सीधे संकलित .js को इंगित करता है और रनटाइम पर यह किसी भी तरह काम करता है, भले ही यह त्रुटि आउटपुट करता है, संकलन समय पर मॉड्यूल नहीं ढूंढ सकता है।

अभी भी सबमॉड्यूल से आयात करने में समस्या आ रही है (उदाहरण के लिए npm install angular2, import { Inject, Binding } from 'angular2/di' । आज रात तक एक निहित परीक्षण केस प्राप्त करने पर काम करेगा।

ऐसा मत सोचो कि कोणीय पहले से ही टाइपस्क्रिप्ट कंपाइलर द्वारा अपेक्षित तरीके से अपनी टाइपिंग को बंडल करता है।

यह शायद सच है; मैं उनके साथ काम करूंगा और देखूंगा कि यह कहां खत्म होता है।

यह सुविधा टाइपस्क्रिप्ट 1.1 पर अच्छी तरह से काम कर रही है, उदाहरण के लिए https://github.com/Nemo157/typescript_w_node_modules_example

लेकिन टाइपप्रति 1.5.3 में विफल, कुछ भी बदल गया?

------ अपडेट करें ---------

मुझे पता है कि यह 1.6 में रिलीज होगी, धन्यवाद

मैं केवल 1.6.2 . में यह "आधा काम" प्राप्त कर सकता हूं

सबसे पहले, मैं dist निर्देशिका में my-lib.d.ts के साथ एक पुस्तकालय पैकेज करता हूं, और इस फ़ाइल को package.json फ़ाइल में इंगित करता हूं typings विशेषता (उदाहरण "typings" : "dist/my-lib.d.ts" )

फिर मैं इस लाइब्रेरी को Test.ts टाइपस्क्रिप्ट फ़ाइल का उपयोग करके आयात करता हूं

import { MyObject } from "my-lib"

MyObject ठीक से आयात किया जाता है और जेएस कोड ट्रांसपिलेशन पर उत्सर्जित होता है।
विजुअल स्टूडियो कोड MyObject . पर भी पूर्णता प्रदान करता है

हालांकि मुझे कंपाइलर चेतावनियां मिलती हैं कि:
Test.ts(10,60): error TS2306: File '[]/node_modules/my-lib/dist/my-lib.d.ts' is not a module.

विजुअल स्टूडियो कोड वास्तव में आयात को एक कठिन त्रुटि के रूप में दिखाएगा

नोड पैकेज से किसी भी आयातित मॉड्यूल को "बाहरी मॉड्यूल" होना चाहिए, न कि "परिवेश मॉड्यूल घोषणाएं"। यानी कोई declare module "foo" {.. } घोषणाएं नहीं, बल्कि फ़ाइल में शीर्ष स्तरीय आयात या निर्यात घोषणाएं।

इसलिए यदि आपका पैकेज "my-lib" टाइपस्क्रिप्ट में लिखा गया है, तो बस इसे --declarations के साथ बनाएं और टाइपिंग को अपने मुख्य मॉड्यूल की .d.ts फ़ाइल में सेट करें। यदि नहीं, और आपकी टाइपिंग कुछ ऐसी है जिसे आपने हाथ से लिखा है, या निश्चित रूप से टाइप किया है, तो आपको या तो इसे बाहरी मॉड्यूल में बदलना होगा, या #4665 के हल होने तक प्रतीक्षा करनी होगी (उम्मीद है कि जल्द ही)।

इस प्रतिबंध का कारण यह है कि यह आपके पैकेज उपयोगकर्ताओं के लिए बाद में वैश्विक दायरे के प्रदूषण और संघर्ष का कारण बन सकता है। #4665 में इस बारे में लंबी चर्चा है।

भविष्य की खोजों के लिए यहां कुछ दस्तावेज दिए गए हैं: https://github.com/Microsoft/TypeScript/wiki/Typings-for-npm-packages

@mhegazy आपके त्वरित उत्तर के लिए धन्यवाद जिसने वास्तव में टाइपस्क्रिप्ट में लिखे गए कॉमनज लाइब्रेरी के निर्माण को स्वचालित करने में मेरी खोज में मदद की, जिसे जावास्क्रिप्ट और टाइपस्क्रिप्ट कोड दोनों द्वारा उपभोग किया जा सकता है।
import/export वाक्य रचना और संकल्प हाल ही में इतनी तेजी से आगे बढ़ रहा है कि मुझे लगता है कि अभी जो गायब है वह एक बनाने के तरीके पर एक निश्चित मार्गदर्शिका है।

मुझे यह काम मिल गया ... एक चेतावनी के साथ (और इसलिए एक और सवाल)

यहाँ सेटअप का एक सरलीकृत दृश्य है।

पुस्तकालय में तीन ऑब्जेक्ट A1, A2 और B 2 टाइपस्क्रिप्ट फ़ाइलों A.ts और B.ts में होते हैं; कुछ इस तरह

सूत्रों का कहना है

A.ts

class A1{}
class A2{}
export { A1, A2 }

B.ts

class B{}
export { B }

हम जो उजागर करना चाहते हैं उसे index.ts में एकत्र किया जाता है:

export * from './A'
export * from './B'

निर्माण
निर्माण ग्रंट की मदद से किया जाता है और --module commonjs और --declaration झंडे tsc 1.6.2 पर सेट किए जाते हैं
निर्माण का अंतिम परिणाम एक ऐसा पेड़ है जो दिखता है

    package.json
    dist/
        js/
             A.js
             B.js
             index.js
        typings/
             A.d.ts
             B.d.ts
             index.d.ts

package.json में ये दो प्रविष्टियाँ हैं:

"main": "dist/js/index.js",
"typings": "dist/typings/index.d.ts"

टाइपस्क्रिप्ट 1.6.2 में इस लाइब्रेरी का उपयोग एक साधारण import {A1, A2, B} from "mylib" के साथ बिल्कुल ठीक काम करता है। एकाधिक स्तर निर्भरता (यानी एक दूसरे को आयात करने वाले पुस्तकालय) भी ठीक काम करते हैं।

जहाँ समस्याएँ उत्पन्न होती हैं, जब पुस्तकालय किसी अन्य पुस्तकालय पर निर्भर करता है जो कि _not_ एक टाइपस्क्रिप्ट पुस्तकालय है।
मान लें कि पुस्तकालय Node.js पर निर्भर करता है।
स्रोत फ़ाइलों में से एक में NodeJS की टाइपिंग का संदर्भ होगा जैसे
///<reference path="../typings/node/node.d.ts"/>

ट्रांसपिलेशन पर कि <reference > निर्देश संबंधित घोषणा फ़ाइल में समाप्त होने जा रहा है; समस्या यह है कि node.d.ts का पथ गलत या अस्तित्वहीन होने की संभावना है।
क्या इसके बारे में जाने का कोई अनुशंसित तरीका है?

_नोट_: पुस्तकालय के दिलचस्प हिस्सों को उजागर करने के लिए index.ts फ़ाइल पर उपयोग द्वारा इस समस्या को कम किया गया है, क्योंकि index.ts में <reference > निर्देश शामिल करने का कोई कारण नहीं है और 1.6 के साथ .2, संकलक को इस बात की परवाह नहीं है कि संदर्भ निर्देश में Adts का पथ अमान्य है

@bgrieder हम इसे tsconfig.json का उपयोग करके फॉस्फर में संभालते हैं:
https://github.com/phosphorjs/phosphor-widget/blob/master/src/tsconfig.json

हम केवल संकलित फाइलों में किसी भी बाहरी टाइपिंग को जोड़ते हैं जो हमें चाहिए। इसका मतलब यह है कि यदि इनमें से कोई भी बाहरी प्रकार हमारे सार्वजनिक इंटरफ़ेस का हिस्सा है, तो कोड के उपभोक्ताओं को अपने निर्माण के हिस्से के रूप में उन बाहरी टाइपिंग को भी प्रदान करना होगा। _ये ठीक है_। अगर हम उन परिभाषाओं को बंडल करते हैं, और उपभोक्ता द्वारा उपयोग किए जाने वाले कुछ अन्य lib _also_ उन्हीं परिभाषाओं को बंडल करते हैं, तो डुप्लिकेट प्रतीक संघर्ष होंगे।

@sccolbert हाँ!
मैं चिंतित था कि <reference ...> निर्देशों को हटाने से सभी आईडीई पर स्वत: पूर्णता टूट जाएगी, लेकिन हे, नहीं: कम से कम विजुअल स्टूडियो कोड 0.8.0 tsconfig.json से उन परिभाषाओं को चुनने के लिए पर्याप्त स्मार्ट प्रतीत होता है

reference के साथ हो गया। उत्कृष्ट !

@sccolbert

क्या होगा यदि आप इसके भीतर एक सादा Node.js प्रोजेक्ट और इसके लिए *.d.ts का उपयोग कर रहे हैं, तो tsconfig समाधान आपकी कैसे मदद करता है?

@heycalmdown आप d.ts को files फ़ील्ड में tsconfig पर जोड़ें, यहां एक उदाहरण दिया गया है जो यह करता है:

https://github.com/phosphorjs/phosphor-widget/blob/master/test/src/tsconfig.json#L11
https://github.com/phosphorjs/phosphor-widget/blob/master/test/src/index.ts#L10

ध्यान दें कि हमें $#$4 import #$ के बजाय यहां require का उपयोग करना होगा, केवल इस कारण से कि कैसे d.ts के लिए फ़ाइल आंतरिक रूप से लिखी गई है।

ठीक है मैं समझ गया। आपकी रिपॉजिटरी एक अच्छे उदाहरण की तरह दिखती है।

क्या यह वास्तव में टाइपस्क्रिप्ट 1.6.2 में लागू किया गया है?

अगर यह है, तो क्या कोई मुझे बता सकता है कि मैं यहाँ क्या गलत कर रहा हूँ ?:
https://github.com/chanon/typescript_module_example

आप शायद es6 आयात सिंटैक्स चाहते हैं।

बुधवार को, 4 नवंबर, 2015, 6:10 पूर्वाह्न चैनन नोटिफिकेशन @github.com ने लिखा:

क्या यह वास्तव में टाइपस्क्रिप्ट 1.6.2 में लागू किया गया है?

अगर ऐसा है, तो क्या कोई मुझे बता सकता है कि मैं यहाँ क्या गलत कर रहा हूँ ?:
https://github.com/chanon/typescript_module_example

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/Microsoft/TypeScript/issues/247#issuecomment -153688004
.

मैंने इसे es6 आयात सिंटैक्स का उपयोग करने के लिए अभी अपडेट किया है और मुझे अभी भी वही त्रुटियां मिलती हैं (मॉड्यूल नहीं मिल रहा है)।

@chanon package.json के लिए node_modules पैकेज में typings कुंजी होनी चाहिए जो d.ts फ़ाइल की ओर इशारा करती है, _not_ एक typescript कुंजी इंगित करती है .ts फ़ाइलें जैसे आपके पास अभी हैं।

हम PhosphorJS में विशेष रूप से (TS 1.6.2 पर) नोड मॉड्यूल रिज़ॉल्यूशन का उपयोग करते हैं और यह ठीक काम करता है। यहां एक उदाहरण दिया गया है: https://github.com/phosphorjs/phosphor-widget/blob/f908341cb1d46ada8ad8149e695a75e7ea2fde57/package.json#L6

धन्यवाद @sccolbert , हालांकि मेरा प्रारंभिक प्रस्ताव (इस मुद्दे के शीर्ष पर) typescript.main संपत्ति के लिए package.json में अनुमति देना था जो नोड मॉड्यूल पैकेज के लिए मुख्य टाइपस्क्रिप्ट प्रविष्टि बिंदु को इंगित करेगा। टाइपस्क्रिप्ट में।

यह टाइपस्क्रिप्ट कोड में टाइपस्क्रिप्ट मॉड्यूल को d.ts टाइपिंग फाइलों की आवश्यकता के बिना आयात करने की अनुमति देगा (उन्हें उत्पन्न करने की भी कोई आवश्यकता नहीं होगी)।

@chanon मैं सिर्फ यह बता रहा था कि आपको अपना कोड चलाने के लिए क्या करना है।

@sccolbert मैं धन्यवाद देखता हूँ।

क्या कोई जानने वाला मुझे बता सकता है कि क्या मुझे इस विशिष्ट सुविधा का अनुरोध करते हुए कोई अन्य समस्या बनानी चाहिए?

मॉड्यूल रिज़ॉल्यूशन लॉजिक (इस एक के अलावा) से संबंधित मुख्य मुद्दे #2338 हैं जो बंद हैं और #5039 जो सिस्टमजेएस स्टाइल पथ रिज़ॉल्यूशन का समर्थन करने के बारे में प्रतीत होता है जो बहुत जटिल दिखता है।

हालांकि इस मुद्दे में शुरू में अनुरोध की तरह आयात करने वाली साधारण कॉमनजेएस शैली को भुला दिया गया है? मॉड्यूल के रूप में typescript.main और फ़ोल्डर्स के बारे में कम से कम हिस्सा?

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

यह वास्तव में एक टाइपस्क्रिप्ट फ़ाइल को अपेक्षाकृत पूर्व आयात करने से बहुत अलग नहीं है ।

करने के बजाय:
import * as lib from '../relative/path/to/typescriptFile.ts'

या:
import * as lib from '../../node_modules/myModule/index.ts'

बस TSC को सामान्य नोड_मॉड्यूल पथ रिज़ॉल्यूशन का उपयोग करके आयात करने के लिए टाइपस्क्रिप्ट फ़ाइल खोजने में सक्षम होने दें। और कम से कम फ़ोल्डर्स को मॉड्यूल के रूप में आयात करने की अनुमति दें (index.ts के साथ) ताकि दूसरे उदाहरण में मैं कर सकूं:

import * as lib from 'myModule'

या ऐसा इसलिए है क्योंकि "आप वास्तव में अपनी निर्भरताओं को संकलित नहीं करना चाहते हैं, आप केवल उनकी टाइपिंग का उपभोग करना चाहते हैं"?

@chanon जिस व्यवहार को आप रेखांकित करते हैं वह अब मास्टर में है। क्या आप typescript@next एक कोशिश दे सकते हैं?

#2338 के मूल कार्यान्वयन ने यह सुनिश्चित करने के लिए कुछ अतिरिक्त जाँचें जोड़ीं कि यह एक .d.ts है, और यह मुख्य रूप से आपके द्वारा बताए गए कारण के लिए है। आप नहीं चाहते कि आपके पैकेज उपयोगकर्ता प्रत्येक कंपाइलर आमंत्रण पर आपके "स्रोत" संकलित करें, और उनके कंपाइलर विकल्पों के आधार पर अलग-अलग आउटपुट प्राप्त करें, आप केवल अपनी टाइपिंग साझा करना चाहते हैं।

हालाँकि यदि आप दोनों पैकेज बना रहे हैं तो आप उन पर पुनरावृति करते हुए ऐसा करना चाह सकते हैं। #5278 में प्रतिबंध हटा दिया गया था।

अधिक जानकारी के लिए कृपया एनपीएम पैकेज के माध्यम से टाइपिंग साझा करने के लिए विकी पेज पर एक नज़र डालें: https://github.com/Microsoft/TypeScript/wiki/Typings-for-npm-packages

आपके स्पष्टीकरण के लिए धन्यवाद @mhegazy! मैं इसे आजमाऊंगा।

@mhegazy बस typescript@next के साथ प्रयास किया, उम्मीद के मुताबिक काम करता है!

यह भी खूब रही!!

और इस और संबंधित मुद्दों में भाग लेने के लिए आप सभी का धन्यवाद: +1:

इस सुविधा को वास्तव में जिस तरह से लागू किया गया है, उसे समझाने के लिए मैंने ऊपर दिए गए समस्या टेक्स्ट में एक अपडेट जोड़ा है।

एक खदान में कदम रखने के जोखिम पर, यह कैसे सादे-पुराने npm मॉड्यूल के साथ काम करने की उम्मीद है कि _don't_ के पास package.json में typings संपत्ति है? tape या get-parameter-names के साथ typescript@next का उपयोग करने का प्रयास करने से यह मेरे चेहरे पर उड़ जाता है क्योंकि यह उन पैकेजों को खोजने में असमर्थ है क्योंकि उनके पास यह नहीं है संपत्ति।

निश्चित रूप से, वे टाइपस्क्रिप्ट मॉड्यूल नहीं हैं, लेकिन मुझे कोई काम नहीं मिल रहा है और यह npm पारिस्थितिकी तंत्र के एक महत्वपूर्ण हिस्से को बंद कर देता है।

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

आप बिना टाइप किए सामान्य मॉड्यूल का उपयोग कर सकते हैं, केवल सामान्य कॉमनज का उपयोग करके सिंटैक्स की आवश्यकता होती है।

जैसे
वर मॉड्यूलनाम = आवश्यकता ("मॉड्यूलनाम")

टाइपस्क्रिप्ट के साथ ES6 सिंटैक्स का उपयोग करते समय @chanon 'क्लासिक' require सिंटैक्स का उपयोग करने के लिए एक हैक की तरह महसूस करता है, इसलिए मैं जावास्क्रिप्ट निर्भरता का उपयोग कर सकता हूं, लेकिन धन्यवाद। मैंने tsd उपयोगिता के बारे में सुना है, लेकिन मैं इस बारे में अनिश्चित हूं कि यह ES6 आयात का उपयोग करने के लिए कैसे कारक होगा .. जब तक मुझे इस प्रकार के मॉड्यूल के लिए /// <reference path=... का उपयोग शुरू नहीं करना पड़ता है?

हाँ यह एक तरीका है। दूसरा तरीका है हमारे लिए tsconfig.json फाइलें और अपनी रूट tsd.d.ts फाइल को पहली फाइल के रूप में रखें।

आपको इसे पढ़ने में रुचि हो सकती है, tsd और टाइपिंग को कवर करना https://angularclass.com/the-state-of-typescript-packages/

@joewood जानकारी के लिए धन्यवाद, पिछली बार जब मैंने टाइपस्क्रिप्ट में देखा तो व्यक्तिगत .d.ts फाइलों के दिनों में था। उत्कृष्ट लेख

@chanon @danpantry यह कुछ हद तक दुर्भाग्यपूर्ण है कि import foo = require('foo') (foo के साथ node_modules के तहत) काम नहीं करता है जब foo's package.json में टाइपिंग नहीं होती है।

@wmono ठीक है, शायद टाइपस्क्रिप्ट 0.80 या शायद पहले import foo = require('foo') सिंटैक्स केवल टाइपिंग के साथ मॉड्यूल आयात करने के लिए था। यदि इसमें टाइपिंग नहीं होती तो आप इसके बजाय var foo = require('foo') का उपयोग करते। तो मैं कहूंगा कि यह जैसा है वैसा ही है।

@chanon क्षमा करें; उपयोगकर्ता त्रुटि। ऐसा लग रहा था कि वेबपैक "नंगे" require के साथ संघर्ष कर रहा था लेकिन समस्या कहीं और थी।

क्षमा करें कोई स्पष्ट कर सकता है क्यों
var foo = require('foo');
टाइपिंग के बिना एक मानक नोड_मॉड्यूल के लिए काम करता है लेकिन
import foo from 'foo';
नहीं? क्या यह सिर्फ मनमाने ढंग से परिभाषित किया गया था? मैं नहीं देखता कि बाद वाला _ should't_ काम क्यों नहीं करता - मुझे परवाह नहीं है कि बाहरी JS लाइब्रेरी में टाइपिंग है या नहीं।

क्षमा करें कोई स्पष्ट कर सकता है क्यों
वर फू = आवश्यकता ('फू');
टाइपिंग के बिना एक मानक नोड_मॉड्यूल के लिए काम करता है लेकिन
'फू' से फू आयात करें;
नहीं? क्या यह सिर्फ मनमाने ढंग से परिभाषित किया गया था? मैं नहीं देखता कि बाद वाले को काम क्यों नहीं करना चाहिए - मुझे परवाह नहीं है कि बाहरी जेएस लाइब्रेरी में टाइपिंग है या नहीं।

@harangue क्योंकि var require प्रतिस्पर्धी मॉड्यूल सिंटैक्स में से एक था (यह एक commonjs है और सूची में अन्य में amd शामिल है) जो कि प्रकार की जाँच प्रणाली_ के बाहर _ का समर्थन करता था। यदि कोई टाइप सिस्टम का उपयोग करना चाहता है तो वह import require करेगा। ES6 लेने के साथ: हथौड़ा: और कह रहा है कि एक वाक्यविन्यास (: अंगूठी :) उन सभी पर शासन करने के लिए ... यह समझ में आता है कि मॉड्यूल सिंटैक्स बॉक्स के बाहर टाइप चेकिंग सिस्टम द्वारा समर्थित है: गुलाब:

@बसरत स्पष्टीकरण के लिए धन्यवाद। आइकन भी मददगार थे। ;) मुझे अभी भी यकीन नहीं है कि ES6 सिंटैक्स अनिवार्य प्रकार की जाँच क्यों करता है। संकलक को यह कहने से रोकने के लिए क्या है - "ओह, मुझे उस मॉड्यूल के लिए किसी भी प्रकार का डेटा नहीं मिला लेकिन मैं इसे वैसे भी आयात करूंगा"। यह (बल्कि सहज ज्ञान युक्त, IMO) व्यवहार के क्या दुष्प्रभाव होंगे?

यह उन लोगों के लिए भ्रमित करने वाला है (जैसे मैं) ES6 से टाइपस्क्रिप्ट में आ रहा हूं। मुझे उम्मीद है कि ES6 मॉड्यूल आयात सिंटैक्स टाइपस्क्रिप्ट में उसी तरह व्यवहार करेगा, लेकिन अफसोस कि यह अधिकांश npm पैकेजों के लिए बिल्कुल भी काम नहीं करता है ...

लेकिन अफसोस कि यह अधिकांश npm पैकेजों के लिए बिल्कुल भी काम नहीं करता है ...

@teohhanhui मैं उलझन में हूँ। क्या आप एक ठोस उदाहरण दे सकते हैं कि आप क्या हासिल करने की कोशिश कर रहे हैं और आपने किस कोड को हासिल करने की कोशिश की है। यह सिर्फ इसलिए है ताकि मैं आपकी मदद कर सकूं :गुलाब:

import koa from 'koa';

Cannot find module 'koa'. (2307) देता है जब target es6 है

koa (बेशक) node_modules में है

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

यह एक खराब निर्णय की तरह लगता है क्योंकि कोई import कथन की अपेक्षा करता है जैसे यह सादे ES6 मॉड्यूल में काम करता है। (हां, मुझे पता है, अधिकांश npm पैकेज कॉमनजेएस मॉड्यूल हैं, लेकिन यहां उनका समर्थन करना अभी भी समझदारी की बात होगी।)

मैं टाइपस्क्रिप्ट के लिए नया हूं इसलिए मुझे शायद गलत समझ है, लेकिन क्या टाइप परिभाषाएं वैकल्पिक नहीं हैं? मैं टाइप परिभाषा के बिना पैकेज आयात क्यों नहीं कर सकता? मैं टाइप परिभाषाओं को देखने/बनाने के लिए मजबूर नहीं होना चाहता हूं।

लीगेसी TS मॉड्यूल आयात सिंटैक्स पर स्विच करना एक विकल्प नहीं है क्योंकि es6 लक्ष्य का उपयोग करते समय इसकी अनुमति नहीं है।

मैं टाइपस्क्रिप्ट के लिए नया हूं इसलिए मुझे शायद गलत समझ है, लेकिन क्या टाइप परिभाषाएं वैकल्पिक नहीं हैं?

यह गलत है। परिभाषाएँ टाइप करें _in आपका अपना कोड_ निहित हो सकता है, जिसका अर्थ है कि टाइपस्क्रिप्ट कंपाइलर "इसे समझेगा"। आप टाइपस्क्रिप्ट कंपाइलर के माध्यम से कभी भी किसी तृतीय-पक्ष लाइब्रेरी को पास नहीं करने जा रहे हैं, इसलिए कंपाइलर कभी नहीं जानता कि वे प्रकार क्या हैं। यदि आप तृतीय-पक्ष कोड का उपयोग करने की योजना बना रहे हैं, तो आपको वास्तव में निश्चित रूप से टाइप किए गए और tsd टूल का उपयोग करना सीखना चाहिए।

@basarat के इस जवाब के बारे में क्या?

http://stackoverflow.com/a/27434010/1529493

टाइप परिभाषाओं के बिना गैर-टाइपस्क्रिप्ट मॉड्यूल को इस तरह आयात क्यों नहीं किया जा सकता है?

वे कर सकते हैं: const koa = require(‘koa’)

21 जनवरी 2016 को 14:47 बजे, तेह हान हुई नोटिफिकेशन @github.com ने लिखा:

टाइप परिभाषाओं के बिना मॉड्यूल को इस तरह आयात क्यों नहीं किया जा सकता है?

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub https://github.com/Microsoft/TypeScript/issues/247#issuecomment -173574234 पर देखें।

@bgrieder मैं ES6 आयात वाक्यविन्यास का जिक्र कर रहा हूं।

(अर्थात आप कॉमनज का उपयोग कर रहे हैं), यदि नहीं, तो बसरत उत्तर के declare var का उपयोग करें

21 जनवरी 2016 को 14:48 बजे ब्रूनो ग्रीडर ब्रूनो। [email protected] ने लिखा:

वे कर सकते हैं: const koa = require(‘koa’)

21 जनवरी 2016 को 14:47 बजे, तेह हान हुई < नोटिफिकेशन @github.com [email protected] > ने लिखा:

टाइप परिभाषाओं के बिना मॉड्यूल को इस तरह आयात क्यों नहीं किया जा सकता है?

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub https://github.com/Microsoft/TypeScript/issues/247#issuecomment -173574234 पर देखें।

मुझे लगता है कि मुद्दा बनाया जा रहा है कि टाइपस्क्रिप्ट के लक्ष्यों में से एक यह है कि वैध जेएस वैध टीएस होना चाहिए। ES6 मॉड्यूल सिंटैक्स के लिए, TS को इसे टाइप डिक्लेरेशन के साथ या उसके बिना संकलित करना चाहिए। प्रकार की घोषणाओं के बिना import कथन को केवल any पर हल करना चाहिए।

मैं उससे पूर्णतया सहमत हूँ।

@ जो वुड

21 जनवरी 2016 को 14:52 बजे, जो वुड नोटिफिकेशन @github.com ने लिखा:

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

मैं उससे पूर्णतया सहमत हूँ।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub https://github.com/Microsoft/TypeScript/issues/247#issuecomment -173575301 पर देखें।

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

• निश्चित रूप से टाइप किए गए पर नहीं हैं
• ./typings फ़ोल्डर नहीं है
• मेरे पास इसे खुद टाइप करने का समय नहीं है

इसके बजाय मुझे किसी ऐसी चीज से लड़ना नहीं पड़ेगा जो मेरे विकास में सहायता करने के लिए हो।

@danpantry , क्यों न केवल अपने लिब एंट्री पॉइंट को किसी के रूप में घोषित करें, और कंपाइलर इससे संतुष्ट होगा:

declare var $: any;

यह एक उपाय है। लेकिन मुझे लगता है कि टाइपस्क्रिप्ट के लिए ES6 मॉड्यूल कोड का सम्मान करना और इनायत से फॉलबैक करना एक अच्छा विचार होगा। मुझे एक अच्छा कारण नहीं दिख रहा है कि एक आयात विवरण any पर वापस क्यों नहीं आ सकता है, बजाय एक त्रुटि की रिपोर्ट करने के यदि शीर्ष स्तर के मॉड्यूल को टाइप नहीं किया गया है।

रनटाइम मुद्दों को किसी का ध्यान नहीं जाने देने के बजाय, मैं संकलक को जल्दी और जोर से (वर्तमान व्यवहार) विफल करने के लिए पसंद करूंगा। "यह असुरक्षित है, और मुझे पता है कि मैं क्या कर रहा हूं" इंगित करने के लिए मैं स्पष्ट रूप से declare var foo: any लाइन रखना पसंद करूंगा।

जब कोई टाइपिंग उपलब्ध नहीं है तो ES6 आयात सिंटैक्स की अनुमति क्यों न दें, एक साधारण कंपाइलर चेतावनी है कि आयात ने «उत्सर्जन रोकथाम» त्रुटि के बजाय any का समाधान किया है?

21 जनवरी 2016 को 18:42 बजे एस. क्रिस कोलबर्ट नोटिफिकेशन @github.com ने लिखा:

मैं संकलक को जल्दी और जोर से (वर्तमान व्यवहार) विफल करने के लिए पसंद करूंगा, बजाय रनटाइम मुद्दों को किसी का ध्यान नहीं जाने देने के लिए। मैं स्पष्ट रूप से var foo घोषित करना पसंद करूंगा: "यह असुरक्षित है, और मुझे पता है कि मैं क्या कर रहा हूं" इंगित करने के लिए कोई भी पंक्ति।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub https://github.com/Microsoft/TypeScript/issues/247#issuecomment -173649845 पर देखें।

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

^^^ यह एक हजार बार। इस बात का कोई संकेत नहीं था कि जब मैं पहली बार इस मुद्दे पर आया तो मैं कुछ गलत कर रहा था। आखिर में क्या हो रहा था यह पता लगाने के लिए गुगलिंग में कुछ लंबा समय लगा (संयोग से मुझे लगता है कि यह मुद्दा एकमात्र खोज योग्य स्थानों में से एक है जो इसे दस्तावेज करता है)। यह इतना अनावश्यक है। और कोणीय 2 के साथ टाइपस्क्रिप्ट को मुख्यधारा में लाने से मैं केवल कल्पना कर सकता हूं कि इस व्यवहार से कितने स्टैक ओवरफ्लो प्रश्न आएंगे।

खराब त्रुटि प्रबंधन विवरण से बहुत सहमत हैं और इसे किसी भी तरह आयात करें!

@sccolbert मैं मानता हूं कि एक अधिसूचना होनी चाहिए, लेकिन मुझे यकीन नहीं है कि यह एक विफलता होनी चाहिए - इसके बजाय एक चेतावनी, शायद

मैं @mhegazy और @sccolbert से सहमत हूं।

अगर कुछ गड़बड़ है तो मैं जोर से शिकायत करने के लिए हमारे उत्पादन निर्माण स्क्रिप्ट (यानी सीआई सर्वर) को ज्यादा पसंद करूंगा।

हाय दोस्तों,
यह व्यवहार मुझे पागल कर देता है। परिभाषा फ़ाइलें अद्यतित नहीं हैं या package.json में पंजीकृत नहीं हैं।
अंत में TypeScript JavaScript $ का उत्पादन करता है, इसलिए, जब तक हम सभी इस भाषा में नहीं जाते हैं, तब तक pls दुनिया के बाकी हिस्सों के प्रति विनम्र रहें जो आपकी जैसी किसी भी अन्य ट्रांसपिल्ड भाषाओं में मातृभाषा के लिए पुस्तकालय प्रदान करता है। .
मैं वास्तव में जानना चाहता हूं कि क्या TypeScript JavaScript पारिस्थितिकी तंत्र में रहना चाहता है (मैं कहूंगा कि "एकीकृत करने के लिए" जैसा दिखता है, अभी तक नहीं है) या अलग जीवन जीना चाहता है, जैसा कि दूसरा विकल्प मुझे कुछ और करने के लिए प्रेरित करेगा।
यह प्राप्त करने के लिए कि .tsconfig फ़ाइल में एक स्विच करेगा, उसके लिए हम कह सकते हैं कि हम सख्त आयात चाहते हैं या नहीं।
सीआई ज़ोरदार शिकायत के लिए उसके लिए JavaScript में परीक्षण ढांचे हैं। वैसे भी, आपको रनटाइम पर टाइप चेकिंग नहीं मिलेगी, खराब आयात जांच कम महत्वपूर्ण मुद्दा है।
शुभकामनाएं।

@ devel-pa, त्रुटियां आपको यह बताने के लिए हैं कि संकलक को पता नहीं है कि आपका आयात क्या है। आयात के बाद के किसी भी उपयोग की जाँच नहीं की जा सकती है।

त्रुटियों को बंद करने से किसी भी समस्या का समाधान नहीं होता है। यह इन "अज्ञात" को चुपचाप आपके पूरे सिस्टम में धकेल देता है। प्रकार की जानकारी के बिना, संकलक आपको चेतावनी नहीं दे सकता कि क्या सुरक्षित है और क्या नहीं। और वह टाइपस्क्रिप्ट का पूरा बिंदु है :)

उत्पन्न जेएस के लिए। TS प्रकार की कोई भी त्रुटि आपके आउटपुट को उत्पन्न होने से नहीं रोकती है। यदि आप प्रकार की त्रुटियों की परवाह नहीं करते हैं, तो बस उन सभी को अनदेखा करें। कंपाइलर अभी भी आपकी मेल खाने वाली .js फाइलें जेनरेट करता है।

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

declare module "myLibrary" {
    var a: any;
    export = a;
}

जैसा कि #6615 में बताया गया है, टाइपस्क्रिप्ट को जल्द ही इसके छोटे रूप का समर्थन करना चाहिए।

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

मैं TS में नए लोगों के लिए यहाँ भ्रम को समझ सकता हूँ। यदि उन्होंने JS में सक्रिय रूप से ES6 मॉड्यूल सिंटैक्स का उपयोग किया है, तो यह केवल TS में क्यों काम नहीं करता है? import from से अधिक var x = require के बारे में विशेष क्या है - जिसे _is_ एक निहित के रूप में माना जाता है। मूल रूप से आयात एक टीएस विशिष्ट कीवर्ड था, इसलिए इसका तात्पर्य यह था कि डेवलपर चाहता था कि मॉड्यूल को टाइप किए गए मॉड्यूल के रूप में माना जाए। अब जबकि यह TS के लिए विशिष्ट नहीं है, मुझे नहीं लगता कि यह धारणा बनाई जा सकती है।

निहित-कोई भी त्रुटि बिना किसी प्रकार के परिवर्तनीय घोषणाओं पर होती है। लेकिन एक अघोषित चर का उपयोग करना आज भी एक त्रुटि है। Jquery के लिए, आपको अभी भी declare var $; की आवश्यकता है ताकि संकलक यह जान सके कि आपका वास्तव में $ नामक एक वैश्विक चर होना चाहिए था और न केवल इसे मिस-टाइप किया गया था। यह कमोबेश मॉड्यूल के लिए समान है, कंपाइलर को यह जानने की जरूरत है कि "myLibrary" नामक एक मॉड्यूल है और यह मिस-टाइप किया गया नाम नहीं है। तो बस इसके लिए एक घोषणा जोड़ें।

किसी भी दर पर, #6615 को आपके सिस्टम में सभी मॉड्यूल से मेल खाने के लिए declare module "*"; जोड़ने का समर्थन करना चाहिए, हालांकि मुझे लगता है कि यदि आप ऐसा करते हैं, तो आपको अपने टूलिंग से कोई मदद नहीं मिल रही है, और आप खुद को एक दर्दनाक के लिए स्थापित कर रहे हैं संक्रमण बाद में जब आप इसे हटाने का निर्णय लेते हैं।

@mhegazy मैं आपके तर्क को समझता हूं लेकिन मुझे वास्तव में इस तर्क से समस्या है

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

टाइप किए गए मॉड्यूल (पैकेज.json में typings प्रविष्टि वाले) के साथ स्थिति और भी खराब है, जिसे हम ठीक से टाइप किया हुआ मान सकते हैं, वास्तव में आंतरिक रूप से उन प्लेसहोल्डर का उपयोग कर सकते हैं।

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

(एक पक्ष के रूप में, जैसा कि typescriptlang.org होम पेज पर बताया गया है, टाइपस्क्रिप्ट जावास्क्रिप्ट का एक 'सुपरसेट' है, और आईएमएचओ किसी भी वैध ईएस 6 सिंटैक्स को बस निगल लिया जाना चाहिए)

वर्कअराउंड और कार्पेट के नीचे कचरा छिपाना मेरे लिए सबसे बुरा हो सकता है (ES6 सुपर के बगल में)।
मैं हर समय JS libs के साथ काम कर रहा हूं, और आमतौर पर मेरे काम के हिस्से के रूप में पिछले संस्करणों के साथ और घर पर अतिरिक्त कोडिंग के साथ। 90% टाइप नहीं किए गए हैं या पुराने डीफ़ हैं, 9% बहुत अच्छी तरह से टाइप नहीं किए गए हैं (क्योंकि कंपाइलर सभी फाइलों के लिए एक डीफ़ बनाना नहीं जानता है)। न तो मेरे पास बहुत अच्छा def है, उसी पिछले कारण से और इस कारण से कि मेरा लक्ष्य जेएस है, मुझे नहीं लगता कि मुझे मूल भाषा की परवाह है।
साथ ही, मैंने कारण देखा है कि 'अज्ञात' libs हैं। नहीं, बिलकुल नहीं, यदि डेवलपर्स नहीं जानते और समझते हैं कि किस प्रकार के कामों का उपयोग किया जाता है, तो उनसे परेशान क्यों होते हैं, मुझे पता है कि मैं सामान का उपयोग क्यों कर रहा हूं और मैं स्टैक में क्यों जोड़ रहा हूं। चेतावनी और परीक्षण (यदि यह मौजूद है) उसके लिए पर्याप्त हैं।
कृपया, जावास्क्रिप्ट पहले, यह लक्ष्य और पारिस्थितिकी तंत्र है। TS संकलन समय पर बेहतर कोडिंग और टाइप चेक के लिए केवल एक एक्सेसरी है, लेकिन केवल उसके लिए जो हम बना रहे हैं। बाकी कोई टाइपस्क्रिप्ट व्यवसाय नहीं है।
मैं यह उल्लेख करना चाहता हूं कि मैं nmps peerDependencies के भी खिलाफ था, मैं वह हूं जिसने चुना है, सॉफ्टवेयर नहीं। अनिवार्य प्रोग्रामिंग, बेबी।

नोड_मॉड्यूल्स के बजाय जेएसपीएम निर्देशिका से मॉड्यूल आयात करने के बारे में क्या?

संपादित करें: मुझे एक मौजूदा टिकट मिला है -> https://github.com/Microsoft/TypeScript/issues/6012

निर्देशिका लोड करने के लिए SystemJS का उपयोग करते समय, मैं नोड मॉड्यूल रिज़ॉल्यूशन के साथ बस एक समस्या में भाग गया:

जाहिर है, जबकि नोड (और इसलिए टाइपस्क्रिप्ट) समझता है कि पथ वास्तव में एक निर्देशिका है और इसलिए इसके बजाय index.ts लोड होता है, सिस्टमजेएस ऐसा कुछ नहीं करता है, जिसका अर्थ है कि वैध टीएस कोड वास्तव में ब्राउज़र में लोड करने में विफल रहेगा।

यह नोड मॉड्यूल के बारे में भी सच है जिसमें index.ts/js एंट्री पॉइंट होता है या यहां तक ​​कि package.json main प्रॉपर्टी का उपयोग करते हैं। इसके साथ काम करना थोड़ा आसान है, क्योंकि SystemJS में पैकेज कॉन्फ़िगरेशन जोड़ना आसान (हालांकि दोहराव) है। मनमानी निर्देशिकाओं के साथ काम करते समय यह इतना आसान नहीं है।

इसके लिए उपयुक्त समाधान क्या है?

JSPM स्वचालित मॉड्यूल रिज़ॉल्यूशन वर्तमान में समर्थित नहीं है। इसे https://github.com/Microsoft/TypeScript/issues/6012 द्वारा ट्रैक किया जाता है।

पथ मैपिंग मॉड्यूल रिज़ॉल्यूशन समर्थन का उपयोग करने की सिफारिश है, देखें https://github.com/Microsoft/TypeScript-Handbook/blob/release-2.0/pages/Module%20Resolution.md#path -mapping

उपरोक्त निर्देश एक शुरुआत है, लेकिन कुछ लोगों को कुछ अतिरिक्त करने की आवश्यकता हो सकती है... आपको जोड़ना पड़ सकता है
<Folder Include="node_modules" />
करने के लिए .njsproj

और जानकारी

मैं गल्प के साथ निर्माण कर रहा था, और .nsproj में TypeScriptCompileBlocked था। वीएस 15 पूर्वावलोकन 5 में डिबगिंग ब्रेकप्वाइंट में मुद्दों को ठीक करने के लिए (मुझे "मॉड्यूल में फ्रेम नहीं" त्रुटि मिल रही थी) और जिन मुद्दों पर मैं इंटेलिजेंस के साथ था, मुझे जोड़ना पड़ा को .njsproj. वह निर्देशिका पहले से ही थी जब मैंने प्रोजेक्ट आयात किया था, लेकिन गिट-अनदेखा करने के लिए सेट किया गया था। यही मेरा सिद्धांत है कि क्यों विजुअल स्टूडियो ने इसे नजरअंदाज कर दिया (शायद इसमें नोड_मॉड्यूल्स के लिए एक स्वचालित अपवाद होना चाहिए?)

डिबगिंग और इंटेलिजेंस दोनों काम करने से परे, मैंने इंटेलिजेंस त्रुटियों को उसी सटीक त्रुटियों से परे देखना बंद कर दिया, जो मैंने इसे बनाते समय गल्प से देखा था, जिसकी अपेक्षा की जाती है।