Typescript: 強制インポート

書くことで強制的に放出できるはずです

var myExternalModule = require("./myExternalModule");

ただし、「。/myExternalModule」が正しくないパスの場合、これは文句を言いません。

正しいアプローチは、副作用のないダミー参照を導入することです。

import myExternalModule = require("./myExternalModule"); 
myExternalModule;

これはハックですが、このかなり狭いユースケースに新しい構文が導入される可能性はほとんどありません。 設計目標を参照してください

TypeScriptがvar myExternalModule = require("./myExternalModule");のパスを検証する場合、ユーザーはハックに頼ることなく、 emit_および_getコンパイル時検証を強制できます。

var 、

さらに、必要に応じてamd-dependency属性を使用できます。

使われていないものをどのような目的で輸入していますか？

たとえば、Angularアプリでは、他のファイルにいくつかのディレクティブがあります。 これらのディレクティブをインポートする必要があります。そうしないと、HTMLマークアップが機能しません。 ただし、JavaScriptでは使用しません。
通常、Angularでは、ほとんどのモジュールは分離されており、相互に依存関係はありませんが、アプリ全体を機能させるにはインポートする必要があります。

：+1：
それは私を混乱させます。
TypeScriptコンパイラがそれを排除するのはなぜですか？
外部モジュールはインスタンス化されていないモジュールではありません。
requireには副作用があります。
import句は、AMDおよびCommonJSの要件と互換性があるようです。 そうではありません。

この問題は、require（）-ingモジュールが実際には何もエクスポートせず、代わりにes5-shim 、 es6-shimなどのグローバルオブジェクトの機能をシムする場合にも厄介です。

それは私を混乱させます。
TypeScriptコンパイラがそれを排除するのはなぜですか？

モジュールからタイプ情報のみをインポートしたい場合があるため、これは最適化です。

import foo = require('foo');

function bar(paramOne: foo.ParamOne, paramTwo: foo.ParamTwo){}

それは単なる最適化ではありません。 インポートされたモジュールをタイプのみに使用している場合（つまり、値の位置で使用されていない場合）、モジュールは実行時に存在しないアンビエントタイプのみのモジュールである可能性があるため、requireロジックを発行できません。 モジュールインポートを発行すると、存在しないモジュールを読み込もうとしたときにランタイムエラーが発生します。

これにはamd-dependencyフラグを使用できます。

/// <amd-dependency path="foo" />

import x = require('foo');

ちょっとしたハックのように見える<amd-dependency>代わりに、 <reference name="..."> IMOを使用するの

@danquirk TypeScriptエンジンにインポートステートメントの最適化の責任を負わせることは、恣意的で危険なことです。 TypeScriptがJavaScriptからまだキャプチャしていないパターンはたくさんあります。 1つの例は、 thisがタイプ＃229を持つ可能性があることに対処しない方法です。

インポートは、現在のコードがロードされる前に依存関係をロードするために使用され、直接参照することはできません。 角度の依存関係は1つの例ですが、jQueryプラグインは別の例です。 ベースオブジェクトを拡張し、直接参照されないライブラリは、「機能」の影響を受けます。 ローカル静的分析に基づいてインポートを任意に含めないことを決定することにより、インポートステートメントを作成した開発者の明示的な意図にCスタイルのコンパイラパターンを課すことになります。 importの記述には、依存関係として含まれ、モジュールのローカルスコープで使用できることが期待されます。 その他のアクションは、モジュール内にimportを書き込むことを選択するという自然な期待に対する副作用です。

この場合、TypeScriptコンパイラーはより少ないことを行い、より多くのことを達成できる可能性が非常に高いです。

TypeScriptの次のリリースでは、ES6スタイルのモジュールがサポートされます（変更は現在マスターにあります）。 したがって、依存関係を宣言するだけでよい場合は、次を使用できます。

import "myLib";

コンパイラはこのインポートを削除しません。

既存の一貫性のない行動に対処するのでしょうか、それとも人々が発見するのが楽しいものとして残るのでしょうか？ importがファイルを依存関係として追加しない場合であることをドキュメントに追加する必要がありますか？ TypeScript AMDモジュールをビルドするとき、 ///<reference...はエラーと見なされますか？

import現在機能する方法は、悪い設計です。 悪いデザインは曖昧さを生み出します。 追加の動作が明確に定義されていない場合、それは副作用ですが、発見される可能性が高くなります。 したがって、このフォーラムでは、OP、私、およびそれに関連するその他のコメントとバグがあります。

CommonまたはRequireスタイルの依存関係管理を使用する場合にすでに存在する既存の一連のプラクティスがあります。 importの実装は、それが無視されたことを示しています。

ドキュメントについては、仕様のセクション11.2.5およびセクション11.2.6を参照してください。

