संदर्भ की परवाह किए बिना सभी यूएमडी ग्लोबल्स तक पहुंच की अनुमति देने के बजाय, केवल यूएमडी ग्लोबल तक पहुंच की अनुमति देना सरल नहीं होगा यदि यूएमडी मॉड्यूल को ///<reference types=<>> सिंटैक्स के माध्यम से स्पष्ट रूप से "संदर्भित" (आयातित नहीं) किया गया है। , या tsconfig.json में types कॉन्फ़िगरेशन के माध्यम से?

दूसरे शब्दों में, केवल एक मॉड्यूल के भीतर ///<reference types=<>> का उपयोग करने की अनुमति क्यों नहीं है?

अगर हमने कहा कि /// <reference type="x" /> मतलब है कि x वैश्विक रूप से उपलब्ध _everywhere_ था, तो अक्सर ऐसा होता है कि कुछ .d.ts फ़ाइल कहीं न कहीं गलत तरीके से संदर्भ वाली चीज़ों के लिए जा रही है जो वास्तव में वैश्विक नहीं हैं; मैं आपको यह बता सकता हूं क्योंकि मैं निश्चित रूप से 2.0 शाखा को निश्चित रूप से हटा रहा हूं और यह एक बहुत ही सामान्य त्रुटि है)।

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

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

संपादित करें: यह देखकर खुशी हुई कि यह अपने अलावा कई लोगों को प्रभावित करता है।

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

मैं लॉश का उपयोग कर रहा हूं, जो स्वयं के टाइपिंग के साथ नहीं आता है। मेरे पास एक ऐसी स्थिति है जहां मेरे रनटाइम वातावरण में रिश्तेदार पथ आयात विवरणों का उपयोग करना सबसे आसान है। इसलिए, मेरे पास स्थानीय रिश्तेदार पथ और फ़ोल्डर रिश्तेदारों ('./oo' के साथ-साथ 'एन / बार') के साथ आयात विवरणों का एक संयोजन है।

अगर मैं मैन्युअल रूप से @types/lodash/index.d.ts से node_modules/lodash/ कॉपी करूं तो मुझे टाइपेक करने की चीजें मिल सकती हैं।

अब तक मेरा वर्कअराउंड ///<amd-dependency path='../lodash' name="_"> (और import स्टेटमेंट) का उपयोग कर रहा था। इस कॉम्बो के साथ, संकलक द्वारा @ प्रकार / लॉश परिभाषा को 'विश्व स्तर पर' देखा जाएगा और अभी भी उत्सर्जित जेएस में सही सापेक्ष पथ ( ../lodash ) होगा।

मुझे उम्मीद है कि यह इस मुद्दे के काफी करीब है?

क्या आप स्पष्ट कर सकते हो

मेरे पास एक ऐसी स्थिति है जहां मेरे रनटाइम वातावरण में रिश्तेदार पथ आयात विवरणों का उपयोग करना सबसे आसान है।

तथा

अगर मैं मैन्युअल रूप से @types/lodash/index.d.ts से node_modules/lodash/ कॉपी करूं तो मुझे टाइपेक करने की चीजें मिल सकती हैं।

कृप्या? मैं इस परिदृश्य से परिचित नहीं हूं, इसलिए इसका उद्देश्य क्या है और यह सहायक क्यों है?

हाय दोस्तों,

मैं वर्तमान @types/bluebird घोषणा समस्या का समाधान ढूंढने की प्रक्रिया में हूं (कृपया इसे पढ़ने में समय व्यतीत न करें)। मैंने पाया, कि .d.ts में export as namespace Promise; जोड़कर इस समस्या को हल किया जा सकता है, लेकिन फिर मैं इस github मुद्दे द्वारा वर्णित समस्या में भाग लेता हूं।

संक्षेप में, मैं काम करने के लिए निम्नलिखित चाहूंगा:

1. git clone -b vanilla-es5-umd-restriction-problem https://github.com/d-ph/typescript-bluebird-as-global-promise.git
2. cd typescript-bluebird-as-global-promise
3. npm install
4. export as namespace Promise; export = Bluebird; लाइन से ऊपर जोड़कर node_modules/@types/bluebird/index.d.ts संपादित करें।
5. npm run tsc

वर्तमान परिणाम:
'Promise' refers to a UMD global, but the current file is a module. Consider adding an import instead. त्रुटियों की एक जोड़ी।

अपेक्षित परिणाम:
संकलन सफल हुआ।

यह समस्या विशेष रूप से कठिन है, क्योंकि यह देव के कोड और 3rd पार्टी कोड (उस मामले में RxJS) दोनों में Promise उपयोग से चालू है। बाद वाला मानता है कि Promise वैश्विक है (जेएस मानक द्वारा प्रदान किया गया है), इसलिए उदाहरण के लिए import Promise from std; // (not that "std" is a thing) का उपयोग करना कभी नहीं बदलेगा।

मैं वास्तव में यूडीएम मॉड्यूल को आयात करने योग्य मॉड्यूल और ग्लोबल्स दोनों के रूप में उपयोग करने का एक तरीका चाहता हूं।

धन्यवाद।

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

मैंने इस मुद्दे को अलग तरीके से हल किया (जैसे: Promise और PromiseConstructor इंटरफेस वृद्धि)।

"globals": [] tsconfig विकल्प उन्हें हर जगह दिखाई देना बेहतर लगता है। UMD घोषणा के आदर्श बनने के साथ, गलती से मॉड्यूल आयात करने की भूल अधिक होती है। कृपया वर्तमान व्यवहार को बनाए रखने पर विचार करें। यह एक त्रुटि होनी चाहिए।

अनायास ही मुझे याद है जब एक पल में वैश्विक पल window.moment चर को हटा दिया। हमने सोचा कि हम विवेकपूर्ण तरीके से इसे हर जगह आयात कर रहे हैं, लेकिन हम 5 स्थानों के बारे में भूल गए थे।

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

इस पर +1। मैं सिर्फ SystemJS के साथ React का उपयोग करने की कोशिश कर रहा था, और जैसा कि React बहुत अच्छी तरह से बंडल नहीं करता है, मैं इसे सीधे एक स्क्रिप्ट टैग में CDN से लोड कर रहा हूं, और इस प्रकार React / ReactDOM ऑब्जेक्ट विश्व स्तर पर उपलब्ध हैं।

मैं सबसे अच्छे अभ्यास के रूप में कोड लिख रहा हूं, लेकिन यह एक रनटाइम स्क्रिप्ट में बंडल किया जाएगा (रोलअप) जो लोड पर निष्पादित होता है। यह import from प्रतिक्रिया / प्रतिक्रिया-डोम के लिए एक दर्द (और झूठ) है, और फिर लोडर को कॉन्फ़िगर करने के लिए "वास्तव में नहीं, ये ग्लोबल्स हैं" कहने के लिए कॉन्फ़िगर करें (उदाहरण के लिए https में दिए गए वेबपैक कॉन्फ़िगरेशन: / /www.typescriptlang.org/docs/handbook/react-&-webpack.html)। यह बहुत आसान होगा (और अधिक सटीक) बस मेरे मॉड्यूल में ग्लोबल्स के रूप में उपलब्ध हैं। मैंने जो प्रयास किए, जैसे वे सहज लग रहे थे, वे थे:

