यहाँ ClassA की केवल एक मूल घोषणा है, इसलिए यह त्रुटि नहीं होनी चाहिए।

खैर, क्षमा करें मैंने पाया कि यह npm link ।

जब मैं npm link उपयोग करता हूं, तो पैकेज नीचे स्थापित किए जाते हैं, क्योंकि यह केवल प्रतीकात्मक लिंक बनाता है।

package-c
|
-- node_modules
    |
    -- package-a
    |   |
    |   -- index.d.ts
    |   |
    |   ...
    |
    -- package-b
        |
        -- index.d.ts
        |
        -- node_modules
        |   |
        |   -- package-a
        |       |
        |       -- index.d.ts
        |       |
        |       ...
        |
        ...

जैसा कि दिखाया गया है, ऐसा लगता है कि पैकेज-ए के लिए दो अलग-अलग घोषणा फाइलें हैं।
यदि मैं npm install का उपयोग करके सामान्य रूप से पैकेज स्थापित करता हूं, तो ऐसा नहीं होता है क्योंकि पैकेज-ए की घोषणा इस मामले में पैकेज-बी में शामिल नहीं है।

मुझे उम्मीद है कि इसके लिए कुछ समाधान होगा, लेकिन यह मुश्किल और कम प्राथमिकता हो सकती है।

मैंने npm link का उपयोग नहीं किया, और यह मेरे लिए और अधिक मायने नहीं रखता।

काफी उचित है, लेकिन किसी और को हो सकता है: पलक:

वास्तव में ClassA की दो घोषणाओं के साथ डिस्क पर दो फाइलें हैं। इसलिए त्रुटि सही है। लेकिन हमें नोड मॉड्यूल पर विचार करने की आवश्यकता है जब हम इन प्रकारों की तुलना करते हैं। यह समस्या https://github.com/Microsoft/TypeScript/issues/4800 से पहले बताई गई है, Enums के लिए हमने नियम को अर्ध-नाममात्र चेक में बदल दिया है। संभवतः कक्षाओं के लिए भी ऐसा ही करें।

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

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

EDIT: यह स्पष्ट कर दिया कि NPM लिंक मेरे मामले में चल रहा है

अधिसूचित टीएस 1.8 उपलब्ध है, उन्नत है और यह समस्या उस संस्करण में भी मौजूद है।

इस मुद्दे के विश्लेषण और दस्तावेजीकरण में सभी कार्यों के लिए धन्यवाद। हमारे कुछ कोड बेस में यही समस्या है। हमने कुछ परियोजनाओं को package.json निर्भरता का ठीक से उपयोग करने के लिए पोर्ट किया था, लेकिन अब विकास के दौरान npm link का उपयोग करते समय इसे देख रहे हैं।

क्या इस मुद्दे को हल करने में मेरी मदद की जा सकती है?

मैं Lerna का उपयोग कर रहा हूँ जो चारों ओर सहानुभूति रखता है और इस मुद्दे को भी देख रहा है। टाइपस्क्रिप्ट संस्करण 2.0.3।

दुर्भाग्य से लारना और इसके सिम्बलिंक एक कठिन आवश्यकता है, इसलिए मैंने उपभोक्ताओं को इसे ठीक से संकलित करने के लिए इसे प्राप्त करने के लिए इस खराब वर्कअराउंड का उपयोग किया, जबकि उपभोक्ताओं द्वारा अभी भी ठीक प्रकार से जांच की जा रही है:

export class MyClass {
  constructor(foo: Foo) {
    (this as any)._foo = foo;
  }

  get foo() {
    return (this as any)._foo as Foo;
  }
}

वर्ग बहुत छोटा है इसलिए यह कठिन नहीं था, और मैं इसे वास्तव में कभी भी बदलने की उम्मीद नहीं करता, यही कारण है कि मैं इसे एक स्वीकार्य बदलाव मानता हूं।

FYI करें, मैंने भी npm link और यह त्रुटि प्राप्त करने के परिणामस्वरूप समाप्त किया है। क्या किसी ने इसके लिए वर्कअराउंड पाया है?

@xogeny क्या आप

