2

「Shared」と呼ばれるモジュールを含むd.tsファイルと、NodeJS環境で使用されている場合は同じ名前の変数を含むrequireステートメントが含まれているため、問題が発生していると確信しています。

// shared.d.ts
declare module Shared { ... }

// other_module.ts
/// <reference path="shared.d.ts"/>
if(require) { var Shared = require("shared"); }
export class Something {
    public someVar = new Shared.SomethingElse("blah");
}

したがって、コンパイルするother_module.tsと(実際には多くの個別のファイルです)、Sharedは重複した識別子であることがわかります。これは、TSがSharedをモジュールと見なしているため理解できますが、requireの戻りであると言われています。

ここでの問題は、モジュールの出力が nodeJS の require システムと互換性がある必要があることです。そのため、この場合、other_module が必要な場合、それは独自のスコープ内にあり、認識されないため、require が必要になるShared.SomethingElseため、内部モジュールはother_module共有ライブラリにアクセスできますが、ブラウザ環境ではShared.SomethingElseグローバル スコープを介して取得されます。

Sharedモジュールが nodejs( var otherModule = require("other_module")) にロードされたときに require を削除すると、について知らないため、参照を削除するとファイルはコンパイルされませんShared。それで、これを解決する方法はありますか?

4

1 に答える 1

6

まずエラー

Sharedin shared.d.ts+ inがあるため、識別子が重複していますother_module.ts

FIX A、すべて外部

amd/commonjsつまりを使用したい場合。外部モジュール、使用する必要がありますimport/requirevar/requireあなたがしているのとは異なります)。を使用するとimport、新しい変数宣言スペースSharedが作成されるため、からグローバル名前空間を汚染することはなくなりますother_module.ts。要するに :

// shared.d.ts
declare module Shared { 
   export function SomethingElse(arg:string):any;
}
declare module 'shared'{ 
    export = Shared; 
}

タイプセーフなインポート:

// other_module.ts

/// <reference path="shared.d.ts"/>
import Shared = require("shared"); 

export class Something {
    public someVar = new Shared.SomethingElse("blah");
}

FIX B、あなたと同じですが、別の名前を使用する必要があります

ローカル スコープがグローバル スコープの場合、名前をローカルで使用other_moduleないでください。修正 A に示すように、external Everywhere を使用し、nodeと browser を使用してコンパイルすることをお勧めしますが、ここで必要な場合は compile fixed .Sharedcommonjsamdother_module.ts

// other_module.ts
/// <reference path="shared.d.ts"/>
var fooShared: typeof Shared;
if(require) {  fooShared = require("shared"); }
else { fooShared = Shared; } 
export class Something {
    public someVar = new fooShared.SomethingElse("blah");
}
于 2014-06-21T11:23:41.033 に答える