1. npm install --save-dev @types/react @types/react-dom
2. मेरे tsconfig.json में: "jsx": "react", "types": ["react", "react-dom"]
3. मेरे मॉड्यूल में: export function MyComponent() { return <div>{"Hello, world"}</div>; }
4. इसी प्रकार: ReactDOM.render(...)

हालांकि यह React refers to a UMD global, but the current file is a module. Consider adding an import instead त्रुटि का परिणाम है।

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

import * as ReactObj from "react";
import * as ReactDOMObj from "react-dom";

declare global {
    var React: typeof ReactObj;
    var ReactDOM: typeof ReactDOMObj;
}

मैं विकल्प तीन प्लस ग्लोबल्स से भी सहमत हूं: [] बैकअप। यह नए और पुराने उपयोगकर्ताओं के लिए बहुत सहज लगता है और लोगों को इसकी सटीक कार्यक्षमता प्रदान करेगा।

मैं कोड का विशेषज्ञ नहीं हूं, इसलिए मैं वास्तव में यह नहीं कह सकता कि 2 अधिक बेहतर होगा या नहीं, लेकिन मुझे लगता है कि यह सहज भी होगा क्योंकि इसके लिए कॉन्फ़िगरेशन सीधा है।

अगर मैं इनमें से किसी को लागू करने में मदद करना चाहता हूं तो मुझे कहां जाना चाहिए?

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

प्रतिक्रिया बहुत अच्छी तरह से बंडल नहीं करती है

@ बिल्टी क्या आप विस्तृत कर सकते हैं?

यह import from प्रतिक्रिया / प्रतिक्रिया-डोम के लिए एक दर्द (और झूठ) है, और फिर लोडर को कॉन्फ़िगर करने के लिए "वास्तव में नहीं, ये ग्लोबल्स हैं" कहने के लिए कॉन्फ़िगर करें

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

इस मुद्दे (https://github.com/rollup/rollup/issues/855) को एक उदाहरण के लिए देखें कि वे कैसे बंडलिंग को अनुकूलित करने की कोशिश कर रहे हैं और जो आकार देखे गए हैं। प्रभावी रूप से मेरे सेटअप में (रोलअप का उपयोग करते हुए) मैंने रिएक्ट को कम से कम आकार के लाभ को देखा, इसलिए मैं इसे सिर्फ सीडीएन से सेवा करूंगा। मेरे लिए जिसके लाभ हैं:

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

साइट को लोड करने पर क्रोम देव टूल्स में देख रहे हैं, GZipped HTTP कनेक्शन पर रिएक्ट और रिएक्ट-डोम (छोटा संस्करण), केवल 47kb नेटवर्क ट्रैफ़िक है, जो किसी साइट पर अधिकांश छवियों से कम है, इसलिए मैं नहीं हूं वैसे भी कम करने की कोशिश के बारे में चिंतित, जब तक कि वास्तव में होने वाले बड़े लाभ न हों (जैसे 50% की कमी)।

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

@billti SystemJS को इस परिदृश्य के लिए पूरा समर्थन है। आप विकास के दौरान स्थानीय रूप से स्थापित पैकेज का उपयोग करने और उत्पादन में सीडीएन का उपयोग करने के बीच अदला-बदली कर सकते हैं। इसमें मेटाडेटा के लिए भी पूर्ण समर्थन है जो यह निर्दिष्ट करता है कि सभी आयातों को वास्तव में एक वैश्विक चर के संदर्भ को इंगित करना चाहिए जिसे एक बार लाया जाएगा और जब पहली आवश्यकता होगी तो विंडो ऑब्जेक्ट से जुड़ी होगी, उत्पादन में यह सीडीएन से आ सकता है। मैंने यह प्रतिक्रिया के साथ नहीं किया है, लेकिन मैंने इसे कोणीय 1.x के साथ किया है

साभार @aluanhaddad दिलचस्प ... मैं वास्तव में कुछ इसी तरह का काम करने की कोशिश कर रहा था जिसने मुझे इस सड़क पर ले जाया, और यह पता नहीं लगा सका, इसलिए आज सुबह ही सिस्टमजेएस रेपो पर सवाल पूछा। यदि आप उत्तर दे सकते हैं कि https://github.com/systemjs/systemjs/issues/1510 कैसे प्राप्त करें, तो यह वास्तव में उपयोगी होगा :-)

नोट: मेरी अन्य टिप्पणी अभी भी कायम है, कि टाइपस्क्रिप्ट द्वारा किया गया उत्सर्जन स्वयं इसके बिना प्रयोग करने योग्य नहीं है, क्योंकि आपको कोड चलाने के लिए ग्लोबल्स के आयात के लिए मैप करने के लिए SystemJS / WebPack / Rollup आदि जैसी किसी चीज की आवश्यकता है।

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

अपने दूसरे बिंदु पर, यही ठीक है कि SystemJS क्या करता है। यह उन आयातों को वैश्विक रूप से मैप करेगा और समझता है कि वैश्विक वास्तव में अनुरोध किया जा रहा है और पहले ही लोड हो चुका है। उत्पादन निश्चित रूप से प्रयोग करने योग्य है

FYI करें: मुझे SystemJS API का उपयोग करके SystemJS में यह काम मिला और https://github.com/systemjs/systemjs/issues/1510 पर अपना समाधान जोड़ा। धन्यवाद।

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

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

@ बिल्टी मुझे समझ नहीं आ रही है। ऐसा कौन सा परिदृश्य है जिसमें आपका एकमात्र विकल्प मॉड्यूल के वैश्विक संस्करण का उपयोग करना है, लेकिन टाइपस्क्रिप्ट आपको ऐसा करने की अनुमति नहीं देता है? मैंने केवल उन परिदृश्यों को देखा है जहां एक पुस्तकालय एक वैश्विक और एक मॉड्यूल दोनों के रूप में उपलब्ध है।

@DanielRosenwasser मुझे लगता है कि उनका मतलब है कि रिएक्ट वास्तव में रनटाइम पर एक वैश्विक वस्तु के सदस्य के रूप में एक वैश्विक है, क्योंकि यह कैसे लोड किया जा रहा है।

@ बिल्टी भयानक है कि आप इसे काम कर रहे हैं।

अपने दूसरे बिंदु को फिर से देखें: मैं देख रहा हूं कि आपका क्या मतलब है।

मुझे लगता है कि मेरी भावना यह है कि, एक ब्राउज़र परिदृश्य में, क्योंकि आपको या तो आवश्यकता के लिए लोडर का उपयोग करने की आवश्यकता है जैसे कि आवश्यकताजेएस या वेबपैक जैसा एक पैकेट क्योंकि कोई भी ब्राउज़र मॉड्यूल का समर्थन नहीं करता है फिर भी इससे कोई फर्क नहीं पड़ता है। (मैंने सुना है कि चक्र ने इसे एक ध्वज के पीछे उपलब्ध किया है)। तो एक अतिरिक्त टूल के बिना कोड को चलाने का कोई तरीका नहीं है। यह define , require , या System.register युक्त आउटपुट के निहितार्थ का एक प्रकार है जो उत्सर्जित _JavaScript_ कोड पोर्टेबल होने की संभावना नहीं है। हालाँकि, मुझे "मॉड्यूल बनाम मॉड्यूल नहीं" का महत्व दिखाई देता है।

आप कम से कम केवल "मॉड्यूल" को एक बार संदर्भित करने के लिए इस वर्कअराउंड का उपयोग कर सकते हैं।

_shims.d.ts_

import __React from 'react';

declare global {
  const React: typeof __React;
}

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

अपने shims.d.ts को पुन: भेजें, यदि आप कुछ पदों पर जाते हैं, तो आप देखेंगे कि मैंने अभी के लिए क्या किया है (महान दिमाग एक जैसे हैं); ;-)

