コンテキストに関係なくすべてのUMDグローバルへのアクセスを許可する代わりに、UMDモジュールが///<reference types=<>>構文のいずれかを介して明示的に「参照」されている（インポートされていない）場合にのみ、UMDグローバルへのアクセスを許可する方が簡単ではないでしょうか。 、またはtsconfig.jsonのtypes構成を介して？

言い換えれば、モジュール内で///<reference types=<>>使用を許可しないのはなぜですか？

/// <reference type="x" />がxが_どこでも_グローバルに利用可能であることを意味すると言った場合、どこかの.d.tsファイルが実際にはグローバルではないものを誤って参照することがよくあります（これは、DefinitelyTypedの2.0ブランチを保守していて、非常に一般的なエラーであるためです。

逆に、それが_そのファイルで_しか利用できない場合は、参照ディレクティブをあちこちにコピーして貼り付ける必要があり、これは本当に面倒です。 これらのディレクティブは通常べき等であるため、ファイル固有の動作を導入するのは奇妙です。

そうですか。 まあ、これが他の誰にも影響を与えていないのであれば、おそらく現在の動作を維持する方が良いでしょう。 モジュールとしてのインポートに完全に移行する必要があります。

編集：これが私以外の多くの人々に影響を与えるのを見てうれしいです。

現在の理論は、モジュールの使用に移行するかどうかを人々に求めることです。 他の人がこれに遭遇した場合は、詳細を調査できるように、使用していたライブラリを正確にコメントに残してください。

私はlodashを使用していますが、これには独自のタイピングは付属していません。 また、ランタイム環境で相対パスインポートステートメントを使用するのが最も簡単な状況もあります。 したがって、インポートステートメントとローカル相対パスおよびフォルダー相対（「./foo」および「N / bar」）の組み合わせがあります。

@types/lodash/index.d.tsをnode_modules/lodash/に手動でコピーすると、タイプチェックを行うことができます。

これまでの私の回避策は///<amd-dependency path='../lodash' name="_"> （ importステートメントは使用していません../lodash ）が残ります。

これがこの問題に十分近いシナリオであることを願っていますか？

明確にできますか

また、ランタイム環境で相対パスインポートステートメントを使用するのが最も簡単な状況もあります。

そして

@types/lodash/index.d.tsをnode_modules/lodash/に手動でコピーすると、タイプチェックを行うことができます。

お願いします？ 私はこのシナリオに精通していないので、これの目的は何ですか、そしてなぜそれが役立つのですか？

こんにちは、みんな、

現在の@types/bluebird宣言の問題の解決策を探しています（時間をかけて読んではいけません）。 .d.tsにexport as namespace Promise;を追加することで問題を解決できることがわかりましたが、このgithubの問題で説明されている問題が発生しました。

要するに、私は以下を機能させたいのです。

1. git clone -b vanilla-es5-umd-restriction-problem https://github.com/d-ph/typescript-bluebird-as-global-promise.git
2. cd typescript-bluebird-as-global-promise
3. npm install
4. export = Bluebird;行の上にexport as namespace Promise;追加して、 node_modules/@types/bluebird/index.d.ts編集します。
5. npm run tsc

現在の結果：
いくつかの'Promise' refers to a UMD global, but the current file is a module. Consider adding an import instead.エラー。

期待される結果：
コンパイルは成功します。

この問題は、開発者のコ​​ードとサードパーティのコード（この場合はRxJS）の両方でのPromise使用によって引き起こされるため、特に困難です。 後者は、 Promiseがグローバル（JS標準で提供）であると想定しているため、たとえばimport Promise from std; // (not that "std" is a thing)を使用するように変更されることはありません。

UMDモジュールをインポート可能なモジュールとグローバルの両方として使用する方法を本当に感謝しています。

ありがとう。

-----------------------------更新

私はこの問題を別の方法で解決することになりました（つまり、 PromiseとPromiseConstructorインターフェイスの拡張によって）。

"globals": [] tsconfigオプションは、どこにでも表示するよりも望ましいようです。 UMD宣言が標準になりつつあるため、誤ってモジュールのインポートを忘れる可能性が高くなっています。 現在の動作を維持することを検討してください。 これはエラーであるはずです。

逸話的に、ポイントリリースでグローバルなwindow.moment変数が削除されたときのことを覚えています。 どこにでも丁寧に輸入していると思っていたのですが、5か所くらい忘れていました。

もちろん、UMDパッケージは実行時にグローバルスコープで使用可能になりますが、いつ使用可能になるかは、他のモジュールがロードされる順序によって異なります。

これに+1。 私はちょうどSystemJSでReactを使おうとしていましたが、Reactはうまくバンドルされていないため、スクリプトタグでCDNから直接ロードしているだけなので、React / ReactDOMオブジェクトはグローバルに利用できます。

ベストプラクティスとしてコードをモジュールとして記述していますが、これはロード時に実行される1つのランタイムスクリプトにバンドルされます（ロールアップ）。 import from react / react-domを実行し、ローダーを「実際には、これらはグローバルではありません」と言うように構成するのは面倒です（そして嘘です）（https：/にあるWebPack構成の例と同様） /www.typescriptlang.org/docs/handbook/react-&-webpack.html）。 モジュールでこれらをグローバルとして利用できるようにする方がはるかに簡単（かつ正確）です。 私が試した手順は、直感的に思えたので、次のとおりです。

1. npm install --save-dev @types/react @types/react-dom
2. 私のtsconfig.json： "jsx": "react", "types": ["react", "react-dom"]
3. 私のモジュール： export function MyComponent() { return <div>{"Hello, world"}</div>; }
4. 同様に： ReactDOM.render(...)

ただし、これによりエラーReact refers to a UMD global, but the current file is a module. Consider adding an import insteadます。

