ここにはClassAルート宣言が1つしかないため、このエラーは発生しません。

申し訳ありませんが、これは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
        |       |
        |       ...
        |
        ...

示されているように、package-aには2つの異なる宣言ファイルがあるように見えます。
npm installを使用して通常どおりパッケージをインストールする場合、この場合、package-aの宣言がpackage-bに含まれていないため、これは発生しません。

とにかくこれに対する何らかの解決策があることを願っていますが、それは難しく、優先度が低いかもしれません。

最終的にnpm linkを使用しなくなりましたが、これは私にとってもう問題ではありません。

十分に公平ですが、他の誰かが：wink：

実際には、ClassAの宣言が2つある2つのファイルがディスク上にあります。 したがって、エラーは正しいです。 ただし、これらのタイプを比較するときは、ノードモジュールを考慮する必要があります。 この問題は以前にhttps://github.com/Microsoft/TypeScript/issues/4800で報告されており、列挙型の場合、ルールを半名目チェックに変更しました。 おそらくクラスについても同じことをします。

NPMにリンクされたすべての関連パッケージを備えたTS1.7.5でこれを+1します。 問題を示すテストケースを作成しようとしましたが、できませんでした。 何を試しても、アプリケーションでTS2345で失敗するシナリオでは、TSは問題ありませんでした。私が知る限り、問題のある.d.tsファイルのすべてのコピーは同じファイルへのシンボリックリンクであったため、存在しないはずです。タイプ内で異なる宣言が行われています。 ただし、Typescriptによって発行されたエラーが、2つの互換性のないタイプを宣言したファイルを参照している場合は、私が考慮していないことに光を当てる可能性があるため、便利です。 現在、2つの定義があると書かれていますが、開発者が問題を特定するのに役立つことは何もありません。

回避策として、競合する式で<any>して、型チェックをスキップできます。 明らかに、これまでは必要なかったかもしれない別の型注釈を行う必要があるかもしれません。 誰かがこの問題をいつか切り分けることができるといいのですが。

編集：私の場合、NPMリンクが機能していることを明確にしました

TS 1.8が利用可能であり、アップグレードされており、そのバージョンでも問題が発生していることに注意してください。

この問題の分析と文書化にご尽力いただき、ありがとうございます。 一部のコードベースでも同じ問題が発生しています。 package.json依存関係を適切に使用するようにいくつかのプロジェクトを移植しましたが、開発中にnpm linkを使用すると、これが発生するようになりました。

この問題を解決するために私が助けることができるものはありますか？

パッケージをシンボリックリンクするLernaを使用していて、そこでも問題が発生しています。 Typescriptバージョン2.0.3。

残念ながら、Lernaとそのシンボリックリンクは厳しい要件であるため、この厄介な回避策を使用して、コンシューマーが適切に型チェックできる一方で、これを正常にコンパイルできるようにしました。

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

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

クラスは非常に小さいので、それほど難しいことではありませんでした。実際に変更されることはないと思います。そのため、これは許容できる回避策であると考えています。

参考までに、 npm linkを使用してこのエラーが発生した結果、ここに到達しました。 誰かがこれの回避策を見つけましたか？

@xogenyは、npmリンクがこの問題をどのように引き起こしているかについて詳しく説明できますか？

@mhegazyさて、上記のようなエラーが発生し始めました（ただし、 rxjsからObservableを使用していた場合、つまり、「タイプ 'Observable'はタイプ 'Observable'に割り当てられません）。もちろん、両方のモジュールでまったく同じバージョンのrxjsからObservableを参照していたため、奇妙に思えました。しかし、タイプが「一致」した場合、エラーが発生しました。最終的に、 @ kimamulaがnpm linkを使用すると、このエラーが発生することをrxjs参照するのではなく、1つのモジュールで必要です）。

それはあなたの質問に答えますか？ 私のケースはここの他のケースと何ら変わらないと思うので、これがあなたに役立つかどうかはわかりません。

特にnpm linkシナリオを有効にするためにTS2.0で作業を行いました（https://github.com/Microsoft/TypeScript/pull/8486および＃8346を参照）。 npmリンクがまだ機能していない場所を確認できるサンプルはありますか？

ええと。 2.0.3を実行しています（確認しました）。 再現可能なケースを作成してみます。

ちなみに、これらのスレッドはTS 2.0の時点でもまだ問題であると示唆しているため、フォローアップする必要があります。

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

Lernaリポジトリで見られる問題は多少関係しているので、 https：//github.com/seansfkelley/typescript-lerna-webpack-sadnessでその。 それはwebpack / ts-loaderのせいかもしれないので、私はそこにもhttps://github.com/TypeStrong/ts-loader/issues/324を提出しました。

typescript 2.0.3を使用していますが、上記のようにObservableでこのエラーが表示されます。

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>'.

私はこれをLernamonorepoパッケージでもヒットしています。 型システムのすべてではありませんが、ほとんどの部分が実パスを使用してファイルを一意に識別するように感じます。 実パスではなくシンボリックリンクパスを使用しているブランチを下に移動すると、タイプは同じですが異なることになります。

これはかなり残酷な問題であり、より複雑なコードベースにのみ影響し、抜本的な対策を講じずに回避することは不可能と思われるので、それに値する注意を払うように皆さんを説得できれば幸いです。 😄

これは、依存関係Aに依存するアプリがあり、依存関係Aが依存関係Bに依存し、依存関係Bのタイプを含むオブジェクトをnpm linkする場合に最も顕著になります。アプリと依存関係Aは両方とも

これにより、深いエラーメッセージが表示されます。ライブラリ内のすべての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または別のビルドツールを使用していますか？ 私の問題は、Webpackを介してコンパイルされた場合にのみ発生するようです（以前のコメントのリンクされたリポジトリを参照してください）。

@seansfkelleyhttps：//github.com/TypeStrong/ts-nodeのように見えます。