मैं इसे कई तरीकों में से एक अब काम कर सकता हूं, यह बात नहीं है। हम टाइपस्क्रिप्ट को अपनाने में आसान बनाने की कोशिश कर रहे हैं, और उपयोगकर्ताओं को सफलता के गर्त में गिर रहे हैं, न कि निराशा के गड्ढे में। इसे ध्यान में रखते हुए, मैं अक्सर टाइपस्क्रिप्ट और हिटिंग मुद्दों का उपयोग करने की कोशिश करते समय खुद से दो सवाल पूछता हूं: क) क्या यह वैध कोड है, और ख) क्या ग्राहक ऐसा करने की कोशिश कर रहे हैं।

देखने के रूप में मेरे पास (गैर-टाइपस्क्रिप्ट) संस्करण था, जो मैं बाबेल में चाहता था कि जिस समय मुझे इसे टाइप करने में समय लगा, मुझे लगता है कि यह कहना उचित है कि कोड मान्य है। जैसा कि रिएक्ट डॉक्स के इंस्टॉलेशन पेज से पता चलता है कि रिएक्ट को शामिल करने के लिए सीडीएन से स्क्रिप्ट टैग का

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

समाधान के रूप में ... बस यहाँ थूकना, लेकिन शायद "लिबास" संकलक विकल्प, जो पहले से ही प्रभावी रूप से परिभाषित करता है कि एपीआई पूरे प्रोजेक्ट में क्या उपलब्ध है, वैश्विक स्तर पर पुस्तकालयों को जोड़ने के लिए @types/name स्वरूप मान भी ले सकता है। (और शायद रिश्तेदार रास्तों का समर्थन भी करते हैं)।

हम टाइपस्क्रिप्ट को अपनाने में आसान बनाने की कोशिश कर रहे हैं, और उपयोगकर्ताओं को सफलता के गर्त में गिर रहे हैं, न कि निराशा के गड्ढे में।

मुझे लगता है कि हम उपयोगकर्ताओं को अभी सफलता के गर्त तक ले जाने की कोशिश कर रहे हैं। यदि कोई मॉड्यूल केवल सशर्त रूप से किसी वैश्विक को परिभाषित करता है, तो आप गलती से उपयोगकर्ताओं को किसी ऐसी चीज का उपयोग करने के लिए मार्गदर्शन कर रहे हैं जो मौजूद नहीं है। इसलिए मुझे कुछ अलग विकल्प दिखाई देते हैं:

1. एक संवर्धित export as namespace foo निर्माण बनाएं जो केवल एक मॉड्यूल द्वारा आयात न किए जाने पर दिखाई दे।
2. कुछ भी न करें, और आयात का उपयोग करने के लिए लोगों को धकेलते रहें - यह मेरी राय में कम या ज्यादा ठीक है, क्योंकि हमने त्रुटि संदेश को यथोचित रूप से निर्धारित किया है।
3. लोगों को हर जगह से यूएमडी का उपयोग करने की अनुमति दें - मैं ईमानदारी से इस विचार पर उतना बड़ा नहीं हूं।

@billti

अपने shims.d.ts को पुन: भेजें, यदि आप कुछ पदों पर जाते हैं, तो आप देखेंगे कि मैंने अभी के लिए क्या किया है (महान दिमाग एक जैसे हैं); ;-)

क्षमा करें, मुझे वह बहुत अच्छा लगा;)

मुझे नहीं लगता कि टाइपस्क्रिप्ट को पैटर्न का समर्थन नहीं करना चाहिए क्योंकि हमें नहीं लगता कि वे "सर्वोत्तम अभ्यास" या "विहित" हैं

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

उस ने कहा, अगर मॉड्यूल मुख्य रूप से ग्लोबल्स पर एक _perceived_ syntactic चीनी के रूप में उपयोग किया जाता है, तो उनकी विफलता हाथ में है, क्योंकि वे एक वाक्यात्मक चीनी नहीं हैं। यदि कुछ भी वे एक सिन्थेटिक नमक (शायद एक कर?) है जो हम सच्चे कोड अलगाव, स्क्रिप्ट टैगिंग से मुक्ति, स्पष्ट निर्भरता घोषणा, वैश्विक नाम स्थान नरक से बचने और अन्य लाभों जैसे लाभों के लिए उपभोग करते हैं। मॉड्यूल के लिए सिंटैक्स एर्गोनोमिक नहीं है, यह सबसे अच्छा है, लेकिन यह मॉड्यूल का शब्दार्थ है जो इसे सार्थक बनाता है।

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

@DanielRosenwasser

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

यह हल करने के लिए सबसे अच्छा तरीका लगता है।

यहाँ एक और मामला है जहाँ इस कारण समस्याएँ हैं:

वर्तमान में मैं जिस परियोजना पर काम कर रहा हूं, उसमें हम npm मॉड्यूल के साथ स्थानीय (ज्यादातर ऐतिहासिक कारणों से) शामिल हैं। अंत में रोलअप या ब्राउजराइफ़ का उपयोग करके सब कुछ शामिल हो जाता है, इसलिए यह ठीक है।

मैं इमोजी प्रोजेक्ट से .js फाइल का उपयोग करता हूं जिसे मैंने कोडबस में कॉपी किया था। बाद में मैंने इसके लिए टाइप घोषणाओं को निश्चित रूप से जोड़ा गया: https://github.com/DefinitelyTyped/DefinitelyTyped/pull/13293 मैंने सोचा कि मैं अब बस प्रकार लोड कर सकता हूं और सब कुछ काम करेगा। लेकिन ऐसा लगता नहीं है, क्योंकि टाइपस्क्रिप्ट मुझे वैश्विक एक्सेस नहीं करने देगा।

एनपीएम मॉड्यूल के लिए नहीं जाने का कारण यह है कि एनपीएम मॉड्यूल स्प्राइट और पीएनजी के कई मेगाबाइट को भी बंडल करता है। मुझे बस एक 200KiB स्क्रिप्ट की जरूरत है। प्रकार की घोषणाओं के साथ।

AngularJS के साथ, वर्कअराउंड declare var angular: ng.IAngularStatic । लेकिन यह नामस्थान के साथ काम नहीं करता है, है ना?

@dbrgn आप एक अलग समस्या का सामना कर रहे हैं। यदि मॉड्यूल वास्तव में एक वैश्विक है, तो आपकी प्रकार की परिभाषा गलत है। यह न तो वैश्विक घोषित करता है, न ही यूएमडी शैली की घोषणा है (यह यूएमडी शैली की घोषणाओं के बारे में है), यह वास्तव में केवल शुद्ध ईएस मॉड्यूल की घोषणा करता है।

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

AngularJS के साथ, वर्कअराउंड को var कोणीय घोषित किया गया था: ng.IAngularStatic। लेकिन यह नामस्थान के साथ काम नहीं करता है, है ना?

यह नाम स्थान के साथ काम करता है।