これがうまく機能した場合、これは、モジュールであるコードを装って、そうでないローダー/バンドラーを構成するよりもはるかに簡単です。 （または、以下を含むファイルを追加することで、期待どおりの動作を実現しました。モジュールは、エラーなしでグローバルとしてReact＆ReactDOMを使用できますが、少し醜い/ハッキーです-もっと簡単な方法があるかもしれませんが逃した）：

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

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

オプション3とグローバルにも同意します：[]バックアップ。 これは、新旧のユーザーにはかなり直感的に思え、人々が必要とする正確な機能を提供します。

私はコードの専門家ではないので、2がより好ましいかどうかはわかりませんが、構成が単純であるため、直感的にも理解できると思います。

これらのいずれかを実装するための支援を検討したい場合は、どこに行けばよいですか？

これは本当に旗の後ろにあるはずです。 これは大規模なリファクタリングの危険です。 フラグがデフォルトでtrueに指定されている場合でも。 これは元のシナリオで引き続き機能する必要があると思います。そうしないと、UMD宣言の主な利点が失われます。

Reactはうまくバンドルされていません

@billti詳しく説明していただけますか？

import from react / react-domを実行し、ローダーを「実際にはそうではない、これらはグローバルです」と言うように構成するのは苦痛（そして嘘）です。

チュートリアルでそれを書いた唯一の理由は、 externalsを使用するとバンドル時間が短縮されるためです。 インポートせずにグローバルReact変数を使用する場合、後でモジュールに簡単に切り替えることはできませんが、インポートを使用すると、任意のローダーを柔軟に使用できます。

バンドルを最適化しようとしている方法と観察されたサイズの例については、この問題（https://github.com/rollup/rollup/issues/855）を参照してください。 事実上、（ロールアップを使用した）セットアップでは、Reactをバンドルすることで最小限のサイズの増加が見られたので、CDNから提供したいと思います。 私にとって、これには次の利点があります。

a）私のサイトへのリクエスト（および帯域幅）が少なくなります。
b）ビルドチェーンにバンドルするのにかかる時間が短縮されました。
c）変更をプッシュするたびにクライアントに再ダウンロードするコードが少なくなります（再ダウンロードされるバンドルにはコードのみが含まれ、Reactは変更されずにクライアントキャッシュにあるため、304が取得されます）。

サイトの読み込み時にChrome開発ツールを見ると、GZipped HTTP接続のReactとReact-dom（縮小版）はわずか47kbのネットワークトラフィックであり、サイト上のほとんどの画像よりも少ないので、私はそうではありませんとにかくそれほど大きな利益が得られない限り（たとえば50％の削減）、それだけ削減しようとすることを心配していました。

補遺として：TypeScriptコンパイラ自体には「このモジュールは本当にグローバルです」と言うための構成がないため、このオプションがないと、これらのインポートを排除するバンドラーを使用するように強制されることにも注意してください。実行時に解決されないモジュールのインポート（または要求、定義）を発行します。

@billti SystemJSは、このシナリオを完全にサポートしています。 開発中にローカルにインストールされたパッケージを使用することと、本番環境でCDNを使用することを切り替えることができます。 また、すべてのインポートが、一度フェッチされ、最初に必要になったときにウィンドウオブジェクトにアタッチされるグローバル変数への参照を実際に示す必要があることを指定するメタデータも完全にサポートしています。本番環境では、これはCDNから取得できます。 私はこれをreactで実行していませんが、Angular1.xで実行しました

ありがとう@aluanhaddad 。 興味深い...私は実際に、この障害につながるような何かを機能させようとしていて、それを理解できなかったので、今朝、SystemJSリポジトリで質問しました。 https://github.com/systemjs/systemjs/issues/1510を達成する方法に答えることができれば、それは本当に役に立ちます:-)

注：コードを実行するためにインポートをグローバルにマップするには、SystemJS / WebPack / Rollupなどのようなものが必要なため、TypeScript自体によるemitはこれなしでは使用できないという他のコメントはまだ残っています。

私は実際の例を作ることができるかどうか見てみます、私はそれをかなり長い間していません、そして私はその時に持っていたソースコードにアクセスできませんが、私は100パーセント確信していますそれが可能だ。

2つ目のポイントとして、これはまさにSystemJSが行うことです。 これらのインポートをグローバルにマップし、グローバルが実際に要求されており、すでにロードされていることを理解します。 出力は間違いなく使用可能です

参考：SystemJS APIを使用してSystemJSでこれを機能させ、 https：//github.com/systemjs/systemjs/issues/1510にソリューションを追加しました。 ありがとう。

私の2番目のポイントについて：はい、それがまさにローダーができることだと私は知っています。 それが私のポイントです。インポートされたモジュールをグローバルにマップできますが、TypeScriptはマップできません。そのため、実行時にコードを有効にするにはローダーを使用する必要があります。 したがって、この元の問題のキャッチ22であり、グローバル（この場合はReact）がモジュールで使用可能であることを宣言できない場合は、モジュールであるかのようにインポートする必要があります（そうではありません）。 。

私の他のコメントは、コードを実行するためにインポートをグローバルにマップするためにSystemJS / WebPack / Rollupなどのようなものが必要なため、TypeScript自体によるemitはこれなしでは使用できないということです。

@billtiわかりません。 モジュールのグローバルバージョンを使用することが唯一のオプションであるが、TypeScriptではそれができないシナリオは何ですか？ ライブラリがグローバルとモジュールの両方として利用できるシナリオを見ただけです。

@DanielRosenwasser彼は、Reactがロードされる方法のために、グローバルオブジェクトのメンバーのように、実行時に実際にはグローバルであることを意味していると思います。

@billtiあなたがそれを

あなたの2番目のポイントについて：私はあなたが何を意味するのかわかります。