外部インポート宣言は、生成されたJavaScriptで、モジュールシステムホストによって提供される「require」関数の呼び出しによって初期化される変数として表されます。 インポートされたモジュール、またはインポートされたモジュールを参照するローカルエイリアス（セクション10.3）が、インポートされたモジュールの本体のどこかでPrimaryExpressionとして参照されている場合にのみ、特定のインポートされたモジュールに対して変数宣言と「require」呼び出しが発行されます。 インポートされたモジュールがModuleNameまたはTypeQueryExpressionとしてのみ参照されている場合、何も出力されません_。

///参照はインポートと同じではありません。 ///参照は、domAPIなどの追加の宣言をグローバルスコープにもたらします。 これは、これらのエンティティの存在を信頼するためのコンパイラへのステートメントであり、生成されたコードには影響しません。

一方、インポートは、requireステートメントとして発行する必要があります。 型の位置でインポートのみを使用している場合、意図は明確ではありません。型（実行時に存在しない設計時の構成要素）のみが必要であり、この場合はインポートを省略します。 、そうでない場合は、存在しないタイプのみのモジュールをインポートする可能性があります。 または、副作用も必要です。 後者の場合、 import "mod";構文は、意図を宣言するためのより明確な構文のようです。

@mhegazy新しい号を開きたくないのですが、これはReactの世界では少し問題です。
以下のコードを検討してください。jsにコンパイルすると、 React参照はコードに表示されないため削除され、 ReactRouterはそれに依存するため、コードは失敗します。 修正...本当にばかげているのはコードの下です。 それを取り除くより賢い方法はありますか？ ありがとう。

import * as React from "react"; var temp = React.DOM;
....

// mf("route.schedules", "") // this is to register a translation
anonymousRoutes.route("/schedules", {
  name: "schedules",
  subscriptions: function() {
    this.register("schedules", subscriptions.subscribe("schedules"));
  },
  action: () => {
    ReactLayout.render(ClearLayout, {content: <Book />});
  }
});

修正;）-EHM

import * as React from "react"; var temp = React.DOM;
...

ReactRouterがコードに依存しているため、コードは失敗します。

var "React"が必要ですか、それともインポートによる副作用が必要ですか？

インポートによる副作用が必要です。 varは、トランスパイルされたコードのインポートを削除しないようにするために追加されました。

だからなぜ単に追加しないのですか

import * as React from "react"; // get the types
import "react";  // just for side effect

出力では、最後のインポート： import "react"は省略されません。

残念ながら、このダウは機能せず、私はまだ得ます：

ReferenceError: React is not defined
    at action [as _action] (schedule_router.jsx:15)
    at Route.callAction (kadira_flow-router.js?f961d732ed2b89a53d490af5979b899800aa1a5d:2306)
    at kadira_flow-router.js?f961d732ed2b89a53d490af5979b899800aa1a5d:2025
    at Object.Tracker.nonreactive (tracker.js:560)
    at kadira_flow-router.js?f961d732ed2b89a53d490af5979b899800aa1a5d:2016
    at Tracker.Computation._compute (tracker.js:294)
    at Tracker.Computation._recompute (tracker.js:313)
    at Object.Tracker._runFlush (tracker.js:452)
    at Object.Tracker.flush (tracker.js:412)
    at Router._invalidateTracker (kadira_flow-router.js?f961d732ed2b89a53d490af5979b899800aa1a5d:2065)

ここでの理由は、Meteorの「弱い依存関係」であり、必要なすべての参照を提供するために_callee_に依存していると思います。

私は最近Angular2のtypescriptを学び始めました。これは、他の新規参入者にも当てはまると確信しているので、何度も私を捕らえました。 これは最適化であることを理解していますが、実際には非常に混乱しています。 tsファイルに何かを入力すると、単に無視するのではなく、生成、出力、または何らかの種類のファイルが生成されると予想されます。 requireステートメントを強制的に作成できるようになりましたが、それは少しハッキーなようです。 これは、ユーザーとしての私が、コンパイラーが何が最善かを決定することなく、自分で決定できるはずの原因のように思われます。

TypeScriptは値の上に型宣言をオーバーレイするため、同じインポート構文で型、値、またはその両方を取得できます。 これにより、モジュールの操作が非常に便利で直感的になります。 別のモジュールから型が必要な場合は、変数をインポートするときにそれをインポートするか、クラスをインポートして、型としてもnewのコンストラクターとしても使用します。

これの裏側では、モジュールは単なるタイプコンテナであるため、存在しないモジュールにインポートすることができます。 コンパイラがこれらのモジュールへの参照を発行した場合、実行時に失敗します。 私たちが実施している解決策は、インポートがどのように使用されたかを検出することであり、インポートへのすべての参照が型として使用されるため、実行時に不要であり、省略されます。

モジュールの副作用も必要な場合は、明らかにこれは混乱を招く可能性があります。 しかし、逆に、存在しないモジュールへのインポートが発行された場合も混乱を招きます。同じ構文で型と値をバンドルするという利便性を失う必要があります。