हमारी डिजाइन बैठक में चर्चा का परिणाम यह था कि हम हमेशा यूएमडी की अनुमति देने पर विचार कर रहे हैं, और एक ध्वज जोड़ रहे हैं जो वर्तमान प्रतिबंध को लागू करता है। UMD वैश्विक से एक्सेस प्रकारों पर काम करने के लिए प्रतिबंध भी बढ़ाया जाएगा।

इस बारे में अधिक विचार करने के बाद, मुझे अभी भी लगता है कि बेहतर काम करने के लिए एक नई घोषणा की तरह है। यह ध्वज नए वाक्यविन्यास की तुलना में कम खोज योग्य है, जिसे केवल घोषणा फ़ाइल लेखक द्वारा एक बार लिखा जाना चाहिए।

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

ऊ।

मुझे पता है कि बहुत सारे लोग हैं जो जावा को हंसाना पसंद करते हैं, लेकिन कम से कम काम करने के लिए बुनियादी जावा मॉड्यूल। जार काम करते हैं

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

Shims.d.ts हैक अच्छी तरह से काम करता है। लेकिन ऊ

वेबपैक https://github.com/Microsoft/TypeScript/issues/11108#issuecomment -285356313 का उपयोग करने वालों के लिए अस्थायी समाधान

वांछित UMD ग्लोबल्स के साथ externals webpack.config.js ।

    externals: {
        'angular': 'angular',
        'jquery': 'jquery'
        "react": "React",
        "react-dom": "ReactDOM"
    }

मुझे लगता है कि मौजूदा कोडबेस को स्थानांतरित करना आसान बनाने के लिए यह संभव होना चाहिए।

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

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

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

JQuery के अलावा, एक ही समस्या वाली अन्य स्क्रिप्ट हैं जैसे कि पीटा और अन्य। यह परियोजना को नाइट्रग्मारे में प्रवासित करता है। या, एक यथार्थवादी दृष्टिकोण से, अनम्य।

बेशक, यह सबसे अच्छा पैटर्न नहीं है, और मैं इसे एक नई परियोजना में उपयोग नहीं करूंगा। लेकिन मुझे नहीं लगता कि मैं इस समस्या के साथ एक ही हूँ

उपयोग करने के लिए यह मतलब होगा types में tsconfig.json इस बात के लिए? जैसे बिना types सेट, आपको वर्तमान निहित व्यवहार मिलता है और types सेट के साथ, आप सचमुच "ये चीजें ग्लोबल्स हैं" कह रहे हैं और UMD नामस्थान को वैश्विक रूप से प्रकट होने के लिए मजबूर कर सकते हैं। यह उस तरह का व्यवहार है जो आज भी मौजूद है (बल बल वैश्विक)। यह एक नया globals विकल्प पेश करने के विरोध में है।

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

@blakeembrey हालांकि types समझ में आता है, मैं इसे अतिभारित करने की धारणा के लिए उत्सुक नहीं हूं क्योंकि इसमें पहले से ही समस्याएं हैं। उदाहरण के लिए, <reference types="package" /> निर्माण में पहले से ही सीमा है कि यह "paths" समर्थन नहीं करता है। "package" को @types में एक फ़ोल्डर के नाम से संबंधित होना चाहिए

मुझे इस वार्तालाप के बाद एक कठिन समय मिल रहा है। क्या इसके लिए कोई अद्यतन या नियोजित संकल्प हुए हैं? ऐसा लगता है कि यह कुछ ऐसा है जो परिदृश्यों में उपयोगी हो सकता है जैसे कि जब लॉश एक एप्लिकेशन का एक अभिन्न अंग है, या जब अधिक 3 पार्टी लाइब्रेरी केवल खिड़की पर निर्भर होने के बजाय एक अधिक मॉड्यूलर संरचना में परिवर्तित हो जाती हैं।

क्या इसे संबोधित करने के लिए एक योजनाबद्ध तरीका है या कम से कम यह दस्तावेज़ करने के लिए कि वर्तमान उपलब्ध रिलीज़ के साथ इसे कैसे हल किया जाना चाहिए?

हाय @ मचविच मुझे एक्सटर्नल के रूप में रिएक्ट को परिभाषित करने के साथ निम्नलिखित त्रुटि हो रही है और declare global सिंटैक्स का उपयोग न करें:

TS2686: 'React' refers to a UMD global, but the current file is a module. Consider adding an import instead.

@ कैंटॉक्स declare सकते हैं, लेकिन मॉड्यूल का उपयोग क्यों नहीं करते?

@aluanhaddad ज्यादातर क्योंकि मैं आयात कॉल द्वारा किए गए काम से भ्रमित था। मैंने कुछ कहा, क्या निम्नलिखित कथन सही है?

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

यदि ये सही हैं, तो हम संक्षिप्तता के लिए टिप्पणियों को हटा सकते हैं, थ्रेड एक विशालकाय है।

जैसा कि @codymullins ऊपर पूछा गया है, क्या कोई इस समस्या के लिए वर्तमान समाधान को संक्षेप में प्रस्तुत कर सकता है? मैंने अभी लॉडश प्रकार की परिभाषा को अद्यतन किया और TS2686 त्रुटियों के बहुत सारे मिला।

मेरा वर्तमान हल पुराने, काम कर रहे मानक के अनुरूप टाइप किए गए फ़ाइल को हैक करना था, लेकिन अगर अधिक टाइप की गई फाइल टूटने लगे तो यह व्यवहार्य नहीं है।

मेरा परिदृश्य इस प्रकार है:

• अपने सिंगल-पेज एप्स में मैं एक में कई लाइब्रेरियों (लॉश सहित) को आयात करता हूं

ऊपर उल्लिखित शिम उदाहरण काम करता है, हालांकि vscode इसे एक त्रुटि के रूप में उजागर कर रहा है (भले ही यह अभी भी पूरी तरह से ठीक से करता है!)

कृपया मॉड्यूल में UMD ग्लोबल्स को एक्सेस करते समय त्रुटियां न दें। बड़े पैमाने पर परियोजना मैं पर काम कर रहा हूँ AngularJS में किया जाता है और हम आवेदन के लिए टाइपप्रति उपयोग कर रहे हैं, लेकिन निश्चित रूप से हम टाइपप्रति के बारे में पता करने की जरूरत angular से UMD वैश्विक और कोणीय प्रकार @types/angular । आपको लगता है कि यह "angular" types tsconfig.json में जोड़ने के रूप में आसान होगा, लेकिन, जो भी कारण से, यह नहीं है, और TSC मुझ पर चिल्लाती है। जितना मैं चाहता हूं कि सभी एनपीएम पैकेज शुद्ध टाइपस्क्रिप्ट थे, उनमें से अधिकांश सादे जेएस हैं और बहुत लंबे समय तक रहेंगे। मुझे वास्तव में यह समझ में नहीं आता है कि जब हम एक यूएमडी ग्लोबल मौजूद हैं, तब टीएससी सिर्फ d.ts आयात नहीं कर सकता है। यह स्थिति सामान्य से अधिक है - हर टाइपस्क्रिप्ट प्रोजेक्ट जो मैंने कभी भी कम से कम एक जेएस लाइब्रेरी का उपयोग करने पर काम किया है जिसे मुझे खुद को बंडल करना होगा और प्रकार की परिभाषाओं का उपयोग करके संदर्भ देना होगा।

क्या इस पर कोई अपडेट है?