私の感じでは、ブラウザーのシナリオでは、RequireJSのようなローダーまたはWebpackのようなパッケージャーを使用する必要があるため、モジュールをサポートするブラウザーはまだないため、違いはありません。 （チャクラは旗の後ろでそれを利用できると聞きました）。 したがって、追加のツールがなければ、コードを実行する方法はまったくありません。 define 、 require 、またはSystem.registerを含む出力が、出力された_JavaScript_コードを移植できない可能性が高いことを意味します。 ただし、「モジュールとモジュールではない」の区別の重要性はわかります。

この回避策を使用して、少なくとも「モジュール」を1回だけ参照できます。

_shims.d.ts_

import __React from 'react';

declare global {
  const React: typeof __React;
}

そうすれば、インポートせずに他の場所で使用できます。
また、Reactがグローバルになったことを言っているので、少し厄介な場合でも、これは非常に明確です。これは、Reactをインポートする必要がなくなった理由でもあります。

あなたのshims.d.tsに関して、あなたがいくつかの投稿を上に行くならば、あなたはそれが今のところ私がしたことであることがわかるでしょう（偉大な心は同じように考えます）;-)

私はそれをいくつかの方法の1つで機能させることができますが、それは重要ではありません。 TypeScriptを簡単に採用できるようにし、ユーザーを絶望の落とし穴ではなく成功の落とし穴に陥らせようとしています。 そのことを念頭に置いて、TypeScriptを使おうとして問題が発生した場合、私はよく2つの質問をします。a）これは有効なコードですか。b）顧客はこれを試してみようとしていますか。

（TypeScript以外の）バージョンがBabelでやりたいことを、入力にかかる時間とほぼ同じ時間で実行していたことを考えると、コードは有効であると言っても過言ではありません。 ReactドキュメントのインストールページにCDNのスクリプトタグを

TypeScriptがコードを書く特定の有効なパターンをサポートしない場合は、それをすぐに明らかにして、人々を正しく導くようにする必要があります（これはエラーメッセージや簡潔なドキュメントで行うのが難しいことです）。 しかし、個人的には、TypeScriptがパターンをサポートするべきではないと思います。なぜなら、パターンが「ベストプラクティス」または「標準的」であるとは思わないからです。 コードが有効で、一部のJavaScript開発者がコードを記述したい場合は、TypeScriptでサポートを試みる必要があります。 TypeScriptを機能させるために、コードを変更し、ビルドパイプラインを再構成する必要があるほど（ここでは、些細なアプリを移行することをお勧めします）、開発者の移動は少なくなります。

解決策については...ここで唾を吐くだけですが、プロジェクト全体で使用できるAPIをすでに効果的に定義している「lib」コンパイラオプションも、ライブラリがグローバルに追加するために@types/name形式の値を取る可能性があります（そしておそらく相対パスもサポートします）。

TypeScriptを簡単に採用できるようにし、ユーザーを絶望の落とし穴ではなく成功の落とし穴に陥らせようとしています。

私たちは今、ユーザーを成功の落とし穴に導こうとして

1. モジュールによってインポートされていない場合にのみ表示される、拡張されたexport as namespace foo構造を作成します。
2. 何もせず、インポートを使用するように人々にプッシュし続けます-とにかくエラーメッセージを合理的に規範的にしたので、これは私の意見では多かれ少なかれ問題ありません。
3. 人々がどこからでもUMDを使用できるようにします-私は正直なところ、このアイデアについてはそれほど大きくありません。

@billti

あなたのshims.d.tsに関して、あなたがいくつかの投稿を上に行くならば、あなたはそれが今のところ私がしたことであることがわかるでしょう（偉大な心は同じように考えます）;-)

申し訳ありませんが、私はそれを逃しました、とても素敵です;）

TypeScriptがパターンをサポートするべきではないと思います。なぜなら、それらは「ベストプラクティス」または「標準的」であるとは思わないからです。

TypeScriptがここで規範的であるとは思わない、私はそれが主張することをしていると思う、私にエラーがあると私に告げる。 多くのライブラリには、グローバルとして自分自身をロードしてからESモジュール構文の使用に進むデモとチュートリアルがあります。 そうすることで彼らが最高の市民になったとは思いませんが、それはまた別の議論です。

とは言うものの、モジュールが主にグローバル上で_知覚される_構文糖衣構文として使用される場合、それらは構文糖衣構文ではないため、失敗はすぐそこにあります。 どちらかといえば、それらは構文上の塩（おそらく税金？）であり、真のコード分離、スクリプトタグの順序付けからの解放、明示的な依存関係の宣言、グローバル名前付け地獄からの脱出などの利点のために消費します。 モジュールの構文は人間工学的ではなく、せいぜい冗長ですが、モジュールのセマンティクスが価値のあるものになっています。

少なくとも.tsファイルでTypeScriptを使用している場合は、強力な静的コード分析のメリットを享受したいと考えています。 バベルは、Reactが存在するが、それについての知識がないと仮定して、これを行いません。 これは、ESモジュールが静的解析に適しているように意図的に指定されている場合でも当てはまります。

@DanielRosenwasser

モジュールによってインポートされない場合にのみ表示される名前空間foo構造として拡張エクスポートを作成します。

これを解決する最良の方法のように思えます。

これが問題を引き起こした別のケースは次のとおりです。

私が現在取り組んでいるプロジェクトでは、ローカルインクルード（主に歴史的な理由で）とnpmモジュールを組み合わせています。 最終的には、RollupまたはBrowserifyを使用してすべてが結合されるため、問題ありません。

コードベースにコピーしただけのemojioneプロジェクトの.jsファイルを使用します。 後で、その型宣言をDefinitelyTypedに追加しました。https ：

npmモジュールに移行しない理由は、npmモジュールにも数メガバイトのスプライトとPNGがバンドルされているためです。 その1つの200KiBスクリプトが必要です。 型宣言あり。

AngularJSの場合、回避策はdeclare var angular: ng.IAngularStatic 。 しかし、それは名前空間では機能しませんよね？