そうです、 ts-node （ルートアプリケーション用）を使用しています。 ただし、依存関係はtscコンパイルされたパッケージです。

私はちょうどこの問題に遭遇しました、そしてそれは私たちにとって大きな問題です。なぜなら私たちはバックエンドを多くの小さなライブラリに分割しようとするからです。 開発中、リポジトリをnpmリンクする必要があることがよくあります。 私が遭遇した特定の問題は、これを見つけるように促しましたが、rxjsObservablesとインターフェイスの使用です。

// 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パッケージは公開せず、代わりにJavaScriptスタイルの_プレフィックスを使用します。 私はhttps://github.com/Microsoft/TypeScript/issues/7755でそれにます。これは、 privateが構造的ではなく記名的型システムに入る理由についての同様の議論であり、したがって私の中でそれを禁止しましたバージョンの違いが発生しやすいため、独自のプロジェクト（NPM 2やnpm link ）。

@blakeembreyは、プライベートを避けると言うとき、コード内の何かを変更できることを提案していますか？ Observable型の定義が問題だと思いますよね？

@jeffwhelpleyはい、申し訳ありませんが、あなたのせいではありません。 Observableです。 残念ながら、回避privateアドバイスは非常にスリムで、完全には当てはまりませんでした😄 private使用についてrxjs問題が発生する可能性がありますパブリックインターフェイスにprivate ？

編集：私は以前に問題をフォローし、自分の経験に参加することを避けたので、ほとんどコメントしましたが、 https：//github.com/Microsoft/TypeScript/issues/に似ている代わりに、自分の考えをもう一度書き留めることができると考えました@tomdaleがprivateとprotected削除することを提案している場合、私はしばらく前に同じことをしました）。

@mhegazyから、 npm link問題はないと感じたという印象を受けました。 しかし、それでも私たちや他の人々を悩ませているようです。 だから私はこの問題がどこにあるのかわかりませんか？ TS 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奇妙なことに、私の理解では、定義IDはファイルの場所に関連付けられていました。つまり、 npm linkを使用すると常に問題が発生します（ npm link ed依存関係には独自の依存関係がインストールされるため） 。 おそらく定義IDが変更されました-ファイルハッシュを使用することはTypeScriptの良い回避策かもしれません。 残念ながら、JavaScriptでモジュールが重複するようになるには、さまざまな方法があります（GitHubのnpm install 、 npm install 、手動クローン、バージョンの競合により、同じバージョンが異なる場所に到達する可能性もあります。ノードのモジュール解決アルゴリズムがどのように機能するかなど）。

@blakeembreyおそらく。 しかし、その後、何だったこれについては？

注意してください、私は文句を言っていません。 私はこれが解決されるという希望があるかどうかを理解しようとしています。 @jeffwhelpleyが言及したすべての理由から、これは私たちの側にとって深刻な棘です。

@xogeny私も試していますが、正しく解決されることを望んでいます😄リンクされた問題を読みましたが、2つの（実際の）ファイルがあるかどうかを意味するシンボリックリンクのリアルパスを解決するように設計されています異なる場所に解決されるため、引き続き競合します。 これは、あるプロジェクトから別のプロジェクトにnpm linkを実行すると、両方に独自の依存関係があり、 npm link edパッケージから再エクスポートされたシンボルとは異なる可能性があるためです。

編集：確認できます。すべての問題は2つのファイルが原因です。 npm linkは、リンクしたプロジェクトと同じ依存関係である、リンクしたばかりのリポジトリに依存関係を設定するのが簡単なため、トリガーされます。 簡単な再現は、アプリケーションの2つの異なるレベルで同じ依存関係の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には2つのインストールがあるため、次のようになります。

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>'.

コマンドラインに最適な回避策がありますが、Visual Studioはまだすべて混乱しています： https ：

Windows + Visual Studio 2015の新しい回避策は、 xlibライブラリsrcおよびdistフォルダーをnode_modules\xlib\srcおよびnode_modules\xlib\distフォルダーにrobocopyすることです。消費プロジェクトの。

誰かがそれを望むなら、これが私のrobocopyバッチファイルスクリプトの重要な部分です：

: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を実行できないことは深刻な問題です。 現在のTypeScript寄稿者の1人が、コードベースのどこから調べ始めるかについて少しガイダンスをくれたら、PRを手伝いたいと思います。

私もこれに苦労しています。 小さなアプリから始めてTSを採用しましたが、今ではサブモジュールに分割してリンクし、…BOOM。 TSはもうコンパイルされません。 これはまだすべてのTSdist-tagsの問題ですか？ 私は現在@rc （2.1.1）でこれを経験しています。

@heruanと@jeffwhelpleyでtypescript@nextを試してみてください。いくつかの関連する問題を修正しました。 それでも問題が発生する場合は、プロジェクトの設定に関する詳細情報を提供してください。

@mhegazy私はVersion 2.2.0-dev.20161129を使用していますが、まだ問題が発生しています。 特定の問題は、次のように「インターフェイス」（クラスを使用しますが、クラスをAngular 2 DIのトークンとして使用できるようにするため）を含む1つのプロジェクト（ProjectAと呼びます）があることです。

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

次に、次のような最初のプロジェクトからのインターフェイスを実装するクラスを持つ完全に別のプロジェクト（ProjectBと呼びましょう）で：

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の通常のtypescriptコンパイルを実行すると、正常に機能します。 しかし、ProjectBルートディレクトリからnpm link ProjectAから、もう一度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>'.

模擬プロジェクトで複製できませんでした。問題の原因が欠落しているため、複製できません。 @jeffwhelpley問題を複製したモックプロジェクトを公開できますか？ Lernaプロジェクトは問題なく、簡単にテストできるはずだと思います。

@heruan私はそれを設定しようとします。