मेरा usecase: मैं एक बड़े मौजूदा कोडबेस पर काम कर रहा हूं जो CDN का भारी उपयोग करता है। सामान्य उपयोगिताओं को कई पृष्ठों में स्क्रिप्ट टैग के माध्यम से आयात किया जाता है (उदाहरण के लिए क्लिपबोर्डज, लॉश)। मैं उन वैश्विक चरों का संदर्भ देना चाहूंगा, क्योंकि वे पृष्ठ पर उपलब्ध हैं। मॉड्यूल का उपयोग किए बिना, प्रासंगिक स्रोत फ़ाइलों के शीर्ष पर /// <reference type="$name" /> का उपयोग करके टाइपस्क्रिप्ट संकलन करना काफी आसान है। हालांकि यह मॉड्यूल बनाने की कोशिश करते समय काम करना बंद कर देता है।

ऐसा प्रतीत होता है कि धागे में दो दृष्टिकोण प्रस्तावित हैं:

1. /// <reference type="$name" /> आयात केवल वर्तमान फ़ाइल के नाम स्थान में टोकन रखें।

2. tsconfig.json में एक संकलक विकल्प / कॉन्फ़िगरेशन चर (उदा। "globals" , "types" )

मुझे लगता है कि दोनों दृष्टिकोण अच्छे हैं। जबकि मैं @RyanCavanaugh द्वारा विकल्प 1 की आलोचना से सहमत

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

मेरा मानना ​​है कि यह बहुत अधिक कष्टप्रद है कि आप मौजूदा व्यवहार के कारण UMD ग्लोबल्स के साथ मॉड्यूल का उपयोग नहीं कर सकते हैं। कुछ समाधान कुछ भी नहीं से बेहतर है।

क्या यह मुद्दा अभी भी बकाया है? और यदि हां, तो वर्तमान वर्कअराउंड क्या है?

यदि आप @types पैकेज स्थापित करते हैं, तो वे पैकेज जिन्हें मॉड्यूल के रूप में आयात नहीं किया जाता है, उन्हें ग्लोबल्स के रूप में उपलब्ध कराया जाता है।

उदाहरण के लिए, यदि मैं अपनी परियोजना की जड़ में npm install -D @types/underscore हूं, तो मैं ऐसे मॉड्यूल लिख सकता हूं जो अंडरस्कोर से कुछ भी आयात नहीं करते हैं, फिर भी _ वैश्विक उपलब्ध कराया जाता है (नीचे देखें)।

क्या आप उसके बाद हैं?

@ बिल्टी शायद मुझे गलतफहमी हो रही है, लेकिन आपका उदाहरण मेरे लिए काम नहीं करता है।

मरम्मत के लिए आवश्यक न्यूनतम:

जे एस / foo.ts:

// <reference types="js-cookie">

import { Bar } from "./bar";

const Foo = {
    set: function() {
        Cookies.set("foo", "bar");
    },
    get: function() {
        console.log(Cookies.get("foo"));
    }
};

window.onload = function() {
    console.log(Cookies);
}

जे एस / bar.ts

const Bar = {
    x: 3
};

export { Bar };

package.json:

{
  "name": "foo",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "private": true,
  "devDependencies": {
    "@types/js-cookie": "^2.1.0",
    "typescript": "^2.7.1"
  },
  "dependencies": {
    "http-server": "^0.11.1"
  }
}

tsconfig.json

{
    "compilerOptions": {
        "module": "system"
    },
    "files": [
        "js/foo.ts"
    ]
}

त्रुटि संदेश:

js / foo.ts (7,3): त्रुटि TS2686: 'कुकीज़' एक UMD वैश्विक को संदर्भित करता है, लेकिन वर्तमान फ़ाइल एक मॉड्यूल है। इसके बजाय एक आयात जोड़ने पर विचार करें।
js / foo.ts (10,15): त्रुटि TS2686: 'कुकीज़' एक UMD वैश्विक को संदर्भित करता है, लेकिन वर्तमान फ़ाइल एक मॉड्यूल है। इसके बजाय एक आयात जोड़ने पर विचार करें।
js / foo.ts (15,14): त्रुटि TS2686: 'कुकीज़' एक UMD वैश्विक को संदर्भित करता है, लेकिन वर्तमान फ़ाइल एक मॉड्यूल है। इसके बजाय एक आयात जोड़ने पर विचार करें।

आपके द्वारा प्राप्त किया गया व्यवहार इस बात पर निर्भर करता है कि आयातित मॉड्यूल को "उचित" UMD मॉड्यूल के रूप में लिखा गया था (यह "कुकीज़" के साथ व्यवहार है) या "एक ही समय में दोनों तरीके से काम करता है" मॉड्यूल (जो कैसे दर्ज किया गया है) ।

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

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

@RyanCavanaugh

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

😁

उन्हें ठीक करने का कोई भी मौका?

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

डेवलपर्स के रूप में हमने टूलचिन को स्वीकार किया है जो 5-6 साल पहले की तुलना में अधिक परिमाण के आदेश हैं, और जटिलता का प्राथमिक स्रोत मॉड्यूल रहा है।

यदि हम हार मान लेते हैं और इन यूएमडी पैकेजों को ग्लोबल्स के रूप में लोड करना शुरू कर देते हैं, तो यह सब क्या है?

और फिर भी ... लोग बस यही कर रहे हैं। यह भयानक है!

मेरा मतलब है, इस स्टैक ओवरफ्लो उत्तर में 61 ack हैं और यह पिछले आधे साल के लिए 99% पैकेज के लिए सभी गलत चीजों का सुझाव दे रहा है। (लेखक ने आज सुबह प्रदान किए गए कुछ फीडबैक के कारण UMD निर्भरता के लिए मॉड्यूल का उल्लेख करने के लिए कृपया इसे अपडेट करने के लिए अद्यतन किया)

यह सब इस नस में नहीं गया है और ग्लोबल्स पर वापस जा सकता है!

और फिर भी ... लोग बस यही कर रहे हैं। यह भयानक है!

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

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

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

इस पर किसी भी अद्यतन? मैं वास्तव में काम करने के लिए विकल्प 2 पसंद करूंगा:

कुछ सिंटैक्स या कॉन्फ़िगरेशन को यह कहने की अनुमति दें "यह यूएमडी वैश्विक वास्तव में वैश्विक रूप से उपलब्ध है"

इसके अलावा यह मदद नहीं करता है कि बहुत सारे पुराने स्कूल शैली के जेएस लिबास हैं
वहाँ, और उन सभी को फिर से लिखना प्रश्न से बाहर है। बस एक ठोस काम कर रहा है
मेरे समय के सभी सही ढंग से कचरे को संभालने के लिए रोलअप प्राप्त करने के लिए कॉन्फ़िगर करें।

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

जैसा कि यह है "यूएमडी शैली ग्लोबल्स की अनुमति दें" निश्चित रूप से एक विकल्प होना चाहिए।

सोम, अप्रैल 2, 2018 को दोपहर 1:40 बजे कागामी साशा रोशलाइट <
सूचनाएं@github.com> ने लिखा:

मुझे इसके साथ काम करना था:

/ * मॉड्यूल: es2015 * /
// js-yaml UMD का समर्थन करता है, लेकिन ES2015 मॉड्यूल का नहीं; "js-yaml" से _jsyaml के रूप में आयात *;

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की है।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/Microsoft/TypeScript/issues/10178#issuecomment-377885832 ,
या धागा म्यूट करें
https://github.com/notifications/unsubscribe-auth/AA50ljAD33sr09EGFVAsURbu1x75X-lOks5tkeQCgaJpZM4Jd8jX
।