@dbrgn別の問題が発生しています。 モジュールが実際にグローバルである場合、タイプ定義は正しくありません。 グローバルを宣言することも、UMDスタイル宣言（これはUMDスタイル宣言に関するものです）でもありません。実際には、純粋なESモジュールのみを宣言します。

モジュールがグローバルを表す場合は、ファイルの最上位でエクスポートしないでください。これにより、モジュールがモジュールになります。

AngularJSでは、回避策はvarangular：ng.IAngularStaticを宣言することでした。 しかし、それは名前空間では機能しませんよね？

名前空間で機能します。

設計会議での議論の結果、UMDを常に許可し、現在の制限を適用するフラグを追加することを検討しました。 この制限は、UMDグローバルからタイプにアクセスする場合にも拡張されます。

これについてもっと考えてみても、新しい宣言の種類を作成する方がよいと思います。 このフラグは、宣言ファイルの作成者が1回だけ書き込む必要がある新しい構文よりも検出されにくくなっています。

これは、既存のコードとツールにどうしても必要です。 そのような時まで、Javascriptは高速で再生を停止し、モジュールシステムで負けるまで、存在するコードを柔軟に処理する必要があります。 警告を発しますが、ビルドを失敗させないでください。 私は、レガシーコードをロールアップとタイプスクリプトでうまく機能させることに対処することに何日も無駄にしてきました。

UGH。

Javaを笑うのが好きな人はたくさんいると思いますが、基本的なJavaモジュールは少なくとも機能します。 瓶は働く

14の異なるアドホックモジュール標準に適合させる必要はありません。または、その日のロールアップ/バンドルツールが実際に消費する形式のソースファイルからjsモジュールをコンパイルしてみて、モジュール形式を生成する必要もありません。これは、Typescriptのインポート/エクスポートステートメントとサードパーティのd.tsファイルでうまく機能するため、TSCは、「ダーンインポートを使用するだけで、グローバルなATになる」と言うのではなく、実際にコードをビルドすることを決定します。実行時間」。

shims.d.tsハックはうまく機能します。 しかし、うん。

Webpackを使用している人のための一時的な解決策https://github.com/Microsoft/TypeScript/issues/11108#issuecomment-285356313

目的のUMDグローバルを使用してexternalsをwebpack.config.js追加します。

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

これにより、既存のコードベースの移行が容易になるはずです。

jQueryがグローバルとして含まれているrequirejsで実装されたプロジェクトがあります。これは、グローバルとして見つかった場合にのみjQueryを拡張するプラグインがいくつかあるためです。

一部のモジュールのコードはそのプラグインに依存しており、jQueryがモジュールとしてインポートされた場合は使用できません。 これを機能させるには、モジュールとしてロードされたjQueryで動作するようにすべてのプラグインを変更し、モジュールとしてもロードする必要があります（必要な場所を推測します）。

その上、モジュールローダーなしでjavascriptを使用するページもあります。 したがって、プラグインはグローバルとモジュールの両方で機能する必要があります。

jQueryとは別に、ノックアウトなどの同じ問題を持つ他のスクリプトがあります。 これにより、プロジェクトの移行が簡単になります。 または、現実的な観点からは、実行不可能です。

もちろん、これは最良のパターンではなく、新しいプロジェクトでは使用しません。 しかし、この問題を抱えているのは私だけではないと思います

これにtsconfig.jsonでtypesを使用するのは理にかなっていますか？ たとえば、 types設定されていない場合、現在の暗黙的な動作が得られ、 types設定されている場合、文字通り「これらはグローバルです」と言っており、UMD名前空間をグローバルに表示させることができます。 それはとにかく今日存在する一種の振る舞いです（グローバルな力を除いて）。 これは、新しいglobalsオプションを導入することとは対照的です。

それはいい考えだと思います。 私の場合、UMDライブラリをグローバルとして使用するスクリプトと、モジュールとして使用するスクリプトがあります。 それぞれのケースに対処する2つの異なるtsconfig.jsonを使用して、この問題を解決できます。 本当にまっすぐです。

@blakeembrey typesすることは理にかなっていますが、すでに問題があるため、オーバーロードの概念にはあまり熱心ではありません。 たとえば、 <reference types="package" />構造には、 "paths"サポートしないという制限がすでにあります。 "package"は、 @types内のフォルダー名を

この会話の後、私は苦労しています。 これに関する更新または計画された解決策はありますか？ これは、lodashがアプリケーションにとって不可欠な部分である場合や、ウィンドウに依存するだけでなく、より多くのサードパーティライブラリがよりモジュール化された構造に変換される場合などのシナリオで役立つ可能性があるようです。

これに対処する、または少なくとも現在利用可能なリリースでこれをどのように解決する必要があるかを文書化するための計画された方法はありますか？

こんにちは@mochawichReactを外部として定義し、 declare global構文を使用しないと、次のエラーが発生します。

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

@cantuxTypeScriptはWebpack構成を読み取りません。 Reactをグローバルに利用できるようにした場合は、それをdeclareできますが、モジュールを使用しないのはなぜですか？

@aluanhaddadは、主にインポート呼び出しによって行われた作業と混同されたためです。 私はいくつかいじりました、次のステートメントは正しいですか？

モジュールをインポートする際に、少額のリクエスト料金を支払っています。 これにより、使用しているものがメモリ内で使用可能になります。以前に要求された場合、モジュールはキャッシュからロードされ、モジュールが存在しない場合はフェッチされます。 このリクエストを回避したい場合は、何かをグローバルとして定義するだけで、Typescriptはそれが利用可能であることを盲目的に信頼します（スマートバンドラーを使用する場合は、インポートステートメントを置き換えたり削除したりすることもできます）。

これらが正しければ、簡潔にするためにコメントを削除できます。スレッドはそのままでは巨大です。

@codymullinsが上記で尋ねたように、誰かがこの問題の現在の回避策を要約できますか？ lodashタイプの定義を更新したところ、TS2686エラーがたくさん発生しました。