回避策：
従来の解決策を使用している場合（ moduleResolutionがnode設定されていない場合）、識別子に!を含むインポートステートメントが回避されることはありません。 これは、 systemjs動作をより適切にサポートしようとしていることと関係があると思いますが、インポートを強制するために使用できます。 systemjs、requirejs、またはモジュール識別子の再マッピングを可能にするローダーを使用している場合は、強制インポートを!jsまたは同様のマークで終了し、モジュールローダーでマップすることができます。 TSはインポートを逐語的に出力し（タイプチェックや解決を試みません）、ローダーにインポートを理解する方法を教えることができます。

チームは、checker.tsなど、これらのタイプのインポート用に特別なケースのコードを作成する必要があるようです。

// If we're compiling under --jsx react, the symbol 'React' should
// be marked as 'used' so we don't incorrectly elide its import. And if there
// is no 'React' symbol in scope, we should issue an error.
if (compilerOptions.jsx === JsxEmit.React) {
    let reactSym = resolveName(node.tagName, "React", SymbolFlags.Value, Diagnostics.Cannot_find_name_0, "React");
    if (reactSym) {
        getSymbolLinks(reactSym).referenced = true;
    }
}

@mhegazyが指摘しているように、これは最適化だけではなく、ランタイムエラーの原因となるランタイム定義（インターフェイスなど）のないインポートを必要としないようにするためです。

私はどちらがより頻繁に起こるのか疑問に思います。 インポートが* .d.tsであるかどうかを簡単に検出できるため、それらは簡単に削除されます。

残りの場合、インポートされたモジュールにランタイム出力がなく、それらのインポートを削除するだけであることをコンパイラーが検出するのは非常に簡単なことのように思われます。

DRYの観点から、この提案は、あなたのトランスパイラーがこの重複したコードを私のために書くためのトランスパイラーがあればいいのにと思いました。

import * as React from "react"; // get the types
import "react";  // just for side effect

私の見方では、実行時にロードする必要があるかどうかは、_imported_ファイルの選択である必要があります（副作用があることがわかっているため）。 他のファイル/モジュールの実装の詳細を知ることはビジネスではないため、これは実際には_loading_ファイル（つまり、importステートメントを含むファイル）によって決定されるべきではありません。

少なくともこれは、ディレクティブとサービスを定義するファイルが参照された場合に実行時にロードする必要があることを「認識」しているため、コンパイラーがそれを削除してはならない、angularjsの観点からはうまく機能します。 タイプスクリプトコンパイラへのファイル内の「削除しない」ためのある種のヒントは、このIMOを修正します。 しかし、私はおそらくここでいくつかのユースケースを見落としています。

-JM

xmodule.ts：

console.log('ive been imported');
export class X {
}

import {X} from "xmodule"; // get the types
import "xmodule";  // just for side effect

xmoduleにステートメント（例：console.logステートメント）がある場合、それは定義上、単なる宣言の山ではありません。 xmoduleが単なる一連の型宣言以上のものと見なされるようにするために、xmoduleを使用するステートメントを作成することはインポートモジュールの責任ではありません。

@weswigham

インポートを強制するために強打を使用するとおっしゃいました。 それは私のシナリオに適しています。 どうすれば使用できますか？ 次のすべてを試しました：

!import {Service} from './service';
import! {Service} from './service';
import {!Service} from './service';
import {Service!} from './service';
import {Service} from '!./service';
import {Service} from './service!';
import {Service} from !'./service';
import {Service} from './service'!;

文字列内にありましたが、パスマッピングが導入されたときに、この動作は最近削除されたと思います。

私はノードラッパーをインポートするためにreactのようなライブラリを使用しています-h（私が間違っていなければreactではreact（）です）、それで私は次のようにインポートします：

import { h, Component } from "preact";

そして、もちろん、実行時にhはありません。 なぜそこにいるのでしょうか？ また、jsxpreserveと一緒に使用すると、TypeScriptは実際にはhについては認識しませんが、babelはそれを認識します。

したがって、hのような参照を使用して、残っているもの。 インポート後、そうですか？

h （またはその他のカスタムjsxファクトリ）の場合は、 --jsxFactoryを使用して、これが実行時に使用しているファクトリであることをコンパイラに通知します。 例： --jsxFactory h 。

現時点ではtypescript@nextは必要ありませんが、TypeScript2.1.2で利用できるはずです。

@mhegazy 2種類のJSXコンシューマー（reactとsnabbdomなど）があるプロジェクトの場合、これは受け入れられません。

私は、reactを使用してWeb UIをレンダリングし、カスタマイズされた仮想domを使用してwebglオブジェクトをレンダリングするプロジェクトに取り組んでいます。 また、同じプロジェクトに2種類の@jsxアノテーションが必要なため、問題が発生します。

今、私は自分のhをグローバル変数としてエクスポートすることを余儀なくされています...それは醜いです。

これを行うワンライナーインポートを必要とする/望んでいる開発者のリストに私を含めてください。 これを実現するための2行のソースは、特に多数のモジュールを連続してインポートする場合に、排除しようとしているものです。 これまでのところ、私にとって最もよく聞こえたのは、インポートを強制するためのキーワード/構文だと思います。 みんなありがとう！