>

डैनियल जॉयस

नम्र पृथ्वी के वारिस होंगे, क्योंकि बहादुर सितारों के बीच होंगे।

मैं एक कोणीय परियोजना में तीन .js का उपयोग कर रहा हूँ। मैं इसे आयात करता हूं

import * as THREE from "three";

import {Vector3} from "three"; भी उम्मीद के मुताबिक काम करता है।

three और @types/three npm संकुल स्थापित होने से, सब कुछ ठीक चलता है। हुड के तहत, मुझे लगता है कि यह three/build/three.module.js का उपयोग कर रहा है। @types/three/index.d.ts फ़ाइल संकेतन export as namespace THREE , जिसे मैं पूरी तरह से सहज नहीं हूं, लेकिन वह काम करता है।

इस विशेष मामले में, समस्या यह है कि तीन .js प्रणाली में एक और संबंधित फ़ाइल है, जिसे OrbitControls.js कहा जाता है (जो आपको मूल रूप से अपनी उंगली या माउस से 3 डी छवियों को घुमाने की अनुमति देता है)। समस्या यह है कि हालांकि यह फ़ंक्शन तीन.js वितरण का अर्ध-आधिकारिक हिस्सा है, यह examples वृक्ष में पाया जाने वाला एक सादा-पुराना JS फ़ाइल है और सीधे THREE संपत्ति पर स्थित है खिड़की का, और सीधे अन्य एपीआई का उपयोग करता है यह window.THREE पर मौजूद खोजने की अपेक्षा करता है। इसलिए भले ही मुझे फ़ाइल की "आवश्यकता" हो

require("three/examples/js/controls/OrbitControls.js");

यह window.THREE खुद को लगाने के लिए, या इसके उपयोग वाले THREE सिस्टम के अन्य हिस्सों तक पहुंचने के लिए नहीं मिल सकता है। मैं पूरी लाइब्रेरी को सीधे Angular scripts angular.json (लगभग एक पुराने जमाने के बराबर <script> टैग) का उपयोग करके शामिल कर सकता हूं, लेकिन तब अगर मुझे गलत नहीं समझा जाए लाइब्रेरी को दो बार लोड किया जाएगा।

उस से बचने के लिए, मैंने import * as THREE from "three"; स्टेटमेंट निकाला, और हे, यह अभी भी foo: THREE.Vector3 जैसे प्रकारों को हल कर सकता है, लेकिन कुख्यात के साथ new THREE.Vector3() जैसे संदर्भों पर चुटकुले

'THREE' एक UMD वैश्विक को संदर्भित करता है, लेकिन वर्तमान फ़ाइल एक मॉड्यूल है। इसके बजाय एक आयात जोड़ने पर विचार करें। [2686]

इस बिंदु पर मैं सोच रहा हूं कि मैं OrbitControls.js फ़ाइल और ES6-ify और / या TS-ify हड़पने जा रहा हूं, जो कि ऐसा लगता है कि एक से अधिक लोगों ने पहले ही कर लिया है 'ऑर्बिट-कंट्रोल-एसई 6' जैसी चीजों का रूप, इसलिए शायद मुझे अपने जीवन को सरल बनाना चाहिए और इसका उपयोग करना चाहिए, भले ही मुझे अपने जीवन को दूसरे लोगों के हाथों में रखने से नफरत हो।

एक अर्द्ध-असंबंधित नोट पर, एक विषमता यह है कि @types/three OrbitControls लिए प्रकार परिभाषित करता है, यहां तक ​​कि कोड के माध्यम से भी three मॉड्यूल में ही नहीं है। हालाँकि, मैं यह पता नहीं लगा सकता कि किसी भी चीज़ को OrbitControls परिभाषित करने वाले सभी प्रकार के सहयोगियों को किसी भी चीज़ के साथ कैसे जोड़ा जाए - मैं उपरोक्त orbit-controls-es6 के होने के डिफ़ॉल्ट निर्यात की घोषणा करना चाहूंगा इस प्रकार, लेकिन मुझे कैसे करना है।

आखिरकार मैं जो समाधान लेकर आया, जिससे मैं बहुत शर्मिंदा हूं, वह है:

import * as THREE from "three";
Object.defineProperty(window, "THREE", {get() { return THREE; }});
require("three/examples/js/controls/OrbitControls.js");

यह काम करता है, हालांकि मैं थोड़ा उलझन में हूं कि क्यों। आवश्यक फ़ाइल में एक पंक्ति है जैसे

THREE.OrbitControls = funtion() { };

ऐसा लगता है कि यह import * as THREE from "three"; कथन के परिणामस्वरूप होने वाले "नाम स्थान" को निर्दिष्ट करेगा, जो काम नहीं करना चाहिए?

@RyanCavanaugh ने मुझे यहाँ # 26223 से अपनी प्रतिक्रिया को कॉपी करने के लिए कहा:

मैं एक बड़ा टाइपस्क्रिप्ट कोड आधार (Google का आंतरिक मोनोरपो) बनाए रख रहा हूं जिसमें कई निश्चित रूप से टाइप किए गए पुस्तकालय हैं जो लोग निर्भर करते हैं। मूल रूप से उपयोगकर्ता केवल angular जैसे पुस्तकालयों के लिए वैश्विक प्रकारों पर भरोसा करेंगे, इससे पहले कि .d.ts बाहरी मॉड्यूल में बदल गए थे। हमने तब मॉड्यूल और स्पष्ट आयात का उपयोग करने के लिए कोड बेस माइग्रेट किया। हम वास्तव में उम्मीद करते थे कि export as namespace d UMD ग्लोबल्स को हमेशा प्रतीकों के उपयोग के लिए एक स्पष्ट आयात की आवश्यकता होगी, दोनों प्रकार और मूल्य संदर्भों के लिए, और जब हम माइग्रेट (व्हाट्सएप) करते हैं, तब भी वापस नोटिस नहीं किया।

कोड के गैर-आयातित उपयोग की अनुमति देना हमारे लिए आम तौर पर समस्याग्रस्त है:

• इसका मतलब है कि कोड वैश्विक "पृष्ठभूमि" प्रकार की परिभाषाओं पर निर्भर करता है, जिससे कोड को पढ़ना मुश्किल हो जाता है (विशेष रूप से रेपो ब्राउज़र या कोड समीक्षा w / o प्रतीक पर जाएं)।

• यह कोड निर्भरता को अस्पष्ट करता है

• यह कहता है कि "सभी आयातों पर स्पष्ट रूप से निर्माण स्तर निर्भरता होनी चाहिए" हम बाज़ल में लागू होने वाली बाधाओं, उर्फ ​​"सख्त डिप्स"।

  एक बड़े कोड बेस में, आपके कोड में स्पष्ट निर्भरताएं होनी चाहिए, अन्यथा रेपो असहनीय हो जाता है। अब यदि आपके पास A -> B -> C और वैश्विक प्रकारों का पीछा करने की निर्भरता है, तो कोड A संकलित करना आसान है क्योंकि B का C पर निर्भरता है। यदि B बाद में अपनी निर्भरता को हटा देता है, तो यह A टूट जाता है, जिसका अर्थ है कि परिवर्तनों का रिपोजिटरी पर अप्रत्याशित रिपल इफेक्ट होता है, जो कोड अलगाव का उल्लंघन करता है।