私の現在の回避策は、typedefファイルをハックして古い動作標準に準拠させることでしたが、より多くのtypedefファイルが壊れ始めた場合、それは実行可能ではありません。

私のシナリオは次のとおりです。

• シングルページアプリでは、いくつかのライブラリ（lodashを含む）をインポートします。

上記のshimの例は機能しますが、vscodeはエラーとして強調表示しています（それでも正常に完了します！）

モジュールでUMDグローバルにアクセスするときにエラーを出さないでください。 私が取り組んでいる大規模なプロジェクトはAngularJSで行われ、アプリケーションにTypescriptを使用していますが、もちろん、 angular UMDグローバルタイプと@types/angular Angularタイプについて知るにはTypescriptが必要です。 あなたはそれが追加と同じように簡単になると思うだろう"angular"するtypesでtsconfig.json 、しかし、何らかの理由で、それはない、とTSCは私に叫びます。 すべてのNPMパッケージが純粋なTypescriptであるといいのですが、それらのほとんどはプレーンなJSであり、非常に長い間使用されます。 d.tsをインポートしたときに、UMDグローバルが存在すると言ってTSCがシャットダウンできない理由がよくわかりません。 この状況は一般的ではありません。これまでに取り組んだすべてのTypescriptプロジェクトでは、少なくとも1つのJSライブラリを使用しており、自分でバンドルして、型定義を使用して参照する必要があります。

これに関する更新はありますか？

私のユースケース：CDNを多用する既存の大規模なコードベースに取り組んでいます。 一般的なユーティリティは、スクリプトタグを介して多くのページ（clipboardjs、lodashなど）にインポートされます。 これらのグローバル変数はページで入手できるので、参照したいと思います。 モジュールを使用せずに、関連するソースファイルの先頭に/// <reference type="$name" />を使用して、typescriptをコンパイルするのは簡単です。 ただし、モジュールを作成しようとすると、これは機能しなくなります。

スレッドでは2つのアプローチが提案されているようです。

1. /// <reference type="$name" />インポートトークンを現在のファイルの名前空間にのみ入れます。

2. tsconfig.jsonのコンパイラオプション/構成変数（例： "globals" 、 "types" ）

どちらのアプローチも良いと思います。 @RyanCavanaughによるオプション1の批判には同意しますが：

逆に、そのファイルでのみ使用できる場合は、参照ディレクティブをコピーして貼り付ける必要があり、これは非常に面倒です。

現在の動作のために、UMDグローバルと一緒にモジュールを使用できないことははるかに厄介だと思います。 いくつかの回避策は、何もないよりはましです。

この問題はまだ未解決ですか？ もしそうなら、現在の回避策は何ですか？

@typesパッケージをインストールすると、モジュールとしてインポートされていないパッケージがグローバルとして利用できるようになります。

たとえば、プロジェクトのルートにnpm install -D @types/underscoreがある場合、アンダースコアから何もインポートしないモジュールを記述できますが、 _グローバルは使用可能になります（以下を参照）。

それはあなたが求めているものですか？

@billti誤解しているかもしれませんが、あなたの例は私には

再現に最低限必要なもの：

js / foo.ts：

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

import { Bar } from "./bar";

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

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

js / bar.ts

const Bar = {
    x: 3
};

export { Bar };

package.json：

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

tsconfig.json

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

エラーメッセージ：

js / foo.ts（7,3）：エラーTS2686： 'Cookies'はUMDグローバルを参照していますが、現在のファイルはモジュールです。 代わりにインポートを追加することを検討してください。
js / foo.ts（10,15）：エラーTS2686： 'Cookies'はUMDグローバルを参照していますが、現在のファイルはモジュールです。 代わりにインポートを追加することを検討してください。
js / foo.ts（15,14）：エラーTS2686： 'Cookies'はUMDグローバルを参照していますが、現在のファイルはモジュールです。 代わりにインポートを追加することを検討してください。

取得する動作は、インポートされたモジュールが「適切な」UMDモジュール（これは「Cookie」を使用した動作）として作成されたか、「同時に双方向で機能する」モジュール（lodashの作成方法）として作成されたかによって異なります。 。

オブジェクトが実行時にどのように機能するかを説明する.d.tsファイルを正しく書き込む人々の不一致、および開発者のエクスペリエンスの不透明さは、私が「UMDグローバル制限の削除」の方向にかなり傾いている理由です。 --noStrictUMDオプトアウトすると、 --strict下に置くことができます。

私が遭遇したもう1つのことは、MonacoのカスタムAMDローダーを扱っていたことです。 これらのモジュールはに正しくロードに失敗し、 '必要のグローバルとを参照する傾向があるので、彼らはそれはそれで正しいUMDモジュールを使用するのはとても難しいので、「必要」グローバルに（巨大eyeroll INSERT）AMD行動のいくつかのサブセットをサポートしますが、ストンプモナコモジュールローダー。 最終的にUMDJSライブラリをMonacoローダーのスクリプトタグの上に配置すると、モジュール（Monaco APIをインポートする必要があります）からグローバルにアクセスしているため、TSが文句を言います。

@RyanCavanaugh

私が遭遇したもう1つのことは、MonacoのカスタムAMDローダーを扱っていたことです。 それらはAMDの動作のサブセットをサポートします（巨大なアイロールを挿入します）が、グローバルな「require」を踏みにじるので、適切なUMDモジュールを使用するのは非常に困難です。これらのモジュールは「require」をグローバルに認識し、適切にロードできないためです。モナコモジュールローダー。

😁

彼らがそれを修正する可能性はありますか？

私は最近、モジュールの複雑さのコストについて多くのことを考えてきました。 非常に多くの相互依存し、部分的に互換性のあるローダー、バンドラー、トランスパイラー、パッケージマネージャー、およびフレームワークは、真に重要な量の認定の複雑さになります。 （私はあなたが何もリマインダーを必要としないと確信しています🙉）。