@mhegazy खैर मुझे ऊपर की तरह ये त्रुटियां होने लगीं (सिवाय इसके कि मैं Observable rxjs का उपयोग कर रहा था, अर्थात, "Observable 'टाइप करने के लिए" ऑब्जर्वेबल' टाइप करने योग्य नहीं है।) बेशक, अजीब लग रहा था क्योंकि दोनों मैं Observable मॉड्यूल में rxjs । लेकिन जहां प्रकार "मिले", मुझे एक त्रुटि मिली। मैंने चारों ओर खोदा। अंततः यह मुद्दा मिला जहां @kimamula ने कहा कि यदि आप npm link , तो आपको यह त्रुटि मिलेगी। मैं, अन्य लोगों की तरह, इसके चारों ओर काम किया (मेरे मामले में, मैंने केवल कार्यक्षमता का एक डुप्लिकेट इंटरफ़ेस बनाया। एक मॉड्यूल में आवश्यक, संदर्भ rxjs बजाय)।

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

हमने TS2.0 में विशेष रूप से npm link परिदृश्य (https://github.com/Microsoft/TypeScript/pull/8486 और # 8346) को सक्षम करने के लिए काम किया है। क्या आपके पास एक नमूना है जहां मैं देख सकता हूं कि npm लिंक अभी भी आपके लिए काम नहीं कर रहा है?

हुह। मैं 2.0.3 चला रहा हूँ (मैंने जाँच की)। मैं एक प्रतिलिपि प्रस्तुत करने योग्य मामला बनाने की कोशिश करूँगा।

वैसे, आपको इन थ्रेड्स का पालन करना चाहिए क्योंकि वे कहते हैं कि यह अभी भी टीएस 2.0 के रूप में एक मुद्दा है:

https://github.com/ReactiveX/rxjs/issues/1858
https://github.com/ReactiveX/rxjs/issues/1744

मेरे लेर्ना रेपो में जो मुद्दा मैं देख रहा हूं वह कुछ हद तक शामिल है, इसलिए मैंने https://github.com/seansfkelley/typescript-lerna-webpack-sadness पर इसका एक स्ट्रिप-डाउन संस्करण बनाया https://github.com/TypeStrong/ts-loader/issues/324 वहाँ पर भी दायर किया है।

मैं टाइपस्क्रिप्ट 2.0.3 का उपयोग कर रहा हूं और मैं इस त्रुटि को अवलोकन के साथ देख रहा हूं जैसा कि ऊपर वर्णित है, उदाहरण के लिए

Type 'Observable<Location[]>' is not assignable to type 'Observable<Location[]>'. Property 
            'source' is protected but type 'Observable<T>' is not a class derived from 'Observable<T>'.

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

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

यह उन मामलों में सबसे अधिक ध्यान देने योग्य है जहां आपके पास एक ऐप है जो डिपेंडेंसी ए पर निर्भर करता है, डिपेंडेंसी ए डिपेंडेंसी बी पर निर्भर करता है और ऐसे ऑब्जेक्ट्स पर निर्भर करता है जिनमें डिपेंडेंसी बी से टाइप होते हैं। ऐप और डिपेंडेंसी ए दोनों npm link डिपेंडेंसी बी और होने की उम्मीद करते हैं। इससे प्रकार आयात करने में सक्षम है और उन्हें एक ही बात का वर्णन है।

इससे गहरी त्रुटि संदेश मिलता है, और मैं अपने पुस्तकालयों में private और protected प्रॉपर्टीज़ के माध्यम से जाने और समाप्त करने के कगार पर हूं क्योंकि मैं पहले ही इसके लिए इतना समय खो चुका हूं :

TSError: ⨯ Unable to compile TypeScript
tests/helpers/test-application.ts (71,11): Argument of type '{ initializers: Initializer[]; rootPath: string; }' is not assignable to parameter of type 'ConstructorOptions'.
  Types of property 'initializers' are incompatible.
    Type 'Initializer[]' is not assignable to type 'Initializer[]'.
      Type 'Application.Initializer' is not assignable to type 'Application.Initializer'.
        Types of property 'initialize' are incompatible.
          Type '(app: Application) => void' is not assignable to type '(app: Application) => void'.
            Types of parameters 'app' and 'app' are incompatible.
              Type 'Application' is not assignable to type 'Application'.
                Types of property 'container' are incompatible.
                  Type 'Container' is not assignable to type 'Container'.
                    Types of property 'resolver' are incompatible.
                      Type 'Resolver' is not assignable to type 'Resolver'.
                        Types of property 'ui' are incompatible.
                          Type 'UI' is not assignable to type 'UI'.
                            Property 'logLevel' is protected but type 'UI' is not a class derived from 'UI'. (2345)

वास्तव में आप सभी की सराहना इस में देख; धन्यवाद!

@tomdale क्या आप Webpack, tsc या किसी अन्य बिल्ड टूल का उपयोग कर रहे हैं? मेरा मुद्दा केवल तब होता है जब वेबपैक के माध्यम से संकलित किया जाता है (मेरी पिछली टिप्पणी से लिंक किए गए रेपो देखें)।

@seansfkelley जो https://github.com/TypeStrong/ts-node की तरह दिखता है

यह सही है, यह ts-node (रूट एप्लिकेशन के लिए) का उपयोग कर रहा है। हालाँकि, निर्भरता tsc साथ संकलित पैकेज हैं।

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

// in repo A
export class HttpAdapter {
    request(url: string, options?: HttpRequestOptionsArgs): Observable<HttpResponse> {
        return Observable.of({});
    }
}

// in repo B
export class HttpRequestAdapter implements HttpAdapter {
    request(url: string, options?: HttpRequestOptionsArgs): Observable<HttpResponse> {
        return Observable.of({});
    }
}

यह काम करता है अगर मैं npm link नहीं करता हूं, लेकिन जब मैं करता हूं, मुझे मिलता है:

Error:(10, 14) TS2420:Class 'HttpRequestAdapter' incorrectly implements interface 'HttpAdapter'.
  Types of property 'request' are incompatible.
    Type '(url: string, options?: HttpRequestOptionsArgs) => Observable<HttpResponse>' is not assignable to type '(url: string, options?: HttpRequestOptionsArgs) => Observable<HttpResponse>'.
      Type 'Observable<HttpResponse>' is not assignable to type 'Observable<HttpResponse>'.
        Property 'source' is protected but type 'Observable<T>' is not a class derived from 'Observable<T>'.

एकमात्र सुझाव जो मैं बना सकता हूं वह है private से बचना। मैं इस मुद्दे के कारण private साथ किसी भी पैकेज को प्रकाशित नहीं करता हूं और इसके बजाय केवल जावास्क्रिप्ट-शैली _ उपसर्ग का उपयोग करता हूं। मैं इसे https://github.com/Microsoft/TypeScript/issues/7755 के साथ चलाता हूं, जो इसी तरह की चर्चा है कि क्यों private संरचनात्मक के बजाय नाममात्र प्रकार की प्रणाली में किक करता है, और इसलिए इसे मेरे लिए प्रतिबंधित कर दिया है खुद की परियोजनाएं क्योंकि संस्करण अंतर (जैसे एनपीएम 2 या npm link ) का उपयोग करना बहुत आसान है।

@blakeembrey जब आप कहते हैं कि निजी से बचें, तो क्या आप सुझाव देते हैं कि मैं अपने कोड में कुछ बदल सकता हूं? मैं मान रहा हूं कि ऑब्जर्वेबल टाइप की परिभाषा समस्या है, नहीं?

@ जेफ़ अप्रोली हाँ, क्षमा करें, आपकी गलती पर नहीं। यह Observable । दुर्भाग्य से private सलाह बहुत ही पतली है और आपके लिए पूरी तरह से लागू नहीं है rxjs के उपयोग के बारे में private उनके सार्वजनिक इंटरफेस में

संपादित करें: मैंने ज्यादातर टिप्पणी की क्योंकि मैंने पहले इस मुद्दे का पालन किया था और अपने स्वयं के अनुभवों के साथ जुड़ने से बचा था, लेकिन लगा कि मैं अपने विचारों को फिर से लिख सकता हूं बजाय इसके कि वे https://github.com/Microsoft/TypeScript/issues/ के समान हैं @tomdale ने private और protected समाप्त करने का सुझाव दिया, मैंने कुछ समय पहले ही ऐसा किया था)।

मुझे @mhegazy से npm link साथ कोई समस्या नहीं है। लेकिन यह अभी भी हमें और दूसरों को परेशान करने वाला लगता है। इसलिए मुझे यकीन नहीं है कि यह मुद्दा कहां है? क्या यह टीएस 2.0+ के साथ एक स्वीकृत मुद्दा है या मैं सिर्फ कहीं एक समाधान याद कर रहा हूँ?

मुझे यह वही मुद्दा मिल रहा है और यह npm link कारण प्रतीत नहीं होता है। अगर मैं npm install file.tar.gz का उपयोग करके इसे स्थापित करता हूं, तो भी मुझे मिल जाएगा। यहाँ त्रुटि है:

app/app.component.ts(46,5): error TS2322: Type 'Observable<boolean | Account>' is not assignable to type 'Observable<boolean | Account>'.
  Property 'source' is protected but type 'Observable<T>' is not a class derived from 'Observable<T>'.

यहाँ मेरा app.component.ts जैसा दिखता है:

export class AppComponent implements OnInit {
  private user$: Observable<Account | boolean>;
  private loggedIn$: Observable<boolean>;
  private login: boolean;
  private register: boolean;

  constructor(public stormpath: Stormpath) {}

  ngOnInit() {
    this.login = true;
    this.register = false;
    this.user$ = this.stormpath.user$;
    this.loggedIn$ = this.user$.map(user => !!user);
  }

यह this.user$ लाइन के बारे में शिकायत कर रहा है। Stormpath में user$ निम्नलिखित के रूप में परिभाषित किए गए हैं:

@Injectable()
export class Stormpath {

  user$: Observable<Account | boolean>;

@xogeny Odd, मेरी समझ यह थी कि परिभाषा की पहचान फ़ाइल स्थान से जुड़ी हुई थी, जिसका अर्थ है कि वे हमेशा npm link का उपयोग करके मुद्दों का कारण बनने वाले हैं (क्योंकि npm link ed निर्भरता के कारण यह स्वयं निर्भरता स्थापित होगी) । शायद परिभाषा पहचान को बदल दिया गया है - फ़ाइल हैश का उपयोग करना टाइपस्क्रिप्ट में एक अच्छा समाधान हो सकता है। दुर्भाग्य से जावास्क्रिप्ट में डुप्लिकेट मॉड्यूल ( npm install GitHub से, npm install , मैनुअल क्लोन के साथ समाप्त करने के लिए बस एक दर्जन अलग-अलग तरीके हैं, संस्करण संघर्ष भी भिन्न संस्करण में समान संस्करण लैंडिंग के परिणामस्वरूप हो सकते हैं। नोड के मॉड्यूल रिज़ॉल्यूशन एल्गोरिदम कैसे काम करता है, आदि)।

@blakeembrey शायद। लेकिन फिर यह किस बारे में था?

ध्यान दें, मैं शिकायत नहीं कर रहा हूं। मैं सिर्फ यह पता लगाने की कोशिश कर रहा हूं कि क्या इसके हल होने की कोई उम्मीद है या नहीं। यह हमारे पक्ष में एक गंभीर कांटा के लिए है सभी कारणों का उल्लेख किया @jeffwhelpley।

@xogeny मुझे पता है, मैं भी कोशिश कर रहा हूं, मैं इसे सही तरीके से हल करके देखना पसंद करूंगा the मैंने लिंक किए गए मुद्दों को पढ़ा, लेकिन यह सब एक npm link एक दूसरे में डालते हैं क्योंकि दोनों की अपनी निर्भरताएं होती हैं जो npm link ed पैकेज से पुन: निर्यात किए गए प्रतीकों के साथ भिन्न हो सकती हैं।

संपादित करें: मैं पुष्टि कर सकता हूं, सभी मुद्दे दो फाइलों के कारण हैं। npm link इसे ट्रिगर कर देगा क्योंकि रेपो में निर्भरता का होना सरल है जो आपने अभी लिंक किया है वह भी उसी तरह की निर्भरता है जिस परियोजना से आप जुड़े हैं। एक साधारण रिप्रो एक आवेदन के दो अलग-अलग स्तरों पर एक ही निर्भरता का npm install करना होगा और त्रुटि को देखना होगा।

इस धागे का अनुसरण करने वाले किसी भी व्यक्ति के लिए ... मैंने यहां बताए गए वर्कअराउंड की कोशिश की और यह (अब तक) काम करने लगता है।

मैंने इस त्रुटि को पुन: पेश किया है।

mkdir a; cd a
npm install rxjs
echo 'import * as rx from "rxjs"; export const myObservable: rx.Observable<number>;' > index.d.ts
echo '{ "name": "a" }' > package.json

cd ..; mkdir b; cd b
npm install rxjs
npm link ../a
echo 'import * as rx from "rxjs"; import * as a from "a"; const x: rx.Observable<number> = a.myObservable;' > index.ts
tsc index.ts --target es6 --moduleResolution node

चूँकि rxjs दो इंस्टॉलेशन हैं,

index.ts(1,59): error TS2322: Type 'Observable<number>' is not assignable to type 'Observable<number>'.
  Property 'source' is protected but type 'Observable<T>' is not a class derived from 'Observable<T>'.

मेरे पास एक वर्कअराउंड है जो कमांडलाइन के लिए बहुत अच्छा काम करता है, लेकिन विज़ुअल स्टूडियो अभी भी सभी गड़बड़ कर देता है: https://github.com/Microsoft/TypeScript/issues/11107#issuecomment -254003380

विंडोज + विज़ुअल स्टूडियो 2015 के लिए मेरा नया काम है मेरी xlib लाइब्रेरी src और dist node_modules\xlib\src node_modules\xlib\dist खपत की परियोजना।

अगर कोई भी यह चाहता है तो मेरी रॉबोकॉपी बैच फ़ाइल स्क्रिप्ट का महत्वपूर्ण हिस्सा है:

:rerunloop
    <strong i="14">@echo</strong> watching for changes to project files..............  (Ctrl-C to cancel)

    <strong i="15">@rem</strong> xlib --> blib and slib
    <strong i="16">@robocopy</strong> .\xlib\src .\blib\node_modules\xlib\src *.*  /MIR /NJH /NJS /NDL /XD .git
    <strong i="17">@if</strong> NOT "%errorlevel%" == "0" (
        <strong i="18">@rem</strong> copy occured, so copy both

        <strong i="19">@robocopy</strong> .\xlib\dist .\blib\node_modules\xlib\dist *.*  /MIR /NJH /NJS /NDL /XD .git   
        <strong i="20">@robocopy</strong> .\xlib\src .\slib\node_modules\xlib\src *.*  /MIR /NJH /NJS /NDL /XD .git     
        <strong i="21">@robocopy</strong> .\xlib\dist .\slib\node_modules\xlib\dist *.*  /MIR /NJH /NJS /NDL /XD .git

        <strong i="22">@rem</strong>  set the src dirs readonly
        <strong i="23">@attrib</strong> +R .\blib\node_modules\xlib\src\*  /S /D
        <strong i="24">@attrib</strong> +R .\slib\node_modules\xlib\src\*  /S /D
    )
    <strong i="25">@timeout</strong> /t 1 /nobreak > NUL
<strong i="26">@goto</strong> rerunloop

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

मैं भी इससे जूझ रहा हूं। हमने टीएस को एक छोटे से ऐप से शुरू किया है, अब हमने इसे सबमॉड्यूल में विभाजित कर दिया है और इन्हें… और बूम से जोड़ा है। टीएस अब संकलन नहीं करेगा। क्या यह अभी भी सभी टीएस डिस्ट-टैग में एक मुद्दा है? मैं वर्तमान में @rc (2.1.1) में यह अनुभव कर रहा हूं।

@heruan और @ जेफ ओवरप्ले आप typescript@next एक कोशिश दे सकते हैं, हमने कुछ संबंधित मुद्दे तय किए हैं। और यदि आप अभी भी समस्या देख रहे हैं, तो कृपया अपने प्रोजेक्ट सेटअप के बारे में अधिक जानकारी प्रदान करें।

@mhegazy मैं Version 2.2.0-dev.20161129 हूं और अभी भी समस्या है। विशिष्ट मुद्दा यह है कि मेरे पास एक परियोजना है (चलो इसे प्रोजेक्टए कहते हैं) जिसमें एक "इंटरफ़ेस" (एक वर्ग का उपयोग किया जाता है, लेकिन ऐसा है कि मैं कक्षा को एक कोण के रूप में 2 डीआईजी के लिए उपयोग कर सकता हूं) निम्नानुसार है:

export class ServerAdapter {
    start(opts: ServerOptions): Observable<any> {
        return null;
    }
}

फिर एक पूरी तरह से अलग परियोजना में (इसे प्रोजेक्टबी कहते हैं) जिसमें एक वर्ग है जो इस तरह की पहली परियोजना से इंटरफ़ेस को लागू करता है:

export class RestifyServerAdapter implements ServerAdapter {
    start(opts: ServerOptions): Observable<any> {
        let server = restify.createServer();
        this.addPreprocessors(server);
        this.addRequestHandler(server, opts);
        return this.startServer(server, opts);
    }

   // more stuff here that is not relevant to this issue
}

जब मैं ProjectB के लिए एक सामान्य टाइपस्क्रिप्ट संकलन करता हूं तो यह ठीक काम करता है। लेकिन अगर मैं npm link ProjectA ProjectB रूट निर्देशिका से और फिर से चलाने के tsc फिर से मुझे मिलता है:

Types of property 'start' are incompatible.
    Type '(opts: ServerOptions) => Observable<any>' is not assignable to type '(opts: ServerOptions) => Observable<any>'. Two different types with this name exist, but they are unrelated.
      Type 'Observable<any>' is not assignable to type 'Observable<any>'. Two different types with this name exist, but they are unrelated.
        Property 'source' is protected but type 'Observable<T>' is not a class derived from 'Observable<T>'.

मैं एक नकली परियोजना में नकल नहीं कर सकता, मुझे लगता है कि मैं समस्या का कारण याद कर रहा हूं इसलिए मैं इसे दोहराने में असमर्थ हूं। @ जेफ ओवरप्ले क्या आप इस मुद्दे की नकल करते हुए एक नकली प्रोजेक्ट प्रकाशित कर सकते हैं? मुझे लगता है कि एक लर्ना परियोजना ठीक और आसानी से परीक्षण योग्य होनी चाहिए।

@heruan मैं इसे स्थापित करने का प्रयास करूंगा।

एक, FYI, हालांकि। मुझे लगता है कि मुझे आसपास कोई काम मिल गया होगा। प्रॉब्लम को हल किया जाता है अगर मैं ProjectA और ProjectB दोनों में npm link rxjs हो। इस प्रकार की समझ में आता है क्योंकि उस स्थिति में, ProjectA और ProjectB दोनों एक ही सटीक rxjs फ़ाइलों का उपयोग कर रहे हैं। इसके बिना, वे तकनीकी रूप से विभिन्न फ़ाइलों का उपयोग कर रहे हैं (भले ही एक ही संस्करण):

यदि आप ProjectB से सिर्फ npm link ProjectA लेते हैं, तो:

• ProjectB नोड_modules / rxjs की ओर इशारा कर रहा है
• ProjectA नोड_मॉड्यूल्स / प्रोजेक्टए में एक सिम्लिंक के रूप में मौजूद है और यह जिन संदर्भों में है, वह नोड_मॉड्यूल्स / प्रोजेक्टए / नोड_मॉड्यूल्स / आरएक्सजे में मौजूद है

लेकिन अगर आप दोनों में npm link rxjs , तो उन दोनों आरएक्सजेएस संदर्भों को समान रूप से वैश्विक एनपीएम स्थान पर सहानुभूति दी जाएगी।

वैसे भी, यह स्पष्ट रूप से अभी भी आदर्श नहीं है, लेकिन कम से कम कुछ ऐसा है जो हमें आगे बढ़ा सकता है।

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

संकेत के लिए @Jffreadpley धन्यवाद, लेकिन जब से मैं

यहाँ कोई भी इसे सुरुचिपूर्ण तरीके से हल करने में सक्षम है?

इसके अलावा, ध्यान दें कि यह केवल npm link साथ एक समस्या नहीं है, आपको यह समस्या प्रोडक्शन बिल्ड पर भी मिलेगी, जब आपकी साझा निर्भरता एक अलग संस्करण की ओर इशारा करती है।

अर्थात। ProjectA को [email protected] और ProjectB [email protected] का उपयोग करता है

जब आप ProjectA को एक निर्भरता के रूप में ProjectB में स्थापित करते हैं, तो आपके पास भी डुप्लिकेट किए गए प्रकार होंगे, क्योंकि उदाहरण के लिए दो Observable घोषणाएँ होंगी, एक node_modules/rxjs और एक node_modules/project_a/node_modules/rxjs

आप ProjectA में rxjs संस्करण को ~4.9.0 कुछ होने की अनुमति देकर इसके आसपास प्राप्त कर सकते हैं, ताकि npm install को अपना स्वयं का संस्करण डाउनलोड करने की आवश्यकता न हो, और इसके बजाय ProjectB संस्करण का उपयोग करेगा। लेकिन ध्यान रखें कि यह न केवल एक विकास कार्यप्रवाह मुद्दा है।

@ Andy-ms के सुझाव के अनुसार यहां पोस्टिंग। कल फिर से नवीनतम 2.0.x के साथ कोशिश की और अभी भी यह था।

मैं इसे Angular 1 के लिए टाइपिंग के साथ प्राप्त कर रहा हूं: https://github.com/DefinitelyTyped/DefinitelyTyped/issues/10082#issuecomment -253023107

आज फिर से भाग गया, विशेष रूप से सहानुभूति के साथ समस्या। मेरा सेटअप कुछ इस तरह है:

node_modules/
folder
  another_folder
    node_modules/ (symlinked to ../../node_modules)
    app/ (angular1 app in typescript)
    tsconfig.json
    (other build files)

अगर मेरे पास @types/angular , tsc ठीक चलता है। अगर मेरे पास पूरा सूट ( @types/angular-{animate,cookies,mocks,resource,route,sanitize} ) है तो मुझे टाइप त्रुटियों का भार मिलना शुरू हो जाता है:

$ npm run tsc

> [email protected] tsc D:\work\angular.io\public\docs\_examples\upgrade-phonecat-1-typescript\ts
> tsc

../../node_modules/@types/angular/index.d.ts(17,21): error TS2300: Duplicate identifier 'angular'.
../../node_modules/@types/angular/index.d.ts(18,21): error TS2300: Duplicate identifier 'ng'.
app/app.animations.ts(5,3): error TS2339: Property 'animation' does not exist on type 'IModule'.
app/app.config.ts(6,45): error TS2305: Module 'angular' has no exported member 'route'.
app/core/checkmark/checkmark.filter.spec.ts(5,22): error TS2339: Property 'mock' does not exist on type 'IAngularStatic'.
app/core/phone/phone.service.spec.ts(18,22): error TS2339: Property 'mock' does not exist on type 'IAngularStatic'.
app/core/phone/phone.service.spec.ts(23,18): error TS2339: Property 'expectGET' does not exist on type 'IHttpBackendService'.
app/core/phone/phone.service.spec.ts(30,18): error TS2339: Property 'verifyNoOutstandingExpectation' does not exist on type 'IHttpBackendService'.
app/core/phone/phone.service.spec.ts(31,18): error TS2339: Property 'verifyNoOutstandingRequest' does not exist on type 'IHttpBackendService'.
app/core/phone/phone.service.spec.ts(39,18): error TS2339: Property 'flush' does not exist on type 'IHttpBackendService'.
app/core/phone/phone.service.ts(5,33): error TS2305: Module 'angular' has no exported member 'resource'.
app/phone-detail/phone-detail.component.spec.ts(5,22): error TS2339: Property 'mock' does not exist on type 'IAngularStatic'.
app/phone-detail/phone-detail.component.spec.ts(18,46): error TS2305: Module 'angular' has no exported member 'route'.
app/phone-detail/phone-detail.component.spec.ts(20,20): error TS2339: Property 'expectGET' does not exist on type 'IHttpBackendService'.
app/phone-detail/phone-detail.component.spec.ts(32,20): error TS2339: Property 'flush' does not exist on type 'IHttpBackendService'.
app/phone-detail/phone-detail.component.ts(7,37): error TS2305: Module 'angular' has no exported member 'route'.
app/phone-list/phone-list.component.spec.ts(6,22): error TS2339: Property 'mock' does not exist on type 'IAngularStatic'.
app/phone-list/phone-list.component.spec.ts(15,20): error TS2339: Property 'expectGET' does not exist on type 'IHttpBackendService'.
app/phone-list/phone-list.component.spec.ts(26,20): error TS2339: Property 'flush' does not exist on type 'IHttpBackendService'.
node_modules/@types/angular-resource/index.d.ts(192,40): error TS2305: Module 'angular' has no exported member 'resource'.
node_modules/@types/angular/index.d.ts(17,21): error TS2300: Duplicate identifier 'angular'.
node_modules/@types/angular/index.d.ts(18,21): error TS2300: Duplicate identifier 'ng'.

मैंने इसे आधार ../../node_modules/@types typeRoots के रूप में अपने tsconfig.json जोड़कर तय किया:

    "typeRoots": [
      "../../node_modules/@types/"
    ]

मैंने स्थानीय node_modules/@types जोड़ने की कोशिश की, लेकिन यह काम नहीं किया।

@heruan एक हैक जो मैंने करना शुरू किया, वह है lerna कार्यक्षमता का उपयोग करने के बजाय लिंकिंग / अनलिंक करने के लिए अपनी स्वयं की npm स्क्रिप्ट को लागू करना। तो, आप कुछ ऐसा कर सकते हैं जैसे lerna run link और फिर आपके सभी पैकेज में। आपके पास एक npm स्क्रिप्ट है, जिसे link कहा जाता है, जिसमें सभी npm लिंकिंग शामिल हैं (मेरे मामले में) npm link rxjs । यह ठीक काम करने लगता है, निश्चित रूप से आदर्श नहीं है।

@jeffwhelpley तुम यहाँ अपने समाधान साझा कर सकते हैं?

@yvoronen मैं अपना सभी कोड साझा नहीं कर सकता, लेकिन मेरा समाधान ऊपर वर्णित है। एक उच्च स्तर पर, मुझे जो कुंजी मिली है, वह न केवल उन सभी स्थानीय परियोजनाओं के लिए npm लिंक को सुनिश्चित करने के लिए सुनिश्चित की जा रही है, जो न केवल आपके द्वारा काम कर रहे हैं, बल्कि उन बाहरी परिवादों को भी npm लिंक करते हैं, जो समस्या का कारण बन सकते हैं (मेरे मामले में rxjs की वजह से समस्या है ऑब्जर्वेबल ऑब्जेक्ट में निजी संस्करण)। इसलिए, मैं अपनी सभी स्थानीय परियोजनाओं का प्रबंधन करने के लिए lerna का उपयोग करता हूं और फिर lerna run link चलाता हूं। मेरे प्रोजेक्ट के प्रत्येक रूट फ़ोल्डर में दृश्यों के तहत यह npm run link है। तो, आपको अपने पैकेज में link स्क्रिप्ट को परिभाषित करने की आवश्यकता है। इस तरह से करें:

  "scripts": {
    "link": "npm link my-local-project1 && npm link my-local-project2 && npm link rxjs || true",
    "unlink": "npm unlink my-local-project1 && npm unlink my-local-project2 && npm unlink rxjs && npm i || true"
  }

उम्मीद है कि समझ में आता है, लेकिन मुझे पता है अगर आप किसी भी सवाल है।

मैं एक अद्यतन प्रदान करना चाहता था। एक ऑफहैंड एक्सचेंज से मैंने

• एक समाधान जो हम उनके संस्करण के साथ-साथ उनके रिज़ॉल्यूशन नाम के आधार पर अलग-अलग पैकेज की अवधारणा पर विचार कर रहे हैं। इसमें क्या शामिल होगा, इसकी पूरी जानकारी मेरे पास नहीं है।
• एक अन्य सिम्बलिन की "सही" पहचान प्राप्त करने के लिए पथ का पूरी तरह से विस्तार करना है। मेरा मानना ​​है कि यह सरल है, लेकिन अधिक सीमित है जब यह विभिन्न संस्करणों में एक ही पैकेज से निपटने के लिए आता है, लेकिन मामलों की एक सभ्य संख्या को हल करने में मदद करता है।

क्या आप सुनिश्चित हैं कि आपकी टिप्पणी इस मुद्दे में है? यह पूरी तरह से लगता है
विभिन्न।

Thu पर, 12 जनवरी, 2017, 3:14 AM निकोस नोटिफिकेशन @github.com ने लिखा:

ध्यान दें, मैं AFAIK प्रकार या npm लिंक का उपयोग नहीं कर रहा हूं।

[छवि: छवि]
https://cloud.githubusercontent.com/assets/216566/21887548/451d059c-d8b8-11e6-86d1-50afae4e5c2f.png

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

@dobesv यह वास्तव में संपूर्ण कारण है कि आप पहली बार में समस्या क्यों देखते हैं। टाइपस्क्रिप्ट दो अलग-अलग घोषणाओं के रूप में वर्ग घोषणा को पहचानता है क्योंकि यह सच पथ से सहिष्णु पथ को अलग नहीं कर सकता है। समाधान या तो है

1. सिमिलिंक का विस्तार करें।
2. यह देखने के लिए जांचें कि क्या युक्त पैकेज समान है।

@DanielRosenwasser क्षमा करें मेरी टिप्पणी किसी और की टिप्पणी करने के लिए एक प्रतिक्रिया थी "गुरु, 12 जनवरी, 2017, 3:14 पूर्वाह्न निकोस पर @। *> लिखा था" ... यह है कि जो और उन्होंने क्या कहा मैं अब याद है, मैं उनका मानना है कि इस टिप्पणी थ्रेड में कुछ समस्या के बारे में पूछ रहे थे, जिसका npm लिंक से कोई लेना-देना नहीं था।

लेकिन जब मैं यहाँ हूँ तो मुझे यह उल्लेख करना चाहिए कि फ़ाइल नाम प्रकारों में भूमिका निभाने के तरीके के बारे में कुछ मज़ेदार है। आज मेरे पास RxJS के साथ एक मुद्दा था जहां यह शिकायत थी कि इस तरह के और इस तरह के तरीके को ऑब्जर्वेबल पर परिभाषित नहीं किया गया था। कारण यह था कि HTTP लाइब्रेरी में rxjs की अपनी निजी प्रति थी जो अन्य सभी से भिन्न थी। वास्तव में, मुझे अपने नोड_मॉडल के पेड़ में आरएक्सजे की चार अलग-अलग प्रतियां मिलीं।

यह एक समस्यात्मक दृष्टिकोण है जो अभी समस्याग्रस्त और भ्रमित करने वाला बना रहेगा।

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

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

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

संपादित करें: मैंने इसे पोस्ट करने के बाद महसूस किया, और यह टिप्पणी इसे अच्छी तरह से प्रस्तुत करती है:
https://github.com/Microsoft/TypeScript/issues/6496#issuecomment -257016094

exclude और compilerOptions.typeRoots को tsc द्वारा पूरी तरह से नजरअंदाज कर दिया जाता है। मैंने इसके लिए सभी संयोजनों की कोशिश की ताकि सिम्प्लेक्स किए गए रास्तों को अनदेखा किया जा सके, लेकिन यह अभी नहीं होगा
यह मॉड्यूल को पूरी तरह से अलग पथ के रूप में देख रहा है, जैसे कि यह सिमलिंक को हल कर रहा है और यह अपवर्जित पैटर्न को नहीं समझ रहा है।

उदाहरण के लिए, मेरे पास G:\www\cim-service-locator npm npm link cim-service-locator साथ जुड़ा हुआ है। G:\www\cim-backend में मेरे प्रोजेक्ट पथ पर, त्रुटियां इस तरह दिखाई दे रही हैं:

मैं बाहर / शामिल / typeRoot के संयोजन के लिए संभव सब कुछ करने की कोशिश की, लेकिन tsc उन्हें अनदेखा नहीं कर सका। 2.2-dev.20170131 का उपयोग करना

हम "npm लिंक" (@waldekmastykarz द्वारा रिपोर्ट की गई SPFx समस्या के माध्यम से) और "npm लिंक" के बिना भी (बग # 11436 देखें) दोनों का उपयोग कर इस समस्या का सामना कर रहे हैं।

मैंने अंततः महसूस किया कि टाइपस्क्रिप्ट कम्पाइलर की सख्ती असंगतताओं के कारण है जो नोड_मॉड्यूल्स फ़ोल्डर के निराला डिज़ाइन के कारण वास्तविक रूप से हो सकती है। इस उदाहरण पर विचार करें:

A
+---B<strong i="8">@1</strong>
+---C
|   +---B<strong i="9">@2</strong>   <--- first copy of ClassB extends ClassE version 3.4
|   \[email protected]
+---D
|   \---B<strong i="10">@2</strong>   <--- second copy of ClassB extends ClassE version 3.5
\[email protected]

इस उदाहरण में, बी @ 2 को ए @ बी पर निर्भरता के साथ संघर्ष से बचने के लिए सबफ़ोल्डर्स में स्थापित किया जाना है। अब, मान लीजिए कि ClassB ClassE से निकलता है, और हमारे पास कुछ इस तरह है:

बी / package.json

{
  "name": "B",
  "version": "2.0.0",
  "dependencies": {
    "E": "^3.0.0",
    ...
}

यदि C का पैकेज। Json [email protected] के लिए पूछता है, तो में असंगत हैं। कोड रनटाइम पर विफल हो सकता है यदि आपने उन्हें परस्पर उपयोग करने का प्रयास किया है।

इस उदाहरण में, TS2345 उस गलती को रोकेगा, जो अच्छी है। हालांकि, यह आवश्यक नहीं है: यदि कंपाइलर ने दो क्लासबी प्रतियों को बराबर माना है, तो इसका प्रकार सिस्टम आंतरिक रूप से संगत होगा और नियतात्मक व्यवहार होगा।

यह महत्वपूर्ण है क्योंकि हमारे लिए TS2345 ज्यादातर गलत अलार्म का उत्पादन करता है। ये झूठे अलार्म लोगों को एनपीएम पैकेजों के बीच के प्रकारों को साझा करने के लिए "किसी भी" के रूप में लिखने के लिए मजबूर करते हैं, जो अन्य गलतियों का कारण बनता है। इसलिए सख्ती से समस्या हल हो रही है।

मैं निम्नलिखित सुधार का प्रस्ताव देना चाहता हूं:

यदि ये सभी स्थितियां सत्य हैं, तो निजी सदस्यों वाले वर्गों के लिए TS2345 की रिपोर्ट न करें:

1. सार्वजनिक हस्ताक्षर सामान्य टाइपस्क्रिप्ट बतख-टाइपिंग के अनुसार संगत हैं
2. एनपीएम पैकेज फ़ोल्डर में समान नाम और संस्करण के साथ कक्षाएं परिभाषित की जाती हैं (पैकेज के अनुसार)
3. कक्षाओं में उनके मॉड्यूल के लिए समान सापेक्ष पथ होता है (उदाहरण के लिए "./lib/blah/Bdts")

यदि इनमें से कोई मानदंड पूरा नहीं हुआ है, तो TS2345 की रिपोर्ट करना ठीक है।

@iclanton @ nicpape-msft

@seansfkelley वेबपैक त्रुटि को टाइपस्ट्रॉन्ग / ts-loader # 468 द्वारा ट्रैक किया जाता है

हाय दोस्तों,
किसी ने हल ढूंढ लिया ??
मेरे पास एक ही मुद्दा है जब मैं किसी प्रोजेक्ट को RxJS के साथ जोड़ता हूं।
धन्यवाद ;)

नमस्ते, एक अस्थायी काम के लिए चारों ओर वेधशालाओं को लपेटना है जो Observable#from साथ एक निर्भरता द्वारा लौटाए जाते हैं।

अभी तक कोई हल नहीं निकला। ?

यहां दो मुद्दे प्रतीत होते हैं।

डुप्लीकेट परिभाषाओं के लिए त्रुटिपूर्ण त्रुटियां प्राप्त करने वाले टीएस-लोडर के उपयोगकर्ता, कंपाइलर एपीआई को अवैध इनपुट के कारण होते हैं। इसके लिए एक प्रकार TypeStrong / ts-loader # 468 में उपलब्ध है।

दूसरा मुद्दा यह है कि अगर आपके पास एक ही पैकेज (समान npm पैकेज + वर्जन) है, तो दो नेस्टेड फोल्डर में फाइल सिस्टम पर दो बार स्थानीय रूप से स्थापित ( npm link का उपयोग नहीं), एनम या निजी सदस्यों के साथ कक्षाओं के साथ, तुलना करते हुए। इन दो पैकेजों के प्रकार असंगत के रूप में विफल होंगे।
यह मुद्दा थोड़ा और अधिक शामिल है और संकलक के लिए अतिरिक्त काम करने की आवश्यकता होगी ताकि उन्हें संसाधित करने से पहले पैकेजों को "डुप्लिकेट" किया जा सके।

यदि इनमें से कोई भी दो श्रेणियां आप पर लागू नहीं होती हैं, तो कृपया एक नया मुद्दा दर्ज करें और हमें स्थानीय स्तर पर समस्या को पुन: पेश करने के लिए पर्याप्त जानकारी प्रदान करें, और हमें आगे की जांच करने में खुशी होगी।

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

रश (जो हम उपयोग करते हैं) और लर्ना इसके उदाहरण हैं।

@smcatala आप अपने समाधान की व्याख्या कर सकते हैं। मुझे इसे तत्काल ठीक करने की आवश्यकता है। धन्यवाद।

@ leovo2708
मॉड्यूल 'फू':

import { Observable } from 'rxjs'
export function foo() {
  return Observable.of('foo')
}

अन्य मॉड्यूल में क्लाइंट कोड, जो मॉड्यूल 'फू' पर निर्भर करता है:

import { Observable } from 'rxjs'
import { foo } from 'foo'

Observable.of(foo()) // wrap the returned Observable
.forEach(res => console.log(res))

@ leovo2708 सरल उपाय npm link का उपयोग नहीं करना है।

ts 2.1 का उपयोग करते हुए, मैं एक ही लाइब्रेरी के साथ npm लिंक का उपयोग करने में सक्षम रहा हूं (इसे xlib , जो कि मेरा वास्तविक उदाहरण है) कहते हैं, लेकिन आपको यह सुनिश्चित करने की आवश्यकता होगी कि आपके लाइब्रेरी ( xlib के मॉड्यूल उपभोक्ता परियोजना के नोड_मॉडल्स फ़ोल्डर में

मैं निम्नलिखित वर्कफ़्लो द्वारा ऐसा करता हूं

1. node_modules हटाएं
2. npm link xlib जो कि मेरी खपत परियोजना के node_modules xlib का सिंबल बनाता है
3. npm install जो मेरी खपत परियोजना की निर्भरता के शेष हिस्से को स्थापित करता है

मैं वास्तव में इस वार्तालाप का अनुसरण नहीं कर रहा हूं या जाँचता हूं कि क्या यह मुद्दा 2.2 से बदल गया है / संशोधित है, लेकिन हालांकि मैं ts 2.1 के लिए अपना वर्कअराउंड साझा करूंगा

यदि यह उपयोगी है, तो मैंने यहां एनमोंस केस की कई परिभाषाओं का एक न्यूनतम पुन: संग्रहित किया: https://github.com/rictic/repro-npm-link-typescript-issue

@mhegazy हम

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

tsconfig.json एक पथ मानचित्रण को उजागर करता है, paths में डुप्लिकेट की गई निर्भरता जोड़ते हैं, इसलिए इसे लिंक किए गए के बजाय node_modules सही से लोड किया जाएगा।

{
  "compilerOptions": {
    "baseUrl": ".", // This must be specified if "paths" is.
    "paths": {
      "@angular/common": ["../node_modules/@angular/common"],
      "@angular/compiler": ["../node_modules/@angular/compiler"],
      "@angular/core": ["../node_modules/@angular/core"],
      "@angular/forms": ["../node_modules/@angular/forms"],
      "@angular/platform-browser": ["../node_modules/@angular/platform-browser"],
      "@angular/platform-browser-dynamic": ["../node_modules/@angular/platform-browser-dynamic"],
      "@angular/router": ["../node_modules/@angular/router"],
      "@angular/http": ["../node_modules/@angular/http"],
      "rxjs/Observable": ["../node_modules/rxjs/Observable"]
    }
  }
}

यकीन नहीं है कि यहाँ पहले से ही उल्लेख किया गया है, लेकिन इस समाधान ने मेरे लिए काम किया: https://github.com/Microsoft/TypeScript/issues/11916#issuecomment -257130001

यह मूल रूप से ऊपर दिए गए @charpeni के समाधान के समान है, सिवाय पथ के "../" उपसर्ग के। (जो अजीब लगता है, क्योंकि इसका मतलब यह नहीं होगा कि tsconfig.json फ़ाइल प्रोजेक्ट रूट के सबफ़ोल्डर में होगी?)

यह एक महान विचार है @charpeni। मैंने उस पथ का उपयोग विभिन्न अन्य समान मुद्दों के आसपास काम करने के लिए किया है, लेकिन यह इस के लिए भी आदर्श प्रतीत होता है। वास्तव में, मुझे आश्चर्य है कि यदि उपभोग परियोजना में सही paths सेटिंग (प्रत्येक उपभोग की गई परियोजना की तुलना में) टाइपस्क्रिप्ट कंपाइलर को नोड रिज़ॉल्यूशन से दूर विचलित कर सकती है। यदि वह काम करता है, तो यह O (n) हैक के बजाय O (1) हैक होगा। अनिवार्य रूप से ऐसी योजना नोड संकल्प को सांख्यिकीय रूप से चलाएगी, फिर परिणामों को tsconfig में भर देगी।

मैं इन चीजों के साथ अर्ध-सार्वजनिक रूप से प्रयोग कर रहा हूं अगर कोई देखना चाहता है (या मदद ...)। मैं शायद उपरोक्त विचार का प्रयास करूंगा।

https://github.com/OasisDigital/many-to-many-angular

आसान उपयोग के लिए, आप इस तरह से पथ भी निर्धारित कर सकते हैं:

{
    "compilerOptions": {
        "baseUrl": ".", // This must be specified if "paths" is.
        "paths": {
            "@angular/*": ["../node_modules/@angular/*"],
            "rxjs/*": ["../node_modules/rxjs/*"]
        }
    }
}

मोनो-रेपो आर्किटेक्चर के विपरीत कई पैकेज के साथ काम करते समय एनपीएम लिंक वर्कफ़्लो का एक महत्वपूर्ण हिस्सा है। टीएस को यह देखने में सक्षम होना चाहिए कि दो पैकेज समान हैं और त्रुटि नहीं है

@charpeni मुझे काम करने का

मैं भी इस मुद्दे का अनुभव कर रहा हूँ। यह अचानक सोमवार को होने लगा, और मुझे यकीन नहीं है कि क्यों। यह वास्तव में विकास में बाधा है, खासकर जब यह हमारी परियोजनाओं के लिए पैकेज विकसित करने की बात आती है। मैंने इसे ठीक करने के लिए कई वर्कअराउंड की कोशिश की है। विंडोज में mklink /j चलने के बाद भी यह समस्या उत्पन्न होती है, इसलिए यह npm लिंक समस्या नहीं है। अगर किसी को वर्कअराउंड या फिक्स है तो यह बहुत मदद करेगा।

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

Btw, इस मुद्दे का @types से कोई लेना-देना नहीं है

हमने ग्लोब पैटर्न का उपयोग करके समाप्त किया।

@felixfbecker कार्यान्वयन के लिए, यह यहाँ उपलब्ध है: https://github.com/sherweb/ng2-materialize/blob/master/demo-app/tsconfig.json#L19 -L22

मेरे पास एक समान मुद्दा है सिवाय इसके कि यह पूरी तरह से @ प्रकार / नोड से संबंधित है।

libA @ नोड / प्रकारों पर निर्भर करता है
libB libA और @ नोड / प्रकार पर निर्भर करता है
libC liba, libB और @ नोड / प्रकार पर निर्भर करता है

liba ठीक बनाता है।
libB npm libA से जुड़ी फ़ाइल बनाता है।
libA और libB से जुड़ा libC npm जैसी त्रुटियों के साथ टाइपकास्ट करने में विफल रहता है

libC/node_modules/@types/node/index.d.ts(102,6): Duplicate identifier 'BufferEncoding'.
libC/node_modules/libB/node_modules/@types/node/index.d.ts(102,6): Duplicate identifier 'BufferEncoding'.
libC/node_modules/libB/node_modules/libA/node_modules/@types/node/index.d.ts(102,6): Duplicate identifier 'BufferEncoding'.

मैंने बिना किसी भाग्य के "प्रकार" और "टाइपरूट्स" के साथ खिलवाड़ करने की कोशिश की।

@charpeni ऐसा लगता है कि आपकी परियोजना भी @ प्रकार / नोड पर निर्भर करती है। क्या आपको मेरी समस्या या समाधान के समाधान के बारे में कोई जानकारी है?

@nicksnyder हो सकता है क्योंकि वे अलग-अलग संस्करण हैं, और @types/node एक वैश्विक घोषणा है, जिसका अर्थ है कि आप एक ही नाम को दो बार परिभाषित नहीं कर सकते। यही कारण है कि यह संकुल के लिए सबसे अच्छा है _ नहीं_ पर्यावरणीय टाइपिंग पर निर्भर करता है, इन्हें उपयोगकर्ता द्वारा प्रदान किया जाना चाहिए:
https://github.com/Microsoft/types-publisher/issues/107

@nicksnyder मेरे पास एक समान समस्या थी और सभी तीन परियोजनाओं को एक एकल प्रकार / नोड स्थापित करने के लिए

@felixfbecker मैंने सत्यापित किया कि सभी परियोजनाएँ नोड के एक ही संस्करण पर निर्भर करती हैं।

FWIW libA https://github.com/Microsoft/vscode-languageserver-node/tree/master/jsonrpc है , libB https://github.com/Microsoft/vscode-languageserver-node/tree/master/client और libC है मेरा अपना VS कोड एक्सटेंशन है

@uncleramsay आपने npm link @types/node कितना ठीक किया?

???
cd libA; npm link @types/node
cd libB; npm link @types/node
cd libC; npm link @types/node

मैं लिंकिंग समाधान करना चाहूंगा, लेकिन मैंने इसके बारे में भी हैक कर लिया है @ lib / libB में @ प्रकार / नोड निर्भरता को हटाकर, और एक refs.d.ts जोड़ा है जिसमें libC की नोड की प्रतिलिपि के लिए एक स्थानीय संदर्भ है।

/// <reference path='../../../path/to/libC/node_modules/@types/node/index.d.ts'/>

मैंने पाया कि मैं उन मुद्दों को हल करने में सक्षम था जो मैं https://github.com/Microsoft/TypeScript/issues/9091#issuecomment -225303098 में टिप्पणी से वर्णन कर रहा था

हमने केवल मॉड्यूल के लिए सिमलिंक रिज़ॉल्यूशन के लिए समर्थन जोड़ा ...

कोडबेस में अलग-अलग जगहों पर जब हम दो अलग-अलग संदर्भ शैलियों का उपयोग कर रहे थे:

/// <reference path="../node_modules/@types/library" />
/// <reference types="library" />

ये दोनों उस स्थिति में असंगत हैं जहां नोड_मॉड्यूल्स को सममित किया जाता है, क्योंकि मॉड्यूल रिज़ॉल्यूशन ( types= ) को वास्तविकपथ पर विस्तारित किया जाता है, लेकिन path= नहीं है। tsc --listFiles , सिमलिंक और रियलपैथ के साथ संकलन करते समय संदर्भित दो अलग-अलग फ़ाइलों में यह परिणाम है।

हम जिस समाधान के साथ गए थे वह एक या दूसरे का उपयोग करना था, लेकिन दोनों कभी नहीं। यह भी tsconfig में typeRoots: [] को निर्दिष्ट करने में मदद करता है ताकि संकलक स्वचालित रूप से reference path= शैली का उपयोग करने के मामले में node_modules/@types से प्रकार लोड कर सके।

मेरा मानना ​​है कि आगे बढ़ने की प्राथमिकता (कम से कम हमारे लिए) types= शैली को प्राथमिकता देना है।

आदर्श रूप से, हालांकि reference path= में वास्तविकपथ पर विस्तार करना पसंद किया जाएगा, और इस तरह के मुद्दों से बचने के लिए डुप्लिकेट मिलान पथों की जांच करना।

आशा है कि किसी की मदद करता है।

@nicksnyder आपको कुछ ऐसा करने में सक्षम होना चाहिए:

cd libA/node_modules/@types/node; npm link
cd libB; npm link @types/node
cd libC; npm link @types/node

इस तरह, B & C ठीक उसी फ़ाइलों की ओर इशारा कर रहे हैं जो A है।

@uncleramsay को पता है कि वे सभी एक ही संस्करण हैं, जो कि वे पहले नहीं थे

क्या इसके लिए सहकर्मी निर्भरताएं समाधान नहीं हो सकती हैं?
http://codetunnel.io/you-can-finally-npm-link-packages-that-contain-peer-dependencies/

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

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

• पूरे पेड़ को उल्टा कर दिया जाता है, यानी हर पैकेज अब उन पैकेजों पर एक कठिन निर्भरता लेने के लिए जिम्मेदार हो जाता है जो अप्रत्यक्ष निर्भरता हुआ करते थे, कई मामलों में बिना किसी विचार के।

• यदि एक सहकर्मी निर्भरता को हटा दिया जाता है, तो ये कठिन निर्भरताएं कभी भी दूर नहीं होंगी

• पैकेज लेखकों को अपने सहकर्मी संस्करण पैटर्न के लिए व्यापक रेंज का उपयोग करने के लिए लुभाया जाता है, उन संस्करणों के साथ काम करने का दावा करते हुए जिन्हें उन्होंने वास्तव में कभी भी परीक्षण नहीं किया; टूटी हुई बिल्ड अचानक उपभोक्ता की समस्या बन जाती है

ख़ूब कहा है।

समाधान

यहाँ मैं उपयोग किए जाने वाले वर्कआर्ड के लिए 3 विकल्प हैं:

विकल्प 1: दृश्य स्टूडियो बनाम vscode का उपयोग करें

tsc संकलक VS2017 की तुलना में बहुत अधिक क्षमा करने वाला है, शायद इसलिए कि VS2017 कोड को क्रॉल करता है (जिसमें सममित node_modules ) अच्छा परिचय प्रदान करने के लिए और इस तरह भ्रमित हो जाता है। हालाँकि मेरे पास बड़ी जटिल मल्टी-एनपीएम-मॉड्यूल परियोजनाएं हैं इसलिए वीएस २०१201 का उपयोग करें ... यदि आपके पास समान आवश्यकताएं हैं तो विकल्प २ और ३ पढ़ें।

विकल्प 2: d.ts उत्सर्जन करें

यदि आप outDir और rootDir (आपके tsconfig.json ) तो आपके सहानुभूतिपूर्ण परिवाद-मॉड्यूल को d.ts घोषणाओं का उत्सर्जन करना होगा और उन घोषणाओं को lib- मॉड्यूल में होना चाहिए package.json types संपत्ति।

यहाँ एक उदाहरण है कि आपके परिवाद-मॉड्यूल का tsconfig.json कैसा दिखना चाहिए

{
  "compileOnSave": true,
  "compilerOptions": {
    "module": "commonjs",
    "sourceMap": true,
     "declaration": true,
    "jsx": "react",
    "newLine": "LF",
    "pretty": true,
    "stripInternal": true,
    "diagnostics": true,
    "target": "es5",
    "moduleResolution": "node",
    "forceConsistentCasingInFileNames": true,
    "outDir": "./dist",
    "rootDir": "./src",
   //workaround for npm linking projects and associated dupe identifier bugs: https://github.com/Microsoft/TypeScript/issues/9566#issuecomment-287633339
    "baseUrl": "./",
    "paths": {
      "*": [
        "node_modules/@types/*",
        "*",
        "custom-dts/*"
      ]
    }
  },
  "include": [
    "src/**/*"
  ],
  "exclude": [
    "node_modules",
    "dist"
  ]
}

और आपके लिबर-मॉड्यूल के package.json को निम्नलिखित में से कुछ को शामिल करना चाहिए:

  "main": "./dist/_index.js",
  "types": "./dist/_index.d.ts",

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

यदि आप जंगली में इसका वास्तविक उदाहरण देखना चाहते हैं, तो npm मॉड्यूल xlib v8.5x देखें।

विकल्प 3: स्रोत के साथ .js इनलाइन (मेरी पसंदीदा पसंद) का उत्सर्जन करें

आप अपने .ts फ़ाइलों का उपयोग सीधे सिमिलिंक लिब-मॉड्यूल में टाइप करने के लिए कर सकते हैं! लेकिन केवल तभी जब आप outDir`` and rootDir in your tsconfig.json``` फ़ाइल का उपयोग न करें। यह VS2017 रेफ़रिंग को ठीक से काम करने देगा। यहाँ विन्यास सेटिंग्स की आवश्यकता है:

{
  "compileOnSave": true,
  "compilerOptions": {
    "module": "commonjs",
    "sourceMap": true,
     //"declaration": true,
    "jsx": "react",
    "newLine": "LF",
    "pretty": true,
    "stripInternal": true,
    "diagnostics": true,
    "target": "es5",
    "moduleResolution": "node",
    "forceConsistentCasingInFileNames": true,
    //"outDir": "./dist",
    //"rootDir": "./src",
   //workaround for npm linking projects and associated dupe identifier bugs: https://github.com/Microsoft/TypeScript/issues/9566#issuecomment-287633339
    "baseUrl": "./",
    "paths": {
      "*": [
        "node_modules/@types/*",
        "*",
        "custom-dts/*"
      ]
    }
  },
  "include": [
    "src/**/*"
  ],
  "exclude": [
    "node_modules",
    "dist"
  ]
}

और आपके लिबर-मॉड्यूल के package.json को बदल दिया जाना चाहिए:

  "main": "./src/_index.js",
  "types": "./src/_index.ts",

कैविएट (विकल्प 3 के साथ काम नहीं करेगा)

उपरोक्त वर्कअराउंड केवल तभी काम करते हैं जब प्रत्येक लिबिड-मॉड्यूल अनावश्यक प्रकार की जानकारी का उत्सर्जन नहीं करता है। उदाहरण के लिए मैं अपने xlib लाइब्रेरी का उपयोग करता था @types/async प्रकार की परिभाषाएँ। लेकिन तब मेरे पास एक और पुस्तकालय था जो स्वतंत्र रूप से @types/async संदर्भ देता था। टाइपिंग के लिए सीधे .ts फ़ाइलों का उपयोग करने के कारण tsc का उपयोग async दो लिबर-मॉड्यूल से होता है, जो इसे duplicate identifier मुद्दों के विभिन्न रूपों के साथ बारफ करने का कारण बनता है। इसे हल करने के लिए आपको या तो एक ही @types कई लिब-मॉड्यूल से आयात करने की आवश्यकता नहीं है, या विकल्प 2 .d.ts वर्कअराउंड का उपयोग करें

सारांश

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

वर्कऑन @mhegazy द्वारा https://github.com/Microsoft/TypeScript/issues/11916#issuecomment -257130001 (वर्कअराउंड 2 वैरिएसेंज़रिंगेन का एक रूपांतर) में पोस्ट किया गया है जब एक लार्ना प्रोजेक्ट में लिंक किए गए मॉड्यूल का उपयोग करके इसे हल किया गया था!

मुझे लगा कि मैं अपने अनुभव को साझा करूंगा ... किसी मौजूदा प्रोजेक्ट से एक लिब बनाने / निकालने की कोशिश कर रहा हूं ताकि अन्य प्रोजेक्ट्स में लिब को शेयर किया जा सके।

विंडोज 10 एंटरप्राइज
वीएस 2015 अपडेट 3
VS2015 2.2.2 के लिए उपकरण
वीएस कोड 1.12.2
टाइपस्क्रिप्ट 2.2.2
एनपीएम: 3.10.9
नोड: 6.9.2

हमारे पास वी.एस. 2015 ASP.MVC परियोजना है जो एक कोणीय 4.1.x सामने के छोर के साथ है जिसे हमने कुछ घटकों को एक आम पुस्तकालय बनाने के लिए निकालना शुरू कर दिया है ताकि उनका उपयोग अन्य परियोजनाओं में किया जा सके।

लाइब्रेरी प्रोजेक्ट VS कोड का उपयोग करके बनाया गया है और उचित d.ts फ़ाइलों के साथ dist फ़ोल्डर में es2015, es5 और umd संस्करणों के निर्माण के लिए रोलअप का उपयोग करता है।

अंतिम परिणाम कुछ इस तरह दिखता है:

-- dist
    |
    -- mylib
        |-- <strong i="16">@myscope</strong>
            |-- mylib.es5.js
            |-- mylib.js
        |-- bundles
            |-- mylib.umd.js
        |-- src
            |-- [all the d.ts folders/files]
        |-- index.d.ts
        |-- package.json
        |-- public_api.d.ts

मैंने npm को अपने VS 2015 / कोणीय 4.1.x प्रोजेक्ट के लिए डिस्टर्ब / माईलिब फोल्डर को फोल्डर से जोड़ा है।

जब मैं वीएस 2015 में परियोजना को संकलित करने का प्रयास करता हूं, तो मुझे उसी प्रकार के संदेश मिलते हैं जैसा कि उपर्युक्त कुछ स्थितियों में वर्णित है, जैसे कि सदस्यता, अवलोकन, आदि।

Ex: Build: Argument of type 'Subscription' is not assignable to parameter of type 'Subscription'.

अगर मैं अस्थायी रूप से लाइब्रेरी प्रोजेक्ट से नोड_मॉड्यूल निर्देशिका को हटाता हूं तो मुझे नई त्रुटियां मिल रही हैं जो मॉड्यूल खोजने में सक्षम नहीं हैं:

ex: Build: Cannot find module 'rxjs/Observable'.

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

यह मेरे लिए स्पष्ट नहीं है कि ऊपर प्रस्तावित कौन सा समाधान इस मुद्दे के लिए समाधान प्रदान करेगा, क्या कोई मेरी मदद कर सकता है?

धन्यवाद!

@mikehutter आपके प्रोजेक्ट में जो आपकी लाइब्रेरी का उपयोग करता है (लाइब्रेरी में ही नहीं), अपने tsconfractor में ऐसा कुछ करें:

    "paths": {
      "rxjs/*": ["../node_modules/rxjs/*"]
    },

आपके tsconfig और स्रोत कोड के परिणाम के आधार पर आपको इसके लिए कुछ मामूली समायोजन की आवश्यकता हो सकती है।

(इस धागे में दूसरों की तरह, मैं कुछ टाइपस्क्रिप्ट सुधार देखना पसंद करूंगा जो इसे अनावश्यक बनाता है।)

@mikehutter हमने हाल ही में लिंक किए गए https://github.com/angular/angular-cli/blob/master/docs/documentation/stories/linked-library.md देखें।

@kylecordes बिंदु

धन्यवाद @kylecordes और @filipesilva! मुझे बस इतना ही चाहिए था ...

नमस्ते!

@mhegazy , क्या आपको लगता है कि यह इसे 2.4 या देगा , क्या यह फिर से देरी होगी?
यह वास्तव में इसके आसपास काम करने के लिए दर्दनाक है, प्रत्येक परियोजना को हमेशा उन चीजों के लिए पथ मैपिंग को परिभाषित करने के लिए मजबूर करता है जिनके बारे में उन्हें वास्तव में परवाह नहीं होनी चाहिए।

वास्तव में उम्मीद है कि इस बार यह रिलीज में बदल जाए!

श्रेष्ठ,

लगता है कि यह अभी तक उल्लेख नहीं किया गया है, लेकिन इस मुद्दे के आसपास काम करने का सुपर शॉर्टहैंड तरीका है:

{
    "compilerOptions": {
        "baseUrl": ".",
        "paths": {
            "*": ["node_modules/*", "*"]
        }
    }
}

मूल रूप से ऊपर paths प्रविष्टि का कहना है: किसी भी मॉड्यूल के लिए, पहले इसे प्रोजेक्ट की जड़ में node_modules फ़ोल्डर में देखें, फिर सामान्य नियम पर वापस जाएँ (जहाँ से निर्देशिकाओं को पुनरावर्ती करें) आयात हुआ है)।

(कृपया मुझे सही करें अगर मैं गलत हूं, मैं अभी भी टीएस के लिए एक रिश्तेदार नवागंतुक हूं)।

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

{
    "compilerOptions": {
        "baseUrl": "./src",
        "paths": {
            "*": ["../node_modules/*", "*"]
        }
    }
}

@ फ़िज़ूल फ़िजी मेरे काम के विकल्प 2 और 3 का हिस्सा है (मेरी उपरोक्त पोस्ट में)। मैंने देखा है कि यदि आपके पास समान टाइपिंग का उपयोग करने वाली परियोजनाएं हैं, तो बस paths संपत्ति पर्याप्त नहीं है।

@ajonswearingen आपकी पोस्ट मेरी तुलना में अधिक व्यापक है ... इसे क्लीयर करने के लिए धन्यवाद। अगर मैं किसी और मुद्दे पर भागता हूँ तो मैं इसे वापस संदर्भित करना सुनिश्चित करूँगा। 😄

हम इसे Google प्रोजेक्ट्स में भी देख रहे हैं। जैसा यहाँ वर्णित है:
https://github.com/Microsoft/TypeScript/issues/9091#issuecomment -306969543

बेसयूआरएल और रास्तों का उपयोग करने के लिए ऊपर वर्णित वर्कअराउंड काम नहीं करते हैं, टीएससी अभी भी डुप्लिकेट परिभाषाएं और पथ / बेसयूआरएल / शामिल / बहिष्कृत / आदि का कोई संयोजन नहीं उठाता है। अन्यथा यह समझाने में सक्षम है।

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

@ मैं यह देता हूं कि आप यहां अपना वर्कअराउंड पोस्ट पढ़ें: https://github.com/Microsoft/TypeScript/issues/6496#issuecomment -302886203

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

उम्मीद है की वो मदद करदे।

+1 मैं लारना का उपयोग कर रहा हूं और इसमें शामिल टंकणों के साथ शामिल होने पर टाइपिंग को "डुप्लिकेट" के रूप में चिह्नित किया गया है।

जरूरत पड़ने पर कोड साझा कर सकता हूं।

वेबपैक के साथ जैसा कि कोणीय-सीएलआई में, है कि कोणीय-सीएलआई पैकेज.जॉन RXJS पैकेज का संदर्भ देता है, फिर किसी अन्य प्रोजेक्ट के पैकेज से `RXJS 'पैकेज को हटा दें।जिससे आपको WebPack के कारण की आवश्यकता नहीं है ।

यह स्थिति सिर्फ़ सहानुभूति के साथ नहीं हो सकती है, बल्कि npm-shrinkwrap.json निर्भरता में @types/node dependencies । Shrinkwrap npm @types/node को मूल पैकेज में https://github.com/KingHenne/custom-tslint-formatters/issues/5 देखें

जब @types/react स्थापित किया गया है और यह भी एक app है कि @types/react का उपयोग करता है को जोड़ने के लिए एक प्रतिक्रिया परियोजना का उपयोग करते समय इस में भाग गया

मैं w / yarn link -ed पैकेज काम करते समय एक ही मुद्दा रहा था।
Rx.js त्रुटि फेंक रहा था: Type 'Observable<Location[]>' is not assignable to type 'Observable<Location[]>'. Property 'source' is protected but type 'Observable<T>' is not a class derived from 'Observable<T>'

सौभाग्य से, मैंने माता-पिता और लिंक किए गए पैकेजों में समान Rxj.s संस्करण का उपयोग करके इसे हल किया है।
तो, मेरे मामले में, Rx.js दो अलग-अलग संस्करणों ने समस्या का कारण बना।

यह मोनोरैप के साथ काम करते समय एक विशाल अवरोधक है। वास्तव में उम्मीद है कि यह अब देरी नहीं करेगा और 2.5 में अपना रास्ता ढूंढ लेगा।

संपादित करें: 😮

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

मेरी टीम ने विकास के दौरान हमारे अपने आंतरिक पुस्तकालयों को जोड़ने पर इस समस्या को बहुत बार मारा है।

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

यह समस्या लगातार पीछे धकेलती नजर आ रही है। क्योंकि यह वास्तव में इतने सारे लोगों के वर्कफ़्लोज़ के लिए विघटनकारी है, क्या हम संभवतः किसी प्रकार के स्टॉपगैप फिक्स कर सकते हैं, जैसे कि # 9448 में सुझाए गए 'अक्षम टिप्पणी' के रूप में?

import { baz$ } from './qux';
function foo (bar$: Observable<any>) {}

foo(baz$);
> Duplicate identifier

// Makes foo's `bar$` type equal to that of `baz$`
foo(/*typescript:identicalIdentifier*/ baz$);

"निष्क्रिय टिप्पणी" केवल हर जगह टाइप कास्ट करने से बेहतर नहीं है, जो एक बड़ी परियोजना में बहुत दर्दनाक है। ऊपर मैंने निम्नलिखित संकलक परिवर्तन का प्रस्ताव दिया:

यदि ये सभी स्थितियां सत्य हैं, तो निजी सदस्यों वाले वर्गों के लिए TS2345 की रिपोर्ट न करें:

1. सार्वजनिक हस्ताक्षर सामान्य टाइपस्क्रिप्ट बतख-टाइपिंग के अनुसार संगत हैं
2. एनपीएम पैकेज फ़ोल्डर में समान नाम और संस्करण के साथ कक्षाएं परिभाषित की जाती हैं (पैकेज के अनुसार)
3. कक्षाओं में उनके मॉड्यूल के लिए समान सापेक्ष पथ होता है (उदाहरण के लिए "./lib/blah/Bdts")

यदि इनमें से कोई मानदंड पूरा नहीं हुआ है, तो TS2345 की रिपोर्ट करना ठीक है।

एक सरलीकृत सुधार भी वर्तमान स्थिति से बेहतर होगा, उदाहरण के लिए, केवल # 1 पर विचार करें, शायद तभी जब लोग tsconnig से ऑप्ट-इन करें। इसे लागू करने के लिए बहुत सस्ता होना चाहिए।

इस दृष्टिकोण का लाभ केवल झूठे अलार्म को अक्षम करना है, लेकिन मौजूदा शब्दार्थ को बनाए रखना है। जबकि नोड_मॉड्यूल्स रीमैपिंग हैक्स एक संभावित गलत तरीके से एनपीएम मॉड्यूल रिज़ॉल्यूशन को बदलते हैं (जैसे कि मैंने दिए गए काल्पनिक उदाहरण में कोड की खराबी का कारण बनता है)।

ईमानदार होने के लिए, मुझे यह भी निश्चित नहीं है कि यह टाइपस्क्रिप्ट में "तय" होना चाहिए, क्योंकि सादे जावास्क्रिप्ट के साथ भी एक समस्या है: यदि ऑब्जेक्ट की कक्षा प्रदान की गई कक्षा से भिन्न होती है, तो Instof ऑपरेटर गलत वापस आ जाएगा।

इस प्रकार, मैं बजाय npm लिंक के लिए एक बेहतर विकल्प की उम्मीद करूंगा कि शायद हुक की आवश्यकता हो (), पहले।

यह एक अच्छी अंतर्दृष्टि है। क्या आपने pnpm को देखा है? यह वर्तमान नोड_मॉडल डिज़ाइन से एक छोटा कदम आगे है, लेकिन अगर मैं इसे सही तरीके से समझूं तो यह बहुत प्रभावी है।

यह केवल npm link बारे में नहीं है जिसे प्रतिस्थापित किया जा सकता है या उपयोग नहीं किया जा सकता है, लेकिन एक ही समय में स्थापित समान @types/xxx पैकेज के कई संस्करण होने के बारे में, अक्सर उन निर्भरता से खींच लिया जाता है जो टाइपस्क्रिप्ट घोषणाओं को प्रदान करते हैं मानक घोषणाओं पर, जैसा कि मैंने और अन्य लोगों ने रिपोर्ट किया। इस तरह के पैकेजों की संख्या नोड समुदाय में टाइपस्क्रिप्ट के अधिक गोद लेने के साथ बढ़ेगी।

@Yogu मुझे लगता है कि यह भ्रामक पहचान और समानता है। भले ही दो स्थानों से एक ही पैकेज / संस्करण का आयात एक प्रकार के दो अलग-अलग उदाहरणों का प्रतिनिधित्व कर सकता है, वे अभी भी प्रकार में समान हैं।

निम्नलिखित (मान्य) कोड दिमाग में आता है:

type a = { c: string };
type b = { c: string };

function foo (bar: a) {}

const baz: b = { c: 'd' };
foo(baz);

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

पुस्तकालयों के विभिन्न संस्करणों से आयातित प्रकार (और इसी @types पैकेज) दोनों समान और भिन्न हो सकते हैं (यदि पुस्तकालय अपडेट होता है, तो टाइप परिभाषा को अपडेट करने के साथ-साथ परिवर्तनों को प्रतिबिंबित करना चाहिए)।

मैंने अभी एक परिवर्तन मर्ज किया है जो उनके नाम और संस्करण के आधार पर डुप्लिकेट पैकेजों का पता लगाने का प्रयास करेगा, और केवल एक का उपयोग करेगा। अगली बार प्रकाशित होने पर कृपया typescript@next का उपयोग करके इसे आज़माएं।

हुर्रे, यह तय होने के लिए एक टन धन्यवाद! :-)

@pgon pnpm करने के लिए सूचक के लिए धन्यवाद, यह निश्चित रूप से दिलचस्प लग रहा है!

@sompylasar @types/node एक विशेष मामले का एक सा है, लेकिन @types/react , यहाँ मेरा सुझाव है: peerDependencies में एक मॉड्यूल की एपीआई के लिए आवश्यक सभी निर्भरताएं रखो dependencies । इससे यह स्पष्ट होता है कि माता-पिता और बच्चे के मॉड्यूल के बीच निर्भरता के संस्करण मेल खाने चाहिए (या कम से कम संगत होना चाहिए)। यदि माता-पिता और बच्चा दोनों प्रतिक्रिया का उपयोग करते हैं, लेकिन प्रतिक्रिया प्रकार की वस्तुओं का आदान-प्रदान नहीं करते हैं, तो यह समस्या यहां नहीं उठेगी।

@harangue यदि एक वर्ग को दो अलग-अलग फ़ाइलों में दो बार घोषित किया जाता है, एक ही नाम और एक ही संरचना के साथ, अभी भी दो अलग-अलग वर्ग हैं जिन्हें जावास्क्रिप्ट के बराबर नहीं माना जाता है। जैसा कि मैंने उल्लेख किया है, instanceof ऑपरेटर अभी भी दो वर्गों के उदाहरणों को भेद करेंगे।

इस फिडेल को एक प्रदर्शन के लिए देखें।

यही कारण है कि मैं इसे NPM स्तर पर हल करूँगा (इसलिए यदि हमारे पास पहले से कई घोषणाएँ नहीं हैं, तो इसका उद्देश्य टाइपस्क्रिप्ट से नहीं है)।

@Yogu : +1: यदि @types/node एक विशेष मामला है, तो आप एक ही समय में दो अलग-अलग नोड संस्करणों का उपयोग करके किसी प्रोग्राम को निष्पादित नहीं कर सकते हैं, यह एक संस्करण होगा, और सबसे अधिक संभावना एक निर्दिष्ट होगी। शीर्ष-स्तरीय पैकेज, शायद टाइपस्क्रिप्ट को इसे एक विशेष मामले के रूप में माना जाना चाहिए, उदाहरण के लिए हमेशा प्रत्येक निर्भरता के लिए शीर्ष-स्तर @types/node ?

@ -y-ms इसके लिए धन्यवाद!

कृपया इसे अगले टाइप होने पर टाइपस्क्रिप्ट @ अगला का उपयोग करके देखें।

मुझे लगता है कि अभी तक नहीं हुआ है। मैंने इसे कुछ प्रोजेक्ट्स के साथ आज़माया है लेकिन अब तक कोई किस्मत नहीं। जैसे ही next उपलब्ध हो, इस थ्रेड में एक अद्यतन देखना बहुत अच्छा होगा। @ Andy-एमएस

ऐसा लग रहा है कि दैनिक निर्माण फिर से बंद हो गए हैं। अंतिम था: 2.5.0-dev.20170808 ।

cc / @DanielRosenwasser

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

अगर मेरे पास @types किसी चीज़ के लिए @types/mongodb और मेरे पास एक कस्टम घोषणा है, जो उस मॉड्यूल को बढ़ाती है, अर्थात विधियों में संशोधन जोड़ रही है, तो मेरे पास अब @types/mongodb जो कि मॉड्यूल mongodb और मेरे पास अपनी परियोजना में एक d.ts फ़ाइल है, जिसे mongo-promisification.d.ts कुछ कहा जाता है जिसमें mongodb मॉड्यूल शामिल हैं।

तो फिर उस उपरोक्त परिदृश्य के साथ, मेरे पास एक फ़ाइल है, जिसमें import {somethingFromTypes} from "mongodb" यह शिकायत करता है कि प्रकार मॉड्यूल से डेटा नहीं मिल सकता है, भले ही इसके वहाँ और वैध हो, लेकिन अगर मैंने import {somethingFromMyExtendingDts} from "mongodb" जो काम करता है ठीक।

जब मैं संकलित करता हूं तो मुझे बताया जाता है कि मॉड्यूल उस सामान को निर्यात नहीं करता है, जब वह करता है, तो यह वांछित व्यवहार है और मुझे बस अपने कस्टम d.ts पर फिर से निर्यात करने की आवश्यकता है या इसे दोनों प्रकार और एक्सटेंशन d.ts में लेना चाहिए मेरे पास है?

मैं नवीनतम परीक्षण बिल्ड (विंडोज़ 10 64 बिट) चला रहा हूं और यह मेरे लिए निश्चित नहीं है।

प्रजनन

संरचना

a/
  index.ts
  package.json
b/
  index.ts
  package.json

Daud

cd a
npm link
cd ../b
npm link a

एक / index.ts

import { Observable } from 'rxjs/Observable';

export class Foo {
  public bar: Observable<any>;
}

बी / index.ts

import { Foo } from '@rxjs-test/a';
import { Observable } from 'rxjs/Observable';

const baz = new Foo();

function qux (quux: Observable<any>) {}

// TypeError
qux(baz.bar);

Daud

b>tsc -v
Version 2.6.0-dev.20170826

b>tsc index.ts
index.ts(11,5): error TS2345: Argument of type 'Observable<any>' is not assignable to parameter of type 'Observable<any>'.
  Property 'source' is protected but type 'Observable<T>' is not a class derived from 'Observable<T>'.

@grofit मुझे लगता है कि आपकी स्थिति में समस्या यह है कि आपके पास एक मॉड्यूल की दो घोषणाएं हैं, जहां आपको एक मॉड्यूल और एक वृद्धि की आवश्यकता है।
आपको इस तरह mongo-promisification.d.ts करने में सक्षम होना चाहिए:

import * as mongodb from "mongodb"; // import the real mongo

// now augment it
declare module "mongodb" {
    // new stuff...
}

import बिना, आप एक परिवेश के संदर्भ में हैं और एक नई घोषणा लिख ​​रहे हैं, एक वृद्धि नहीं।

( हैंडबुक रेफरी)

पुष्टि कर सकते हैं यह मेरे लिए अब [email protected] साथ काम कर रहा है। @ Andy-ms के लिए बड़ा धन्यवाद - यह एक गेम चेंजर है!

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

`` `फ़ंक्शन प्राप्तियां (): अवलोकनीय
http.get ()। नक्शा (प्रतिक्रिया: प्रतिक्रिया) => {
वापसीresponse.json ();
}

and when I removed the Observable<T> from function getitems() to not return anything the error disappear.
```function getitems()
http.get().map(response : Response) =>{
return <T> response.json();
}

@ बासेल78 मुझे आपकी त्रुटि को पुन: पेश करने में सक्षम होने के लिए एक पूर्ण उदाहरण की आवश्यकता होगी। इसके अलावा, सुनिश्चित करें कि आप typescript@next का उपयोग कर रहे हैं - कोणीय-क्ली आपके पास पुराने संस्करण पर हो सकता है जिसमें कटौती विशेषता नहीं है।

मैं टाइप करने की कोशिश कर चुका हूँ
दुर्भाग्य से मैं पूरे प्रोजेक्ट को साझा नहीं कर सकता। लेकिन यहाँ कुछ विवरण हैं:
npm-link-ed पैकेज का tsconfig:

    "compilerOptions": {
        "module": "amd",
        "target": "es3",
        "sourceMap": true,
        "noEmitHelpers": true,
        "experimentalDecorators": true,
        "baseUrl": ".", // This must be specified if "paths" is.
        "paths": {
            "lib/*": [ "src/lib/*" ],
            "modules/*": [ "src/modules/*" ],
            "vendor/*": [ "src/vendor/*" ]
        },
        "typeRoots" : ["src/typings"]
    },
    "include": [
        "src/**/*.ts",
        "src/**/.*.ts", // TS ignores file names starting with dot by default
        "tests/**/*.ts",
        "tests/**/.*.ts"
    ]

मुख्य परियोजना का tsconfig ( @croc/webclient जुड़ा हुआ पैकेज है):

    "extends": "./node_modules/@croc/webclient/tsconfig",
    "include": [
        "src/**/*.ts",
        "src/**/.*.ts",
        "node_modules/@croc/webclient/src/**/*.ts",
        "node_modules/@croc/webclient/src/**/.*.ts"
    ],
    "compilerOptions": {
      "baseUrl": ".",
      "typeRoots" : ["node_modules/@croc/webclient/src/typings"],
      "paths": {
        // map runtime paths to compile-time paths
        "lib/*": [ "node_modules/@croc/webclient/src/lib/*" ],
        "modules/*": [ "node_modules/@croc/webclient/src/modules/*" ],
        "vendor/*": [ "node_modules/@croc/webclient/src/vendor/*" ]
      }
    }

@ बुराई-चीख आप अपनी परियोजना को एक साधारण उदाहरण में कम कर सकते हैं जो इस मुद्दे को प्रदर्शित करता है?

@ आमेजी यहां
https://github.com/evil-shrike/typescript-npmlink-issue
प्रोप रूट में:

cd lib
npm link
cd ../main
npm link tstest-lib

तब main :

npm run tsc

हाय @ बुराई-चीख, मैंने समस्या को नीचे संकुचित कर दिया है:
lib / tsconfig.json

{
    "compilerOptions": {
        "typeRoots" : ["src/typings"]
    }
}

मुख्य / tsconfig.json

{
    "extends": "./node_modules/tstest-lib/tsconfig",
    "include": [
        "node_modules/tstest-lib/src/**/*.ts"
    ]
}

इसलिए हम दोनों को शामिल करते हैं ( tsc --listFiles ):

/main/node_modules/tstest-lib/src/typings/jquery/index.d.ts
/lib/src/typings/jquery/index.d.ts

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

@ Andy-एमएस
यह करना आसान नहीं है। मेरे मामले में संदर्भित परिवाद में बहुत सारे परिवेशीय d.ts हैं जो उदाहरण के लिए वैश्विक इंटरफेस का विस्तार करते हैं। JQueryStatic की तरह:

interface JQueryStatic {
    cleanData (elems);
}

या लोड के लिए उपसर्ग की घोषणा (आवश्यकता):

declare module "i18n!*" {
    //const m: { [key: string]: string };
    const m;
    export = m;
}

फिर कहीं न कहीं लिबर के स्रोत में यह उनका उपयोग करता है:

const oldCleanData = $.cleanData;
$.cleanData = function (elems: JQuery) {
..
    oldCleanData(elems);
};

जब इस तरह के एक मॉड्यूल (एफबीआई से) मुख्य रूप से कहीं आयात किया जाएगा तो यह संकलन में विफल हो जाएगा।

आपके परिवाद के स्रोत में आपको /// <reference types="" /> (या /// <reference path="" /> ) निर्देशों का उपयोग करना चाहिए ताकि यह सुनिश्चित किया जा सके कि आपकी लाइब्रेरी के आयात होने पर आवश्यक टंकण मौजूद हैं। इस तरह इसे "शामिल" होने की जरूरत नहीं होगी; जब यह आयात किया जाता है तो संदर्भित प्रकार स्वचालित रूप से परियोजना में जुड़ जाएंगे।

@ -y-ms धन्यवाद, मैंने अपना लीवर पुनःप्राप्त कर लिया है और अब एक ऐसा प्रोजेक्ट है जहाँ यह npm-link-ed ठीक संकलित किया जा रहा है।

यकीन नहीं होता कि ये बहुत बड़े रिप्रोडक्शन हैं, लेकिन मुझे एक ही चीज़ मिल रही है CLI के एक नंगे कोने से, जो कि टाइपस्क्रिप्ट @ है, Observable<T> !== Observable<T> ।

https://github.com/intellix/angular-cli-red
https://github.com/intellix/angular-cli-blue

ब्लू आयात और रेड से एक घटक और सेवा का उपयोग करता है

@intellix क्या आपको एक उदाहरण मिल सकता है जो केवल tsc कमांड लाइन का उपयोग करते हुए त्रुटियां करता है? टाइपस्क्रिप्ट ng का कौन सा संस्करण उपयोग कर रहा है, यह बताना कठिन है।

@ -y-ms मुझे अभी भी यह समस्या आ रही है। यह मेरे लिए तब होता है जब मैं किसी भी vscode एक्सटेंशन के बीच npm लिंक का उपयोग करने का प्रयास कर रहा हूं। वे सभी vscode आयात करते हैं जो डुप्लिकेट पहचानकर्ता त्रुटियों का कारण बनता है।
TS Version 2.7.0-dev.20171118

मेरे लिए यह tsconfig फ़ाइल के पथ अनुभाग में नोड_मॉड्यूल्स के भीतर एक विशिष्ट rxjs फ़ोल्डर के उदाहरण "rxjs / *" के लिए काम किया।
अब सब कुछ npm लिंक के साथ ठीक काम करता है।

मैंने यह भी देखा है जब एक संस्करण अद्यतन लिंक से एक पैकेज के लिए गैर-सहिष्णुता के लिए सहानुभूति से जा रहा है।

इस SO प्रश्न को भी देखें: https://stackoverflow.com/questions/38168581/observablet-is-not-a-class-derived-from-observablet

@dakaraphi @JoshuaKGoldberg क्या आप इन परिदृश्यों को पुन: प्रस्तुत करने के लिए निर्देश प्रदान कर सकते हैं?

नए व्यवहार के साथ हमें एक पैकेज शामिल नहीं करना चाहिए अगर हमने पहले से ही package.json "

@ -y-ms मेरे पास उदाहरण है निम्नलिखित रिपॉजिटरी हैं:

1. https://github.com/dakaraphi/vscode-extension-fold
2. https://github.com/dakaraphi/vscode-extension-common

मैं vscode-extension-common से vscode-extension-fold vscode-extension-common संदर्भ के लिए स्थानीय npm इंस्टॉल का उपयोग करता हूं

यदि आप इन रिपॉजिटरी की जांच करते हैं, तो वे वर्तमान में काम करते हैं क्योंकि मेरे पास package.json vscode-extension-fold में एक पथ मानचित्रण समाधान है। हालांकि, अगर मैं सही तरीके से समझूं, तो मुझे उस वर्कअराउंड की आवश्यकता नहीं होनी चाहिए।

@dakaraphi धन्यवाद! ऐसा लगता है कि त्रुटि vscode.d.ts कारण एक वैश्विक मॉड्यूल के रूप में वैश्विक, परिवेशी घोषणा के रूप में लिखी जा रही है। मैंने Microsoft / vscode-extension-vscode # 90 बनाया है।

यह तब भी मेरे लिए काम नहीं करता है जब मैं 2 पैकेज लिंक करने की कोशिश कर रहा हूं, जिनमें से प्रत्येक rxjs पर निर्भरता रखता है। मैं [email protected] और [email protected] का उपयोग कर रहा हूं। दोनों पैकेज सटीक एक ही संस्करण का उपयोग कर रहे हैं। क्या इसके लिए किसी के पास वर्कअराउंड है?

@SamVerschueren क्या आप त्रुटि को पुन: उत्पन्न करने के लिए विशिष्ट निर्देश प्रदान कर सकते हैं? typescript@next साथ भी परीक्षण करें।

@ -y-ms मैं देखूंगा कि मैं क्या कर सकता हूं!

@ @ -y-ms यहां एक छोटा प्रजनन भंडार है https://github.com/SamVerschueren/ts-link-6496। मैंने इसे पुन: उत्पन्न करने के लिए [email protected] का उपयोग किया।

1. mod-a और mod-b लिए दोनों निर्भरताएं स्थापित करें
2. mod-b yarn build साथ संकलित करें
3. mod-a yarn build mod-a साथ

चरण 3 निम्न त्रुटि के साथ विफल हो जाएगा

src/index.ts(7,15): error TS2345: Argument of type 'UnaryFunction<Observable<string>, Observable<string>>' is not assignable to parameter of type 'UnaryFunction<Observable<string>, Observable<string>>'.
  Types of parameters 'source' and 'source' are incompatible.
    Type 'Observable<string>' is not assignable to type 'Observable<string>'. Two different types with this name exist, but they are unrelated.
      Property 'buffer' is missing in type 'Observable<string>'.
src/index.ts(7,47): error TS7006: Parameter 'result' implicitly has an 'any' type.

अभी भी इस मुद्दे पर टाइपस्क्रिप्ट@2.8.1 के साथ चल रहा है @ टाइप करने की कोशिश की और उसी मुद्दे पर था।

समस्या की जड़ यह प्रतीत होती है कि लिंक किए गए पैकेज अभी भी अपने स्वयं के स्थानीय node_modules में टाइप परिभाषाओं को संदर्भित करने के बजाय node_modules से टाइपिंग का उपयोग करते हैं जिसमें वे लिंक किए जाते हैं, जब संभव हो। इस तथ्य के साथ संयुक्त है कि:

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

मैं paths कॉन्फिग चर का उपयोग करके इस समस्या को हल करने में सक्षम रहा हूँ। उन मॉड्यूलों के लिए, जिनकी परिभाषा @types/* , जैसा कि यहां बताया गया है , आप बस उपयोग कर सकते हैं:

"paths": {
  "*": ["node_modules/@types/*", "*"]
}

उस मामले में जहां आप इस मुद्दे पर एक पैकेज के साथ चलते हैं जो टाइप परिभाषाओं के साथ बंडल होता है जो कक्षाओं या ग्लोबल्स को परिभाषित करते हैं, आपको उन्हें मैन्युअल रूप से जोड़ना होगा। उदाहरण के लिए, rxjs :

"paths": {
  "rxjs": ["node_modules/rxjs"],
  "rxjs/*": ["node_modules/rxjs/*"]
}

जब मैं TS 2.8.3 का उपयोग करता हूं, तो मैं एक स्थानीय पैकेज जोड़ते समय सहानुभूति के साथ समस्याओं का अनुभव करता हूं:

},
"devDependencies": {
    "@types/MyLib": "file:../MyLib/bin/npm/@types"
},

V3 के बाद से, npm स्पष्ट रूप से फ़ाइलों को कॉपी करने के बजाय सिम्बलिंक्स के साथ स्थापित कर रहे हैं।

हालाँकि, जब मैं संकलन करने की कोशिश करता हूं, तो संकलक लिंक की गई परिभाषा फ़ाइल को दो अलग और परस्पर विरोधी फ़ाइलों के रूप में देखता है:

node_modules\@types\MyLib\index.d.ts(3,11): error TS2300: Duplicate identifier 'Foo'.
C:/MySolution/MyLib/bin/npm/@types/index.d.ts(3,11): error TS2300: Duplicate identifier 'Foo'.

अगर मैं इसके बजाय फ़ाइलों को मैन्युअल रूप से कॉपी करता हूं, तो यह अपेक्षा के अनुरूप काम करता है। मैं typeRoots: ["./node_modules/**/"] सेट करके इसके आसपास काम कर सकता हूं