• यह कोड को असंगत रूप से मानों के लिए एक उपसर्ग के साथ मॉड्यूल आयात करने का कारण बनता है और इसके प्रकारों को दूसरे उपसर्ग के साथ उपयोग करता है (विशेष रूप से AngularJS, एनजी बनाम कोणीय)

हम निश्चित रूप से हमारे विक्रेता की प्रतिलिपि में उन export as namespace कथनों को हटाकर इसके चारों ओर काम कर सकते हैं, लेकिन कम से कम हमारे लिए, यह सुविधा कोड रखरखाव और हमारे इंजीनियरिंग लक्ष्यों के खिलाफ काम करने की तरह है। मुझे लगता है कि Google जैसी मोनोरेपो स्थिति में समस्याएं अधिक स्पष्ट हैं, लेकिन आम तौर पर छोटे कोड आधारों में भी लागू होती हैं।

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

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

खुला प्रश्न: क्या " सभी यूएमडी मॉड्यूलों तक पहुंच की अनुमति" के लिए एक वैश्विक झंडा पर्याप्त होगा, या क्या लोगों को वास्तव में त्रुटि पर प्रति-मॉड्यूल नियंत्रण की आवश्यकता है?

"सिर्फ एक ध्वज" के लिए वोट करें
"प्रति-मॉड्यूल नियंत्रण की आवश्यकता" के लिए वोट दें

मैं यह भी विचार कर रहा था कि क्या tsconfig.json में "types" विकल्प में एक स्पष्ट सूची की उपस्थिति भी एक मॉड्यूल में UMD उपयोग की अनुमति नहीं देनी चाहिए। यह दर्शाता है कि प्रकार जानबूझकर मौजूद है। (हालांकि स्पष्ट रूप से उस त्रुटि को शामिल नहीं किया गया है जिसे आप इसे आयात करना भूल गए हैं)।

या इसी तरह, एक /// <reference types="..." /> निर्माण का उपयोग करके उस पैकेज में UMD के उपयोग की अनुमति दी जानी चाहिए (जिसका उपयोग 'प्रति मॉड्यूल नियंत्रण' में किया गया है)।

@RyanCavanaugh # 26233 को संबोधित करने के लिए क्या कोई झंडा होगा?

26233 को पूरी तरह से काम करना माना जाता है; एक मॉड्यूल से एक UMD वैश्विक प्रकार के पक्ष तक पहुँच वैध रूप से हानिरहित है

मुझे यकीन नहीं है कि यह "वैध रूप से हानिरहित" है। उदाहरण के रूप में @types/jquery का उपयोग करना। $ और jQuery JQueryStatic इंटरफ़ेस में मैप किए जाते हैं और स्थिरांक के साथ निर्यात किए जाते हैं। नतीजतन, सभी मॉड्यूल आयात किए बिना $ और jQuery का उपयोग कर सकते हैं। मुझे उम्मीद है कि मैं इसे निष्क्रिय कर सकता हूं।

@RyanCavanaugh हाँ, यह इस अर्थ में हानिरहित है कि TS emit इससे प्रभावित नहीं होता है। यदि आप @types प्रत्येक लायब्रेरी तक पहुँच सकते हैं, तो यह ठीक प्रकार से दानेदार नियंत्रण चाहते हैं, तो यह समस्याग्रस्त है - यह कम से कम वैसा ही दिख रहा है जैसा कि मॉड्यूल वैश्विक प्रकारों में स्कोप्ड प्रकारों में दिखता है। चौड़ीकरण की समस्या एक समस्या हो सकती है, भले ही उत्सर्जन प्रभावित न हो।

वास्तव में jQuery के मामले में, उत्सर्जन प्रभावित होता है। $() एक आयात के बिना एक मॉड्यूल में उत्सर्जित होता है।

एक नए ध्वज के लिए पीआर को स्वीकार करना जो सभी मॉड्यूल से यूएमडी ग्लोबल्स तक पहुंच की अनुमति देता है।

कार्यान्वयन-वार, यह काफी सीधा है ... लेकिन हमें इसे नाम देने की आवश्यकता है। हमने सुझाव की समीक्षा बैठक में लगभग एक दर्जन भयानक नामों को लात मारी और उन सभी से नफरत की, इसलिए यह कुछ खास करने के लिए आने वाला है। कृपया रोकें।

हमने सुझाव की समीक्षा बैठक में लगभग एक दर्जन भयानक नामों को लात मारी और उन सभी से नफरत की

वे क्या कर रहे थे?

तो यह कुछ अच्छा करने के लिए आने के लिए y'all पर निर्भर है।

शायद umdUseGlobal या कुछ और।

मैं UMD वैश्विक ध्वज के नाम के लिए importAllNamespaces सुझाव दूंगा क्योंकि UMD ग्लोबल्स आमतौर पर export as namespace ।

@RyanCavanaugh टीम ने किस प्रकार के मुद्दे पर चर्चा की?

@FranklinWhale हाँ।

@saschanaz ने पहले ही पूछा, लेकिन मैं भी उत्सुक हूं ... @RyanCavanaugh क्या आपको याद है कि भयानक नामों पर चर्चा की गई थी?

मुझे लगता है कि चेन कुछ इस तरह से चली गई

• allowUmdGlobalAccessFromModules - सबसे सटीक लेकिन soooooo लंबा
• assumeGlobalUmd - ऊग
• allowModuleUmdGlobals - "ग्लोबल्स" ??
• umdAlwaysGlobal -
• allowUmdGlobals - लेकिन मैं पहले से ही कर सकता हूं?
• allowUmdGlobalAccess - मॉड्यूल हिस्सा छोड़ देता है लेकिन शायद कोई परवाह नहीं करता है?

अगर मुझे मजबूर किया जाता है तो मैं अंतिम एक को चुनूंगा

धन्यवाद!

मुझे allowUmdGlobalAccessFromModules सबसे अच्छा लगता है क्योंकि, हालांकि यह लंबा है, इसकी सटीकता को याद रखना आसान बनाता है। मुझे लगता है, "ऐसा क्या विकल्प है जो यूएमडी ग्लोबल्स को मॉड्यूल से एक्सेस करने की अनुमति देता है? अरे हाँ, यह allowUmdGlobalAccessFromModules , बिल्कुल!"

उपसर्ग "अनुमति" का उपयोग अन्य विकल्पों के नामकरण सम्मेलन से मेल खाता है, जो अच्छा है।

प्लस ... अन्य विकल्प हैं जो लंबे समय तक हैं :)

allowUmdGlobalAccessFromModules : 31 वर्ण

allowSyntheticDefaultImports : 28 अक्षर
strictPropertyInitialization : 28 अक्षर
suppressExcessPropertyErrors : 28 अक्षर
suppressImplicitAnyIndexErrors : 30 अक्षर
forceConsistentCasingInFileNames : 32 अक्षर

वर्तमान वर्कअराउंड क्या है? मैं पिछले एक घंटे से गुगली कर रहा हूं और कोई काम करने योग्य उपाय नहीं खोज पा रहा हूं।
मैं नहीं बल्कि किसी भी काम कर रहे टाइपस्क्रिप्ट संस्करण के लिए 'कोई' या डाउनग्रेड करने के लिए नहीं बल्कि कोई अन्य विकल्प नहीं मिल सकता है।
क्या कहीं एक प्रायोगिक निर्माण है जिसमें एक संकलक ध्वज है जो इस समस्या को ठीक करता है?
(वैसे, 'allowUmdGlobalAccessFromModules' एक उत्कृष्ट नाम है; ऐसा नहीं है कि हम इसे दिन में 50 बार टाइप करना चाहते हैं :-))