1つは、参考までに。 私は回避策を見つけたかもしれないと思います。 ProjectAとProjectBの両方でnpm link rxjs 、問題は解決します。 その場合、ProjectAとProjectBの両方がまったく同じrxjsファイルを使用しているため、この種の意味があります。 それがなければ、彼らは技術的に異なるファイルを使用しています（同じバージョンであっても）：

ProjectBからnpm link ProjectAだけの場合、次のようになります。

• ProjectBはnode_modules / rxjsを指しています
• ProjectAはnode_modules / ProjectAにシンボリックリンクとして存在し、それが参照するrxjsはnode_modules / ProjectA / node_modules / rxjsにあります。

ただし、両方でnpm link rxjsすると、これらのrxjs参照の両方が同じ正確にグローバルなnpmの場所にシンボリックリンクされます。

とにかく、これは明らかにまだ理想的ではありませんが、少なくとも私たちを前進させることができる何かです。

また...これが関連するか重要かはわかりませんが（テストプロジェクトを設定すると表示されます）、2つのライブラリ（つまり、ProjectAとProjectB）は実際にはプライベートnpmリポジトリです。

ヒントをありがとう@jeffwhelpley 、しかし私はLernaを使用しているので、すべてのモジュールはすでに相互にリンクされているので、同じファイルを読み取りますが、TSコンパイラは実際のパスではなくリンクパスを考慮していると思います。 模擬プロジェクトでは再現できないので、間違っているかもしれません。本当に怒ってしまいます…

ここでエレガントな方法でこれを解決できる人はいますか？

また、これはnpm link問題だけではなく、共有依存関係が別のバージョンを指している場合、本番ビルドでもこの問題が発生することに注意してください。

すなわち。 ProjectAには[email protected]が必要で、ProjectBは[email protected]

ProjectAをProjectBの依存関係としてインストールすると、タイプが重複することになります。たとえば、2つのObservable宣言があり、1つはnode_modules/rxjs 、もう1つはnode_modules/project_a/node_modules/rxjs

ProjectAのrxjsバージョンを~4.9.0ようにすることでこれを回避できます。これにより、 npm installは独自のバージョンをダウンロードする必要がなくなり、代わりにProjectBバージョンが使用されます。 ただし、これは開発ワークフローの問題だけではないことに注意してください。

@ andy-msの提案に従ってここに投稿します。 昨日、最新の2.0.xでもう一度試してみましたが、まだありました。

Angular 1のタイピングでこれを取得しています： //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私が始めたハックの1つは、lerna機能を使用する代わりに、リンク/リンク解除用の独自のnpmスクリプトを実装することです。 したがって、 lerna run linkようなことを行うと、すべてのpackage.jsonファイルにlinkというnpmスクリプトがあり、（私の場合は） npm link rxjsを含むすべてのnpmリンクを実行します。

@jeffwhelpleyここでソリューションを共有できますか？

@yvoronenすべてのコードを共有することはできませんが、私の解決策は上記のとおりです。 大まかに言えば、私が見つけた鍵は、作業中のすべてのローカルプロジェクトだけでなく、問題の原因となっている可能性のある外部ライブラリもnpmリンクすることです（私の場合、rxjsが問題です。 Observableオブジェクトのプライベート変数）。 そのため、 lernaを使用してすべてのローカルプロジェクトを管理してから、 lerna run linkます。 シーンの下では、これは私のプロジェクトの各ルートフォルダー内でnpm run link呼び出します。 したがって、package.jsonで次のように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"
  }

うまくいけばそれは理にかなっていますが、質問があれば私に知らせてください。

アップデートを提供したかった。 @mhegazyとの

• バージョンと解像度名に基づいてパッケージを区別するという概念を検討している1つのソリューション。 これに何が関係するのかについての完全な詳細はありません。
• もう1つは、パスを完全に拡張して、シンボリックリンクの「真の」アイデンティティを取得することです。 これは簡単だと思いますが、異なるバージョンで同じパッケージを処理する場合はさらに制限されますが、かなりの数のケースを解決するのに役立ちます。

あなたのコメントがこの問題に属していると確信していますか？ 完全に聞こえます
違います。

木、2017年1月12日には、午前3時14分AMニコスの[email protected]は書きました：

タイプやnpmリンクAFAIKを使用していないことに注意してください。

【画像：画像】
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これが、最初に問題が発生する理由です。 TypeScriptは、シンボリックリンクされたパスと実際のパスを区別できなかったため、クラス宣言を2つの別個の宣言として認識します。 解決策は次のいずれかです

1. シンボリックリンクを展開します。
2. 含まれているパッケージが同じかどうかを確認します。

@DanielRosenwasser申し訳ありませんが、私のコメントが...「*>書いた。@、3:14ニコス木、2017年1月12日には」誰か他の人のコメントに反応したことが誰であるか、どのような彼らは、私はもはやリコール言った、私は彼らと信じてこのコメントスレッドで、npmリンクとは何の関係もない問題について質問していました。

しかし、私がここにいる間、ファイル名が型で役割を果たす方法について何か面白いことがあることに言及する必要があります。 今日、私はRxJSで問題が発生し、そのようなメソッドがObservableで定義されていないと文句を言いました。 その理由は、HTTPライブラリには、他のすべてのライブラリとは異なる独自のrxjsのプライベートコピーがあったためです。 実際、node_modulesツリーでrxjsの4つの異なるコピーを見つけました。

これは問題のあるアプローチのようであり、問​​題があり混乱し続けるでしょう。

型のアイデンティティに何らかの役割を果たしているファイル名のこの概念全体がなくなった場合、このnpmリンクの問題もなくなると思います。

私はそれがどのように機能するかについてまだ少し曖昧です...私はTypeScriptに不慣れです。 しかし、それは私が得ている一種の印象です。この「ファイル名が重要」なことは、私が使用しているライブラリ（ionic2とangular2とrxjs）に関連してかなりの混乱を引き起こしました。