開発者として、5〜6年前よりも桁違いに複雑なツールチェーンを受け入れました。複雑さの主な原因はモジュールです。

これらのUMDパッケージをあきらめてグローバルとしてロードし始めた場合、それは何のためにあるのでしょうか。

それでも...人々はまさにそれをやっています。 これはひどいです！

つまり、このStack Overflow Answerには61👍があり、過去半年間のパッケージの99％ですべての間違ったことを示唆しています。 （著者は、今朝提供されたフィードバックのために、モジュールをUMD依存関係の_オプション_として言及するように親切に更新しました）

これは、これらすべてが順調に進んでいて、グローバルに戻ることを許すことはできません！

それでも...人々はまさにそれをやっています。 これはひどいです！

問題は、JSモジュールの構想と実装がひどく不十分であるため、グローバルの使用に戻る方がはるかに優れており、簡単であるということです。 モジュールが最初から適切に設計および実装されていた場合...

モジュールとUMDグローバルを組み合わせるのは、さまざまなローダーとの互換性のレベルが異なるモジュールとして依存関係をロードするのが面倒であり、直接の依存関係のバンドルをサポートしていない一部のローダーを使用する必要があるためです。代わりに、実行する分。

この「機能」は、実際にはUMDモジュールを使用しているにもかかわらず、公式のUMDモジュールサポートを使用していないことを意味します。 .d.tsファイルからグローバルとしてエクスポートし、すべてを再エクスポートするその名前の独自のモジュールを手動で作成します。

これに関する更新はありますか？ 私は本当にオプション2を機能させたいです：

「このUMDグローバルは実際にはグローバルに利用可能です」と言う構文または構成を許可します

また、昔ながらのスタイルのjsライブラリがたくさん出ているのも助けにはなりません
そこで、それらすべてを書き直すことは問題外です。 しっかりしたものを作るだけ
Rollupがそれらをすべて正しく処理するように設定すると、何時間も無駄になります。

人々は「エンタープライズJava」を笑いますが、プレーンJavaには実行可能なものが付属しています
1.0のモジュールシステム。 完璧ではありませんでしたが、完全な混乱ではありませんでした。

「UMDスタイルのグローバルを許可する」というのは間違いなくオプションです。

2018年4月2日月曜日午前1時40分KagamiSascha Rosylight <
[email protected]>書き込み：

私は次の問題を回避する必要がありました：

/ *モジュール：es2015 * /
// js-yamlはUMDをサポートしますが、ES2015モジュールはサポートしません！import * as _jsyaml from "js-yaml"; declare var jsyaml：typeof _jsyaml; jsyaml.safeLoad（ ""）;

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/Microsoft/TypeScript/issues/10178#issuecomment-377885832 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AA50ljAD33sr09EGFVAsURbu1x75X-lOks5tkeQCgaJpZM4Jd8jX
。

>>

ダニエルジョイス

勇敢な者は星の中にいるので、柔和な者は地球を受け継ぐでしょう。

Angularプロジェクトでthree.jsを使用しています。 としてインポートします

import * as THREE from "three";

import {Vector3} from "three";も期待どおりに機能します。

threeおよび@types/three npmパッケージがインストールされていると、すべてが正常に機能します。 内部的には、これはthree/build/three.module.jsを使用していると思います。 @types/three/index.d.tsファイルは、表記export as namespace THREE使用します。これは、私が完全に満足しているわけではありませんが、機能します。

この特定のケースでは、問題はOrbitControls.jsと呼ばれるthree.jsシステムに別の関連ファイルがあることです（これにより、基本的に指またはマウスで3D画像を回転させることができます）。 問題は、この関数が半公式にthree.jsディストリビューションの一部であるにもかかわらず、 examplesツリーにあるプレーンな古いJSファイルであり、 THREEプロパティに直接配置されることです。ウィンドウの、そしてwindow.THREE存在すると予想される他のAPIを直接使用します。 したがって、ファイルを「必要」としても

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

自分自身を配置したり、使用する3つのシステムの他の部分にアクセスしたりするためのwindow.THREEが見つかりません。 Angular scriptsプロパティを使用してライブラリ全体をangular.json （昔ながらの<script>タグとほぼ同等）に直接含めることができますが、間違いがなければ私はライブラリを2回ロードします。

それを避けるために、私はimport * as THREE from "three";ステートメントを削除しました、そしてねえ、それはまだfoo: THREE.Vector3ようなタイプを解決できますが、悪名高いnew THREE.Vector3()ような参照で窒息します

「THREE」はUMDグローバルを指しますが、現在のファイルはモジュールです。 代わりにインポートを追加することを検討してください。 [2686]