हम tsc 3.2.2 का उपयोग कर रहे हैं, जो कि शीर्ष HTML फ़ाइल में वैधानिक रूप से शामिल है; आवश्यकता के साथ। js; डी। नवीनतम से निश्चित रूप से प्राप्त। उदाहरण कोड जो संकलन में विफल रहता है:

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

class Example<T extends IThingWithTitle<T>> {

    public test = (arg : T[]) : void => {
        _.sortBy(arg, (el : T) => { return el.title; }); // TS2686: '_' refers to a UMD global, but the current file is a module. Consider adding an import instead.
    };

}

export = Example;

(कृपया मुझे मत बताओ कि मुझे परियोजना को उल्टा करने की आवश्यकता है, मुझे पता है कि हम कुछ पहलुओं में वक्र के पीछे हैं)

अपडेट करें: ((window) ._) / * FIXME https://github.com/Microsoft/TypeScript/issues/10178 * /। SortBy (...) काम करता है, लेकिन प्रिय भगवान, यह बदसूरत है :-P

@ गिले , इस टिप्पणी से समाधान अभी के लिए ठीक काम करता है: https://github.com/Microsoft/TypeScript/issues/10178#issuecomment -263030856

क्या इस पर कोई प्रगति हुई है? मेरे पास एक ऐसा मामला है जहाँ उल्लेखित काम-काज काम नहीं करता है ( [email protected] का उपयोग करके) क्योंकि मैं इस मुद्दे पर चल रहा हूँ।

पहले मैंने यह कोशिश की:

import 'firebase';

declare global {
  const firebase;
}

यह स्पष्ट रूप से वैश्विक firebase प्रकार any , और फिर उस पर नामस्थान (समान नाम के साथ) लागू होता है। पहले यह काम करने के लिए लग रहा था क्योंकि यह firebase सभी शीर्ष-स्तरीय कुंजियों के लिए उचित टूलटिप्स / इंटेलीसेंस दिखाता है।

हालाँकि यह वास्तव में काम नहीं करता है (मुझे लगता है क्योंकि यह तब any रूप में उपयोग करने के लिए स्विच करता है, जो बग हो सकता है ?::

इसलिए मैंने सफलता के बिना यहां बताए गए वर्कअराउंड की कोशिश की (हालांकि यह दूसरों के लिए काम करता है):

import _firebase from 'firebase'; // same with = require('firebase') 

declare global {
  const firebase: typeof _firebase;
}

=> 'फायरबेस' को प्रत्यक्ष या अप्रत्यक्ष रूप से अपने प्रकार के एनोटेशन में संदर्भित किया जाता है।
(हालांकि नाम स्थान अलियास है?)

मैंने भी कोशिश की

import * as _firebase from 'firebase';

declare global {
  const firebase: typeof _firebase;
}

=> आयात उर्फ ​​'_firebase' की सर्कुलर परिभाषा।
(शायद इसकी परिभाषा में export = firebase; export as namespace firebase; होने के कारण ?)

और अंत में, अगर मैं सिर्फ import 'firebase' हूं, तो मैं वापस आ गया हूं

'फायरबेस' एक यूएमडी वैश्विक को संदर्भित करता है, लेकिन वर्तमान फ़ाइल एक मॉड्यूल है। [2686]

यदि किसी के पास इसके लिए कोई समाधान है, तो यह बहुत सराहनीय होगा। अन्यथा इसे हल करने के किसी भी सुझाव का जो अब तक उल्लेख किया गया था, वह मुझे वास्तव में ठीक लगता है (झंडा, ट्रिपल स्लैश संदर्भ, types tsconfig में, global या external वस्तु) tsconfig में)।

री @aluanhaddad की टिप्पणी

यह सब इस नस में नहीं गया है और ग्लोबल्स पर वापस जा सकता है!

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

यह वास्तव में जोड़ने के लिए एक बहुत आसान सुविधा है; यह एक समुदाय के सदस्य के लिए इसे लेने के लिए बहुत अच्छा होगा।

@RyanCavanaugh मैं इस पर देखा और सोचा की तरह मैं करने के लिए विकल्प जोड़ने के लिए बाहर compiler/types.ts और में UMD वैश्विक जांच संशोधित compiler/checker.ts , और मैं मैं करने के लिए इसे जोड़ने की जरूरत है लगता है compiler/commandLineParser.ts रूप में अच्छी तरह से ... लेकिन मुझे लगता है कि इसे पूरा करने में मुझे काफी समय लगेगा क्योंकि मैं स्रोत से बिल्कुल भी परिचित नहीं हूं (जैसे मैं i18n को तोड़े बिना CLI ध्वज के लिए विवरण कैसे जोड़ूं) । अभी के लिए मैं किसी और के लिए इंतजार करने जा रहा हूं जो पहले से ही इसे लेने के लिए स्रोत जानता है।

@simonhaenisch आप इसे गैर-मॉड्यूल घोषणा फ़ाइल में घोषित कर सकते हैं, और परिपत्र संदर्भ से बचने के लिए, आप इसे दूसरे UMD मॉड्यूल घोषणा में फिर से निर्यात कर सकते हैं। मूल firebase को एक नाम स्थान के रूप में घोषित किया गया है, हमारे लिए भाग्यशाली है, यह हमारी घोषणा को बढ़ाएगा, त्रुटि पैदा नहीं करेगा।

// umd.d.ts
import firebase = require("firebase");
export import firebase = firebase;
export as namespace UMD;

// global.d.ts
declare const firebase: typeof UMD.firebase;

दुर्भाग्य से, हमने जो घोषित किया है, वह एक नाम स्थान है, न कि नाम स्थान, इसलिए आप let x: firebase.SomeInterface जैसा कुछ नहीं कर सकते हैं, नाम बदलने का एकमात्र तरीका आयात घोषित करके है, लेकिन आप declare import firebase = UMD.firebase; नहीं कर सकते हैं

पिछली टिप्पणी के समान, हम आलसी-लोडिंग hls.js (UMD) और संदर्भ प्रकार इस प्रकार हैं:

hls.d.ts :

import * as Hls from 'hls.js';
declare global {
    const Hls: typeof Hls;
}

आलसी लोडेड UMD मॉड्यूल का उपयोग करके .ts फ़ाइल में:

/// <reference path="hls.d.ts" />
// now use it
if(Hls.isSupported()){
 ...
} 

टाइपस्क्रिप्ट> = 3.0.1 और 3.4.1 में परीक्षण किया गया।

गतिशील मॉड्यूल आयात के लिए राशन अधूरा ब्राउज़र समर्थन है।

@MatthiasHild /// <reference path="hls.d.ts" /> टिप्पणी के बिना किया जा सकता है?

संपादित करें, हाँ, यह तब तक हो सकता है, जब तक कि घोषणा में .d.ts फ़ाइल शामिल न हो, जिसमें समान SO .ts प्रश्न के आधार पर .ts फ़ाइल के समान नाम न हो, (जो मुझे मिल रहा था) और मैंने क्यों पूछा)।