問題は、ファイル名がまだJavascriptのモジュールのIDであるため、完全に削除できないことです。 複数のパッケージバージョンに関して、正規パス（シンボリックリンクの解決）を使用する際の問題について誰かが詳しく説明できますか？ ツリー内に複数のパッケージバージョンがある場合、それらには複数の正規の絶対パスがありますよね？

編集：私は投稿後にこれに気づきました、そしてこのコメントはそれをうまく要約しています：
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プロジェクトパスで、エラーは次のように表示されます。

excludes / includes / typesRootの可能なすべての組み合わせを試しましたが、tscにそれらを無視させることができませんでした。 2.2-dev.20170131を使用

この問題は、「npmlink」を使用した場合（@waldekmastykarzによって報告されたSPFxの問題を介して）と「npmlink」を使用しない場合（バグ＃11436を参照）の両方で発生しました。

私は最終的に、TypeScriptコンパイラの厳密さは、 node_modulesフォルダの奇抜な設計が原因で現実的に発生する可能性のある非互換性によるものであることに

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]

この例では、 AのB @ 1への依存関係との競合を回避するために、 B @ 2をサブフォルダーにインストールする必要があります。 ここで、ClassBがClassEから拡張され、次のようなものがあるとします。

B / package.json

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

Cのpackage.jsonがE @ 3.4を要求したがあります。つまり、実際にがありません。 それらを同じ意味で使用しようとすると、実行時にコードが失敗する可能性があります。

この例では、TS2345がその間違いを防ぎます。これは素晴らしいことです。 ただし、必須ではありません。コンパイラが2つのClassBコピーを同等として扱った場合、その型システムは内部的に一貫性があり、決定論的な動作をします。

TS2345は主に誤警報を生成するため、これは重要です。 これらの誤警報は、NPMパッケージ間でタイプを共有する場合は常に、「任意に」書き込むことを強制し、他の間違いを引き起こします。 したがって、厳格さはそれが解決するよりも多くの問題を生み出しています。

次の修正を提案したいと思います。

これらの条件がすべて当てはまる場合は、プライベートメンバーを持つクラスのTS2345を報告しないでください。

1. パブリック署名は、通常のTypeScriptダックタイピングに従って互換性があります
2. クラスは、同じ名前とバージョンのNPMパッケージフォルダーで定義されます（package.jsonによる）
3. クラスのモジュールの相対パスは同じです（例： "./ lib / blah / Bdts"）

これらの基準のいずれかが満たされていない場合は、TS2345を報告しても問題ありません。

@iclanton @ nickpape-msft

@seansfkelleyWebpackエラーはTypeStrong / ts-loader＃468によって追跡されます

こんにちは、みんな、
誰かが解決策を見つけましたか？
RxJSを使用してプロジェクトを別のプロジェクトにリンクすると、同じ問題が発生します。
ありがとう;）

こんにちは。一時的な回避策は、依存関係によって返されたObservableをObservable#fromラップすることです。

まだ解決策はありません。 ？

ここには2つの問題があるようです。

ts-loaderのユーザーが重複した定義に対して誤ったエラーを受け取るのは、コンパイラAPIへの無効な入力が原因のようです。 その修正はTypeStrong / ts-loader＃468で入手できます。

もう1つの問題は、同じパッケージ（同じnpmパッケージ+バージョン）がファイルシステム（ npm linkを使用しない）の2つのネストされたフォルダーに、列挙型またはプライベートメンバーを持つクラスのいずれかでローカルに2回インストールされている場合、これら2つのパッケージの型は、互換性がないため失敗します。
この問題はもう少し複雑であり、コンパイラがパッケージを処理する前にパッケージを「重複排除」するための追加の作業が必要になります。

これらの2つのカテゴリのいずれにも当てはまらない場合は、新しい問題を提出し、問題をローカルで再現するのに十分な情報を提供してください。さらに調査させていただきます。

既知の回避策は、重複フォルダーを排除するマルチプロジェクトソリューションを使用することです。つまり、両方のnode_modulesサブフォルダーが同じターゲットにシンボリックリンクされるようにします。

Rush （私たちが使用する）とLernaがその例です。

@smcatalaあなたはあなたの解決策を説明することができます。 私はそれを緊急に修正する必要があります。 ありがとう。

@ leovo2708
モジュール 'foo'：

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

モジュール '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以降に変更/修正されているかどうかを確認していませんが、ts2.1の回避策を共有したいと思います。

役に立つ場合は、列挙型の複数の定義の最小限の再現をここにまとめました： https ：

@mhegazy npmリンクを使用すると上記の問題が発生しますが、それが残りの分析に影響を与えるとは思わない。

どうもありがとう、それがすぐに修正されることを願っています。 ただし、新しいソリューションを使用し、Observableを使用してファイルを複製しました。 それは良くありませんが、一時的な解決策にすぎません。

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 ：

パスに「../」プレフィックスがないことを除いて、基本的に上記の@charpeniのソリューションと同じです。 （これは、tsconfig.jsonファイルがプロジェクトルートのサブフォルダーにあることを意味しないので、奇妙に思えますか？）