この時点で、 OrbitControls.jsファイルを取得して、ES6-ifyまたはTS-ify、あるいはその両方を実行する必要があると考えています。これは、他の1人以上がすでに行っているようです。 `orbit-controls-es6のような形なので、他の人の手に自分の人生をそのように置くのは嫌いですが、私は自分の人生を単純化してそれを使うべきかもしれません。

半無関係なことに、1つの奇妙な点は、コード自体がthreeモジュール自体にない場合でも、 @types/threeがOrbitControls型を定義することです。 ただし、 OrbitControlsというクラスを定義するすべての型を何かに関連付ける方法がわかりません。上記のorbit-controls-es6のデフォルトのエクスポートを宣言したいと思います。このタイプですが、その方法は私にはわかりません。

私が最終的に思いついた解決策は、私が深く恥ずかしいことですが、次のとおりです。

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

理由は少し混乱していますが、機能します。 必要なファイルには次のような行があります

THREE.OrbitControls = funtion() { };

import * as THREE from "three";ステートメントの結果として3つの「名前空間」に割り当てられるように見えますが、これは機能しないはずです。

@RyanCavanaughから、フィードバックを＃26223からコピーするように求められました。

私はかなり大きなTypeScriptコードベース（Googleの内部monorepo）を維持しており、人々が依存している明確に型指定されたライブラリがいくつかあります。 元々、ユーザーは、 .d.tsが外部モジュールに変換される前は、 angularなどのライブラリのグローバルタイプに依存していました。 次に、モジュールと明示的なインポートを使用するようにコードベースを移行しました。 実際、 export as namespace d UMDグローバルでは、型と値の両方の参照にシンボルを使用するために明示的なインポートが常に必要であり、移行したときに気付くことさえありませんでした（おっと）。

インポートされていないコードの使用を許可することは、一般的に私たちにとって問題があります。

• これは、コードがグローバルな「バックグラウンド」タイプ定義に依存しているため、コードが読みにくくなることを意味します（特に、レポブラウザーまたはシンボルに移動しないコードレビューで）。

• コードの依存関係を覆い隠します

• これは、bazelで実装する「すべてのインポートに対して明示的なビルドレベルの依存関係が必要」という制約を回避します。別名「strictdeps」です。

  大規模なコードベースでは、コードに明示的な依存関係が必要です。そうしないと、リポジトリが管理できなくなります。 A -> B -> Cとグローバル型を追跡する依存関係がある場合、 BがC依存しているという理由だけで、コードAコンパイルするのは簡単です。 B後でその依存関係を削除すると、 A壊れます。つまり、変更によってリポジトリに予期しない波及効果が生じ、コードの分離に違反します。

• これにより、コードは値に1つのプレフィックスを持つモジュールを一貫性なくインポートし、そのタイプを別のプレフィックスで使用します（特に、AngularJS、ngとangularの場合）

ベンダーが作成したDefinitelyTypedのコピーにあるexport as namespaceステートメントを削除することでこれを回避できますが、少なくとも私たちにとって、この機能はコードの保守性とエンジニアリングの目標に反するものです。 問題はグーグルのようなモノレポの状況でより顕著であると思いますが、一般的に小さなコードベースにも当てはまります。

あなたが投稿したポイントは、私たちの状況にはまったく重要ではありません。 私たちは、AMDモジュールを使用して独自のコードを実装し、UMDモジュールを使用して依存関係を提供することを余儀なくされています（ただし、JSモジュールは、概念と実装の両方でひどく欠陥があると要約します）。 この機能により、私たちの生活を大幅に簡素化することができます。

おそらくTS3を使用すれば、これを回避する方法を見つけることができますが、それを回避したとしても、必要な変更がすべて完了するまでには少なくとも2年かかるため、これは私たちにとって非常に便利な機能です。

未解決の質問：「すべてのUMDモジュールへのアクセスを許可する」のグローバルフラグは1つで十分ですか、それともモジュールごとにエラーを制御する必要がありますか？

「たった1つの旗」に❤️に投票してください
「モジュールごとの制御が必要」に投票🎉

また、 tsconfig.jsonの"types"オプションに明示的なリストが存在するため、モジュールでのUMDの使用も許可されないかどうかも検討していました。 タイプが意図的に存在することを意味します。 （明らかに、インポートを忘れたというエラーを排除するものではありません）。

または同様に、 /// <reference types="..." />構造を使用すると、そのパッケージが使用されているモジュールでそのパッケージをUMDで使用できるようになります（つまり、「モジュールごとの制御」について説明します）。

@ RyanCavanaugh ＃26233に対処するためのフラグもありますか？

26233は、意図したとおりに完全に機能していると見なされます。 モジュールからUMDグローバルのタイプ側にアクセスすることは合法的に無害です

それが「合法的に無害」であるかどうかはよくわかりません。 例として@types/jqueryを使用します。 $とjQueryはJQueryStaticインターフェースにマップされ、定数としてエクスポートされます。 その結果、すべてのモジュールがインポートなしで$とjQueryアクセスできます。 それを無効にできるといいのですが。

@RyanCavanaughはい、TSの放出が影響を受けないという意味で無害です。 各ライブラリがアクセスできる@typesきめ細かく制御したい場合は問題があります。これにより、少なくともモジュールスコープの型のように見えるものがグローバル型に変わります。 エミットが影響を受けていなくても、アクセスの拡大も問題になる可能性があります。

実際、jQueryの場合、emitが影響を受けます。 $()は、インポートなしのモジュールで発行されます。

すべてのモジュールからUMDグローバルへのアクセスを許可する新しいフラグのPRを受け入れます。

実装に関しては、それは非常に簡単です...しかし、名前を付ける必要があります。 私たちは提案レビュー会議で12のひどい名前を蹴り、それらすべてを嫌っていたので、おいしいものを思い付くのはあなた次第です。 半分にしてください。

私たちは提案レビュー会議で十数のひどい名前を蹴り、それらすべてを嫌いました

あれは何だった？

ですから、おいしいものを思いつくのはあなた次第です。

多分umdUseGlobalか何か。

UMDグローバルは通常export as namespaceため、UMDグローバルフラグの名前にはimportAllNamespacesをお勧めします。

@RyanCavanaughチームはタイプの問題について話し合いましたか？

@FranklinWhaleはい。

@saschanazすでにこれを尋ねましたが、私も興味があります... @RyanCavanaughどんなひどい名前が議論されたか覚えていますか？

チェーンはこんな感じだったと思います

• allowUmdGlobalAccessFromModules -最も正確ですが、すっごく長いです
• assumeGlobalUmd -うーん
• allowModuleUmdGlobals -「グローバル」??
• umdAlwaysGlobal -🤢
• allowUmdGlobals -しかし、私はすでにできますか？
• allowUmdGlobalAccess -モジュール部分をスキップしますが、おそらく誰も気にしませんか？

強制された場合は最後のものを選択します

ありがとうございました！

私はallowUmdGlobalAccessFromModulesが一番好きです。なぜなら、それは長いですが、その精度が覚えやすいからです。 「モジュールからUMDグローバルにアクセスできるようにするオプションは何ですか？もちろん、 allowUmdGlobalAccessFromModulesです！」と思います。

接頭辞「allow」を使用すると、他のオプションの命名規則と一致します。これは良いことです。

さらに...ほぼ同じくらい長い他のオプションがあります:)

allowUmdGlobalAccessFromModules ：31文字

allowSyntheticDefaultImports ：28文字
strictPropertyInitialization ：28文字
suppressExcessPropertyErrors ：28文字
suppressImplicitAnyIndexErrors ：30文字
forceConsistentCasingInFileNames ：32文字

現在の回避策は何ですか？ 私は過去1時間グーグルをしていて、実行可能な解決策を見つけることができません。
'any'にキャストしたり、動作するTypescriptバージョンにダウングレードしたりしたくありませんが、他のオプションが見つかりません。
この問題を修正するコンパイラフラグがある実験的なビルドはどこかにありますか？
（ちなみに、「allowUmdGlobalAccessFromModules」は優れた名前です。1日に50回入力するわけではありません:-)）

一番上のHTMLファイルに静的に含まれているlodashを使用してtsc3.2.2を使用しています。 require.jsで; 最新のDefinitelyTypedから取得したd.ts。 コンパイルに失敗するサンプルコード：

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

class Example<T extends IThingWithTitle<T>> {

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

}

export = Example;

（プロジェクトを逆さまにする必要があると言わないでください。いくつかの面で遅れを取っていることはわかっています）

更新：（（window）._）/ * FIXME https://github.com/Microsoft/TypeScript/issues/10178 */。sortBy（...）は機能しますが、親愛なる主よ、それは醜いです:-P

@Gilead 、このコメントの解決策は今のところ問題なく機能します： https ：

これについて何か進展はありますか？ この問題が発生しているため、上記の回避策が機能しないように見える場合があります（ [email protected] ）。

最初に私はこれを試しました：

import 'firebase';

declare global {
  const firebase;
}

これにより、グローバルfirebaseにタイプany暗黙的に与えられ、名前空間（同じ名前）がそれに適用されます。 最初は、 firebaseすべてのトップレベルキーに適切なツールチップ/インテリセンスが表示されるため、これは機能しているように見えました。

ただし、実際には機能しません（その後、タイプanyとして使用するように切り替わるため、バグの可能性がありますか？）：

だから私はここで述べた回避策を試しましたが成功しませんでした（他の人にはうまくいきます）：

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

declare global {
  const firebase: typeof _firebase;
}

=> 'firebase'は、独自のタイプアノテーションで直接または間接的に参照されます。
（名前空間がエイリアスされている場合でも？）

私も試しました

import * as _firebase from 'firebase';

declare global {
  const firebase: typeof _firebase;
}

=>インポートエイリアス「_firebase」の循環定義。
（おそらくその定義のexport = firebase; export as namespace firebase;ためですか？）

そして最後に、 import 'firebase'実行するだけで、

「firebase」はUMDグローバルを指しますが、現在のファイルはモジュールです。 [2686]

誰かがこれに対する解決策を持っているなら、それは非常にありがたいです。 それ以外の場合、これまでに言及したこれを解決するための提案は、私には本当に問題ないようです（フラグ、トリプルスラッシュ参照、tsconfigのtypes 、 globalまたはexternalオブジェクトを持つ） tsconfig内）。

@aluanhaddadのコメントについて

これは、これらすべてが順調に進んでいて、グローバルに戻ることを許すことはできません！

私はグローバルに戻ろうとはしていません。いくつかの利点をもたらすため、他のすべてにモジュールを使用しながら、アプリバンドルとは別にいくつかの重い依存関係をロードしようとしています：依存関係を適切にキャッシュできます私のアプリバンドルほど頻繁には更新されないためです。 バンドルサイズが爆発しません（バンドラーに同じ依存関係が複数回含まれているため、コードを分割することがあります）。つまり、アプリユーザーのダウンロードが少なくなります。 開発中にバンドルを再構築する方がはるかに高速です。

これは実際に追加することは非常に簡単な機能です。 コミュニティのメンバーがそれを取り上げるのは素晴らしいことです。

@RyanCavanaugh私はそれに見て、種類の私はオプションを追加する必要があります考え出しcompiler/types.tsとでUMDグローバルチェックを変更するcompiler/checker.ts 、と私は私はそれを追加する必要があると思うcompiler/commandLineParser.tsも...しかし、ソースにまったく精通していないため、完了するまでにかなりの時間がかかると思います（i18nを壊さずにCLIフラグの説明を追加する方法など） 。 今のところ、私はすでにソースを知っている誰かがそれを引き受けるのを待つつもりです。

@simonhaenischモジュール以外の宣言ファイルで宣言できます。循環参照を避けるために、別のUMDモジュール宣言で再エクスポートできます。 元のfirebaseは名前空間として宣言されていますが、幸運なことに、エラーを発生させることなく、宣言を補強します。

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

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

残念ながら、宣言したのは名前空間ではなく値であるため、 let x: firebase.SomeInterfaceようなことはできません。名前空間のエイリアスを作成する唯一の方法は、インポートを宣言することですが、 declare import firebase = UMD.firebase;はできません。

前のコメントと同様に、hls.js（UMD）と参照型を遅延読み込みしています。

hls.d.ts ：

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

遅延ロードされたUMDモジュールを使用する.tsファイル：

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

Typescript> = 3.0.1および3.4​​.1でテスト済み。

理論的根拠は、動的モジュールインポートに対する不完全なブラウザサポートです。

@MatthiasHild /// <reference path="hls.d.ts" />コメントなしで実行できますか？

編集、はい、できます。宣言が、このSOの質問に基づいて、別の.tsファイルと同じ名前を持たない含まれている.d.tsファイル内にある限り、可能です（それが私を惹きつけたものです）そしてなぜ私が尋ねたのか）。