それは素晴らしいアイデアです@charpeni。 私はそのパス設定を使用して他のさまざまな同様の問題を回避しましたが、これも理想的です。 実際、（消費されたすべてのプロジェクトではなく）消費プロジェクトで正しいpaths設定を行うと、TypeScriptコンパイラがノードの解決に従わなくなる可能性があるのではないかと思います。 それが機能する場合、それは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/*"]
        }
    }
}

npmリンクは、モノリポジトリアーキテクチャではなく、複数のパッケージを操作する場合のワークフローの重要な部分です。 TSは、2つのパッケージが同一であり、エラーではないことを確認できるはずです。

@charpeni回避策を機能させることができませんでした。 明確にするために、これをどのtsconfig.jsonに追加する必要がありますか？ ルートパッケージ、またはリンクされたパッケージ？

私もこの問題を経験しています。 それは月曜日に突然起こり始めました、そして私は理由がわかりません。 これは、特に私たちのプロジェクトのパッケージを開発することになると、開発を本当に妨げています。 私はこれを修正するために多くの回避策を試しました。 Windowsでmklink /jを実行してもこの問題が発生するため、npmリンクの問題ではありません。 誰かが回避策や修正を持っている場合、これは大きな助けになります。

私の回避策は、ルートパッケージと依存関係の両方ですべての「重複」パッケージをnpmリンクすることです。これは、それらが同じファイルを再び参照するためです。

ところで、この問題は@typesとは何の関係もありません

最終的にグロブパターンを使用しました。

@felixfbecker実装については、 https ：

@ types / nodeに完全に関連していることを除いて、同様の問題があります。

libAは@node / typesに依存します
libBはlibAと@node / typesに依存します
libCは、libA、libB、および@ node / typesに依存します

libAは正常にビルドされます。
libAビルドファイルにリンクされたlibBnpm。
libAおよびlibBにリンクされたlibCnpmは、次のようなエラーでタイプチェックに失敗します

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'.

運が悪かったので、「types」と「typeRoots」をいじってみました。

@charpeniプロジェクトも

@nicksnyderはバージョンが異なるためである可能性があり、 @types/nodeはグローバル宣言です。つまり、同じ名前を2回定義することはできません。 これが、パッケージが環境の型に依存しないことが最善である理由です。これらはユーザーが提供する必要があります。
https://github.com/Microsoft/types-publisher/issues/107

@nicksnyder同様の問題があり、3つのプロジェクトすべてを単一の@ types / nodeインストールにnpmでリンクすることで回避できました。 定義は同じファイルで定義されるため、重複しなくなります

@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です私自身のVSCode拡張です。

@uncleramsayどのくらい正確にnpm link @types/nodeか？

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

リンクソリューションを実行したいのですが、libAとlibBの@ types / node依存関係を削除してこれをハックし、libCのノードのコピーへのローカル参照を含むrefs.d.tsを追加しました。

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

https://github.com/Microsoft/TypeScript/issues/9091#issuecomment -225303098のコメントの説明から、発生していた問題を解決できたことがわかりました

モジュールのシンボリックリンク解決のサポートのみを追加しました...

2つの異なる参照スタイルを使用していたときのコードベースの別々の場所：

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

node_modulesがシンボリックリンクされている場合、モジュール解決（ types= ）は実パスに拡張されますが、 path=は拡張されないため、これら2つは互換性がありません。 これにより、 tsc --listFilesでコンパイルするときに、シンボリックリンクとリアルパスの2つの異なるファイルが参照されます。

私たちが行った解決策は、どちらか一方を使用することでしたが、両方を使用することはありませんでした。 また、 reference path=スタイルを使用する場合に、コンパイラがnode_modules/@typesから型を自動的にロードしないように、tsconfigでtypeRoots: []を指定するのにも役立ちました。

今後の好みは（少なくとも私たちにとっては） 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-c​​ontain-peer-dependencies/

ピアの依存関係は、プラグインがそれがどうなるかを言いたがっている状況のために発明されました。 彼らはその場合は大丈夫です。 しかし、「npm install」の重複を避けたいと考えて、すべての依存関係をピアの依存関係に変換し始めると、多くの問題が発生します。

私たちは、内部のgitリポジトリからそれらを追放するのに何ヶ月も費やしました。 あなたが示唆しているように使用すると、ピアの依存関係により、いくつかの新しい問題と交換することで、バージョン管理の問題を並べて解決できます。

• ツリー全体が反転します。つまり、すべてのパッケージが、以前は間接的な依存関係であったパッケージにハードな依存関係をとる責任があります。多くの場合、それが何のためにあるのかわかりません。

• ピアの依存関係が削除された場合、これらのハードな依存関係はおそらく削除されません

• パッケージの作成者は、ピアバージョンのパターンに幅広い範囲を使用したいと考えており、実際にテストしたことのないバージョンで動作すると主張しています。 壊れたビルドは突然消費者の問題になります

よく言った。

回避策

これが私が使用した回避策の3つのオプションです：

オプション1：VisualStudioではなくvscodeを使用する

tscコンパイラは、VS2017よりもはるかに寛容です。おそらくVS2017がコード（シンボリックリンクされたnode_modulesを含む）をクロールして優れたインテリセンスを提供し、混乱するためです。 しかし、私は大きくて複雑なmulti-npm-moduleプロジェクトを持っているので、VS2017を使用してください...同様のニーズがある場合は、オプション2と3を読んでください...。

オプション2： d.ts放出する

outDirとrootDir （ tsconfig.json ）を使用する場合、シンボリックリンクされたlib-moduleはd.ts宣言を発行する必要があり、それらの宣言はlib-module内にある必要があります。 package.json typesプロパティ。

これは、libモジュールの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"
  ]
}

また、lib-moduleのpackage.jsonは、次のようなものが含まれている必要があります。

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

このオプションはうまく機能します。主な問題は、Visual Studioでデバッグまたは「定義に移動」または「すべての参照を表示」すると、実際のタイプスクリプトソースファイルではなくd.tsが表示され、 Visual Studioの主な利点（大きなプロジェクトでのナビゲーション）

これの実際の例を実際に見たい場合は、npmモジュールxlib v8.5.xを見てください。

オプション3：ソースとインラインで.js放出する（私のお気に入りの選択）

.tsファイルを直接使用して、シンボリックリンクされたlib-modulesを入力できます。 ただし、 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"
  ]
}

lib-moduleのpackage.jsonを次のように変更する必要があります。

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

警告（オプション3では機能しないもの）

上記の回避策は、各lib-moduleが冗長な型情報を出力しない場合にのみ機能します。 たとえば、以前はxlibライブラリで@types/async型の定義を公開していました。 しかし、それから私はまた独立して@types/async参照する別のライブラリを持っていました。 .tsファイルを直接入力に使用すると、 tsc asyncは2つのlib-modulesからduplicate identifier問題が発生します。 これを解決するに@types 、複数のlib-modulesから同じ.d.ts回避策を使用する必要があります。

概要

これにより、私にかかった時間を節約できることを願っています。全体として、これは非常に苦痛であり、typescriptチームがシンボリックリンクされたモジュールを修正できることを願っています。 しかし、少なくとも今はある程度機能します（2.xより前は基本的に不可能でした）

@mhegazyによってhttps://github.com/Microsoft/TypeScript/issues/11916#issuecomment-257130001に投稿された回避策（回避策2 @jasonswearingenのバリエーション）は、lernaプロジェクトでリンクされたモジュールを使用するときにこれを解決しました！

私は自分の経験を共有しようと思っていました... libを他のプロジェクト間で共有できるように、既存のプロジェクトからlibを作成/抽出しようとしています。

Windows 10 Enterprise
VS2015アップデート3
VS2015用ツール2.2.2
VSコード1.12.2
Typescript 2.2.2
NPM：3.10.9
ノード：6.9.2

Angular4.1.xフロントエンドを備えたVS2015 ASP.MVCプロジェクトがあり、他のプロジェクトで使用できるように、いくつかのコンポーネントを抽出して共通のライブラリを作成し始めました。

ライブラリプロジェクトはVSCodeを使用して構築され、ロールアップを使用してes2015、es5、およびumdバージョンを適切なd.tsファイルとともにdistフォルダーに構築します。

最終結果は次のようになります。

-- 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

dist / mylibフォルダーをVS2015 / Angular4.1.xプロジェクトのフォルダーにnpmリンクしました。

VS 2015でプロジェクトをコンパイルしようとすると、サブスクリプション、オブザーバブルなどの上記の状況のいくつかで説明したのと同じタイプのメッセージが表示されます。

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

ライブラリプロジェクトからnode_modulesディレクトリを一時的に削除すると、モジュールが見つからないことを訴える新しいエラーが発生します。

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

これは、typescriptコンパイラがアプリケーションをコンパイルするときに、アプリケーションのnode_modulesフォルダーではなく、リンクされたライブラリパッケージのnode_modulesフォルダーでライブラリのモジュール定義を実際に検索するという結論に導きます。

上で提案されたどの解決策がこの問題の回避策を提供するかは私にはわかりません。誰かが私を助けてくれませんか？

ありがとう！

@mikehutter （ライブラリ自体ではなく）ライブラリを使用するプロジェクトで、tsconfigで次のようにします。

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

tsconfigとソースコードの結果によっては、これを少し調整する必要がある場合があります。

（このスレッドの他の人と同じように、これを不要にするTypeScriptの改善を期待しています。）

@mikehutter最近、リンクされたライブラリを操作するためのガイダンスをAngular CLIに追加しました。あなたの場合、コンシューマーアプリでRxJのTypeScriptパス構成が欠落しているようです。 詳細については、 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フォルダーで検索し、次に通常のルールにフォールバックします（ここからディレクトリを再帰的にウォークアップします）。インポートが発生しました）。

（私が間違っている場合は訂正してください。私はまだTSの比較的新しい人です）。

pathsのエントリは、 baseUrlです。 したがって、 baseUrlをサブフォルダーに設定する場合は、それに応じてパス定義を変更する必要があります。 例えば：

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

@fiznool fyiは、私の回避策オプション2および3（上記の投稿）の一部です。 同じ型を使用するシンボリックリンクされたプロジェクトがある場合は、 pathsプロパティを設定するだけでは不十分であることがわかりました。

@jasonswearingenあなたの投稿は私のものよりもはるかに包括的です...それをクリアしてくれてありがとう。 これ以上問題が発生した場合は、必ず参照してください。 😄

これはGoogleプロジェクトでも見られます。 ここで説明されているように：
https://github.com/Microsoft/TypeScript/issues/9091#issuecomment -306969543

baseUrlとパスを使用した上記の回避策は機能していないようですが、tscは引き続き重複する定義を取得し、paths / baseUrl / include / exclude / etcの組み合わせはありません。 そうでなければそれを納得させることができました。

Xに依存し、他動詞的にXに依存するYにも依存するプロジェクトがある場合、これがどのように正常に機能するのか興味があります。tscはどのようにして型定義を2回ロードしないようにしますか？

@esprehnここで回避策の投稿を読むことを強くお勧めします： https ：

そのリンクに関しては、私のソリューション（2と3）はどちらも、baseUrlとパスを設定するだけでは不十分なので、それだけの場合は、もう一度お読みください。 「簡単な」方法はソリューション2ですが、Visual Studioを介して適切な「定義へのナビゲート」が可能になるため、私の好みはソリューション3です。 ソリューション3の問題は、依存関係チェーンで外部.d.ts定義を1回だけロードする必要があることです。

それがお役に立てば幸いです。

+1私はlernaを使用しており、タイプが含まれているサブ依存関係は、リンクされた依存関係を介して含まれている場合、「重複」としてフラグが付けられます。

必要に応じてコードを共有できます。

Angular-CLIのようにWebPackを使用して、そのAngular-CLIpackage.jsonにRXJSパッケージを

この状況は、シンボリックリンクではなく、していないだけで起こるかもしれnpm-shrinkwrap.json依存関係にあると@types/nodeでdependencies 。 Shrinkwrapは、 npm 2つの同一バージョンの@types/nodeを親パッケージとシュリンクラップされたパッケージにインストールさせます。 https://github.com/KingHenne/custom-tslint-formatters/issues/5を参照して

また、 @types/reactインストールされているreactプロジェクトを使用し、それを@types/react使用するアプリにリンクするときにもこれに遭遇しました。

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つの異なるバージョンが問題を引き起こしました。

これは、モノリポジトリで作業する場合の大きなブロッカーです。 これがもはや遅れず、2.5への道を見つけることを本当に望んでいます。

編集：😮

面白い。 モノレポは、シンボリックリンクがすべてを共通のパッケージフォルダーに戻すため、私のチームがこの問題に遭遇しない1つのシナリオです。

私のチームは、開発中に独自の内部ライブラリをリンクするときに、この問題に頻繁に遭遇しました。

最近、これを非常にうまく軽減し、実際にかなり良い開発ループを作成する

この問題は継続的に押し戻されているようです。 これは非常に多くの人々のワークフローを本当に混乱させるので、＃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. パブリック署名は、通常のTypeScriptダックタイピングに従って互換性があります
2. クラスは、同じ名前とバージョンのNPMパッケージフォルダーで定義されます（package.jsonによる）
3. クラスのモジュールの相対パスは同じです（例： "./ lib / blah / Bdts"）

これらの基準のいずれかが満たされていない場合は、TS2345を報告しても問題ありません。

単純化された修正も現在の状況よりも優れています。たとえば、＃1のみを検討し、おそらくtsconfigを介してオプトインする場合に限ります。 実装するのはかなり安いはずです。

このアプローチには、誤ったアラームを無効にするだけで、既存のセマンティクスを保持するという利点があります。 一方、node_modulesの再マッピングハックは、NPMモジュールの解像度を潜在的に誤った方法で変更します（たとえば、私が示した架空の例でコードが誤動作する原因になります）。

正直なところ、これをTypescriptで「修正」する必要があるかどうかさえわかりません。これは、プレーンJavaScriptにも問題があるためです。オブジェクトのクラスが提供されたクラスと異なる場合、instanceof演算子はfalseを返します。

したがって、最初にrequire（）にフックする可能性のあるnpmリンクのより良い代替手段を楽しみにしています。

それは良い洞察です。 pnpmを見たことが

交換または使用できないのはnpm linkではなく、同じ@types/xxxパッケージの複数のバージョンを同時にインストールすることであり、多くの場合、依存するTypeScript宣言を提供する依存関係から取得されます。私や他の人々が報告したように、標準的な宣言について。 このようなパッケージの数は、ノードコミュニティでのTypeScriptの採用が増えるにつれて増加します。

@Yoguそれは紛らわしいアイデンティティと平等だと思います。 2つの場所からの同じパッケージ/バージョンのインポートは、タイプの2つの異なるインスタンスを表す場合がありますが、タイプは同じです。

次の（有効な）コードが思い浮かびます。

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

function foo (bar: a) {}

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

インポートするライブラリにも同じことが当てはまります。

異なるバージョンのライブラリ（および対応する@typesパッケージ）からインポートされたタイプは、等しくても異なっていてもかまいません（ライブラリが更新されると、タイプ定義も更新されて変更が反映されます）。

名前とバージョンに基づいて重複パッケージを検出しようとする変更をマージし、1つだけを使用します。 次回公開時にtypescript@nextを使って試してみてください。

やあ、これを修正してくれてありがとう！ :-)

@pgonzal pnpmへのポインタをありがとう、これは間違いなく面白そうです！

@sompylasar @types/nodeは少し特殊なケースですが、 @types/react場合、ここに私の提案があります。モジュールのAPIに必要なすべての依存関係をpeerDependenciesに入れます。 dependenciesは入りません。 これにより、依存関係のバージョンが親モジュールと子モジュールの間で一致する（または少なくとも互換性がある）必要があることが明確になります。 親と子の両方がreactを使用しているが、reactタイプのオブジェクトを交換しない場合、ここでのこの問題はそもそも発生しません。

@harangueクラスが同じ名前と同じ構造を持つ2つの異なるファイルで2回宣言されている場合でも、JavaScriptでは同等と見なされない2つの異なるクラスがあります。 前述したように、 instanceof演算子は、2つのクラスのインスタンスを区別します。

デモについては、このフィドルを参照してください。

これが、TypeScriptよりもNPMレベルでこれを解決したい理由です（したがって、意図されていない場合は、そもそも複数の宣言はありません）。

@Yogu ：+1：したがって、 @types/nodeが特殊なケースである場合、つまり2つの異なるノードバージョンを同時に使用してプログラムを実行できない場合、それは1つのバージョンになり、おそらくで指定されたバージョンになります。トップレベルのパッケージ、多分TypeScriptはそれを特別な場合として扱うべきです、例えば常にすべての依存関係にトップレベルの@types/nodeを使用しますか？

@ andy-msありがとうございます！

次回公開時にtypescript @ nextを使って試してみてください。

それはまだ起こっていないと思います。 私はいくつかのプロジェクトでそれを試しましたが、今のところ運がありません。 nextが利用可能になり次第、このスレッドで更新を確認できると便利です。 @ andy-ms

デイリービルドが再び停止したようです。 最後は2.5.0-dev.20170808 。

cc / @DanielRosenwasser

これが関連しているかどうかはわかりませんが、2.5.1を試してみると、他の場所にd.tsが拡張されている場合でも、モジュールの1つの側面しか表示されないようです。

何かに@typesがある場合、 @types/mongodbとしましょう。そのモジュールを拡張するカスタム宣言がある場合、つまりメソッドに約束を追加する場合、 @types/mongodbあります。モジュールmongodbと、 mongodbモジュールを含むmongo-promisification.d.tsような名前のd.tsファイルがプロジェクトにあります。

したがって、上記のシナリオでは、 import {somethingFromTypes} from "mongodb"を含むファイルがあり、typesモジュールからのデータが存在し、有効であるにもかかわらず見つからないと文句を言いますが、 import {somethingFromMyExtendingDts} from "mongodb"を実行した場合は機能します大丈夫。

コンパイルすると、モジュールはそのようなものをエクスポートしないと言われますが、エクスポートする場合は、この望ましい動作であり、カスタムd.tsで再エクスポートする必要があります。または、タイプと拡張子d.tsの両方を取り込む必要があります。私は持っています？

最新のテストビルド（Windows 10 64ビット）を実行していますが、これは修正されていないようです。

再生

構造

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

実行

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

a / index.ts

import { Observable } from 'rxjs/Observable';

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

b / 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);

実行

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あなたの状況での問題は、モジュールの2つの宣言があることだと思います。必要なのは、モジュールと拡張です。
次のように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に感謝します-これはゲームチェンジャーです！

Observableをインポートしたときに同じ問題が発生しましたライブラリTypescriptを介してangular-cliプロジェクトにアクセスし、関数はコードスニペットを使用していました

`` `function getitems（）：Observable
http.get（）。map（response：Response）=> {
戻る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();
}

@ Basel78エラーを再現するには、完全な例が必要です。 また、 typescript@nextを使用していることを確認してください。angular-cliでは、重複排除機能がない古いバージョンを使用している可能性があります。

[email protected]を試しましたが、それでも多くのエラーが発生しますTS2300：識別子が重複しています。
残念ながら、プロジェクト全体を共有することはできません。 しかし、ここにいくつかの詳細があります：
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/*" ]
      }
    }

@ evil-shrikeプロジェクトを、問題を示す簡単な例に減らすことができますか？

@mhegazyここにあります
https://github.com/evil-shrike/typescript-npmlink-issue
プロジェクトルート：

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

次にmain ：

npm run tsc

こんにちは@ evil-shrike、私は問題を以下に絞り込みました：
lib / tsconfig.json

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

main / 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-ms
簡単なことではありません。 私の場合、参照されるlibには、たとえばグローバルインターフェイスを拡張するアンビエントd.tsがたくさんあります。 JQueryStaticのように：

interface JQueryStatic {
    cleanData (elems);
}

またはロードされたプレフィックスを宣言します（requirejs）：

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

次に、libのソースのどこかでそれらを使用します。

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

そのようなモジュール（libから）がmainのどこかにインポートされると、コンパイルに失敗します。

ライブラリのソースでは、 /// <reference types="" /> （または/// <reference path="" /> ）ディレクティブを使用して、ライブラリがインポートされるたびに必要な型が存在することを確認する必要があります。 そうすれば、「含める」必要はありません。 インポートされると、参照されているタイプがプロジェクトに自動的に追加されます。

@ andy-msありがとう、libをリファクタリングし、npm-link-edが正常にコンパイルされているプロジェクトになりました。

これらが大きすぎる複製であるかどうかはわかりませんが、 Observable<T> !== Observable<T>するためにangular @nextと

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

青は赤からコンポーネントとサービスをインポートして使用します

@intellix tscコマンドラインのみを使用してエラーが発生する例を取得できますか？ タイプスクリプトngのどのバージョンが使用されているかわかりません。

@ andy-msまだこの問題が発生しています。 これは、構築しているvscode拡張機能間でnpmリンクを使用しようとしたときに発生します。 それらはすべてvscodeをインポートするため、重複した識別子エラーが発生します。
TS Version 2.7.0-dev.20171118

私の場合、たとえば「rxjs / *」を、tsconfigファイルのpathsセクションにあるnode_modules内の特定のrxjsフォルダーにマップしました。
これで、npmリンクですべてが正常に機能します。

また、バージョン更新リンクからパッケージへのシンボリックリンクから非シンボリックリンクに移行するときにこれが発生することも確認しました。

このSOの質問も参照してください： https ：

@ dakaraphi @ JoshuaKGoldbergこれらのシナリオを再現するための手順を教えてください。

新しい動作では、 package.json同じ「バージョン」値を持つ別のパッケージがすでに表示されている場合は、パッケージを含めないでください。 バージョンが異なる複数のインストールがある場合は、モジュールの2つの異なるコピーを取得します。 これは、2つのインストールのうちの一方にのみ影響する場合、バージョン更新がこれを壊す理由を説明している可能性があります。

@ andy-ms私が持っている例は、次のリポジトリです。

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

ローカルのnpminstallを使用して、 vscode-extension-commonからvscode-extension-fold vscode-extension-commonを参照します

これらのリポジトリをチェックアウトすると、 package.jsonのvscode-extension-fold package.jsonにパスマッピングの回避策があるため、現在は機能しています。 ただし、正しく理解していれば、その回避策は必要ありません。

@dakaraphiありがとう！ このエラーは、 vscode.d.tsが外部モジュールとしてではなく、グローバルなアンビエント宣言として書き込まれていることが原因のようです。 Microsoft / vscode-extension-vscode＃90を作成しました。

それぞれがrxjs依存している2つのパッケージをリンクしようとすると、これはまだ機能しません。 [email protected]と[email protected]ます。 どちらのパッケージもまったく同じバージョンを使用しています。 誰かがこれの回避策を持っていますか？

@SamVerschuerenエラーを再現するための具体的な手順を教えてください。 また、 typescript@nextテストします。

@ andy-ms何ができるか見ていきます！

@ andy-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コンパイルします

ステップ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.

[email protected]でまだこの問題が発生していtypescript @ nextも試しましたが、同じ問題が発生しました。

問題の根本は、リンクされたパッケージが、可能であれば、リンク先の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はファイルをコピーする代わりにシンボリックリンクを使用してこれらをインストールしているようです。

ただし、コンパイルしようとすると、コンパイラーはリンクされた定義ファイルを2つの別個の競合するファイルとして認識します。

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/**/"]設定することでこれを回避できます