[上記の問題の説明のpackage.jsonのtypescript.mainに移動しました]

：+1：
http://nodejs.org/api/modules.html#modules_folders_as_modulesはNode.jsの非常に人気のあるルールだと思います。

他の例。

./test/index.ts

export function hello() { return "Hello, world"; }

./main.ts

import test = require("./test/");
console.log(test.hello()); // print "Hello, world"

[上記の問題の説明のpackage.jsonのtypescript.definitionに移動しました]

1つの解決策は、より優れたツールでそれを解決することです。 たとえばimport foo = require('foo')は、ローカルのnode_module + package.json（fooはtsプロジェクト）またはDT定義（fooはライブラリ作成者がts defを維持したくないjsプロジェクト）を探すためのヒントを提供します。 。

ご参考までに; 私は実際にTSDでこれに似たものをテストしています。 npm（またはbower）パッケージにバンドルされている定義を公開およびリンクする方法。

これは0.6の開発バージョンにあり、 typescript要素をpackage.json（またはbower.json）に追加し、サブ要素definition （おそらく1つであるためサブ要素）を追加することで機能します日はsourceもあるでしょう、または何でも）。

{
    ...
    "main": "./index.js",
    "typescript": {
        "definition": "./foo.d.ts"
    }
    ...
},

次に、TSD（現在tsd link ）でコマンドを実行すると、node_modules（またはbowerなど）内のすべてのpackage.jsonファイルがスキャンされ、定義されている場合はそのプロパティが検索され、中央のtsd.d.tsに参照が追加されます。プロジェクトの

例：ここで定義し、ここで使用する

@Bartvdsそれはかなりいいです。 npmパッケージに.d.tsを含めるための最初のステップになる可能性があります。 「typescript」に「definition」が含まれるpackage.json構造が気に入っています。これは、はるかに整理されています。

TypeScriptコンパイラ自体がそれを自動的に読み取ることができれば、非常にクールです。

議論のためにこれにタグを付ける-よりスマートな外部モジュールの解決は、ここでのさまざまなシナリオを理解するために話し合う必要があるものです。 これは以前に提起されたものであり、1.0でいくつかの調整を行いました。

＃207についても話し合います-「インデックス」の下を見てください

：+1：

@chanon tsMainは、宣言の生成を使用する場合は必要ありません。

はい、この問題はブラウザにとっても非常に重要です-多くのプロジェクトはbrowserify / packifyを使用しているため、ノード互換のディレクトリレイアウトを使用しています

：+1：

codeplexリポジトリでは、この領域ですでにいくつかの作業が行われています。1つはleebyronによるプルリクエストで、もう1つはkayahrによるものです。

そのうちの1つを新しいリポジトリに移植しようと思っていましたが、関連するコードが大幅に再配置されたようです。

これをTypeScriptコンパイラに追加する方法の提案を書きました。 これには、 typingsディレクトリを調べることも含まれます。これは、独自のタイプスクリプト定義を維持しないjavascriptモジュールを操作するときに重要になるためです。 残念ながら、これをすべてtsdで透過的に機能させるには、 /// <reference dファイルがアンビエント外部宣言であるという要件により、少し面倒な作業が必要になります。 これをブランチに実装し、それを使用するいくつかのサンプルモジュールを提供する方法を見ていきます。

賢明に見えます。 これは、タイプの依存関係が衝突するモジュールをカバーしますか？ つまり、アプリがAとBをインポートし、BもAに依存している場合です。外部宣言のコピーが2つあると、重複型エラーに陥りやすくなります。

そうではなく、異なる外部モジュール名に解決される必要があるため、異なるモジュールで同じ名前の独立した型を宣言します。 構造タイプのチェックにより、さまざまなモジュールが問題なく相互作用できるようになります。

これは、これが解決しようとしている現在のtsd定義の主要な問題の1つです。外部アンビエントモジュールを定義することにより、同じ名前でわずかに異なるタイプのライブラリの複数のバージョンを持つことを処理する方法がありません。 。

@joewoodまた、Aの異なるバージョン間で問題が発生します

├── [email protected]
└── [email protected]
    └── [email protected]

同じ名前であるが、タイプがわずかに異なるライブラリの複数のバージョンを持つことを処理する方法はありません。

同じ解決策を聞くことに興味があります。 TypeScriptには、アンビエント宣言用のglobalレベルの変数スコープがあります

バージョンが一致していても、現時点では、2つの異なるが一致するアンビエント宣言ファイルに問題があり、シンボルの重複エラーが発生しています。 ローカルで定義され/// referenceディレクティブは、何らかの方法で単一のファイルに解決する必要があります。 それか、タイプIDにパスを含める必要があり、構造型によってバージョンの不一致などが処理されます。

@joewoodうん、それは、可能な限り/// referenceを避けて、正しい定義をロードするためにrequireを変更することによって、ほとんどの場合に修正されることを願っています。 外部モジュールは、アンビエント宣言ではなく絶対パスによって識別されるため、異なるパスから異なるバージョンで同じ名前の複数をロードできるはずです。

はい、それは、可能な限り///参照を避けて、正しい定義をロードするためにrequireを変更することによって、ほとんどの場合に修正されることを願っています。

：+1：

：+1： @ Nemo157と議論してくれたみんなに感謝します。

最上位のテキストを更新して、package.jsonの追加をマージし、 @ Nemo157の提案にリンクしました。

：+1：

モジュールを作成するためのさまざまな方法がすべて機能することを示すために、モジュールのサンプルセットを作成するとともに、提案の最初の実装を行いました。 異なるサブモジュールで同じライブラリの異なるバージョンを使用することを含みます。

：+1：

index.ts：+1：を持つモジュールとしてのフォルダー

：+1：

：+1：

：+1：

：+1：

：+1 ：： + 1 ：： + 1：

：+1 ：： + 1 ：： + 1 ：： + 1：

これを私たちのレーダーに戻すためにコメントします。

私は@Bartvdsの提案で良い成功を収めました：

次に、TSD（現在はtsdリンク）でコマンドを実行すると、node_modules（またはbowerなど）内のすべてのpackage.jsonファイルがスキャンされ、定義されている場合はそのプロパティが検索され、中央のtsd.d.tsバンドルに参照が追加されます。あなたのプロジェクトで。

したがって、 package.jsonでtypescriptをサポートすることを検討してください。これは、コミュニティが行ってきた方法です。

TypeScriptがnode.jsコミュニティで広く使用される場合は、tscがnode_modulesフォルダーを認識する必要があります。 私は現在、開発プロジェクトの一部であるモジュールへのシンボリックリンクを使用しています（npm-workspaceを使用）。現在、2つのオプションがあります。

• node_modulesから直接インポートします。これは間違っているようです： import Foo = require("node_modules/mymodule/Foo");
• tscを取得して宣言ファイルを生成し、文字列モジュール名を切り替える手動で保守されているモジュール宣言ファイルを使用してそれらをつなぎ合わせます

tscはインポート宣言で外部モジュール名をチェックし、パス解決中にnode.jsランタイムが行うのと同じ方法でnode_modulesも適用できますか？ コンパイラオプションでこれをオンまたはオフにすることもできます。

：+1 ：： + 1 ：： + 1：

tscはインポート宣言で外部モジュール名をチェックし、パス解決中にnode.jsランタイムが行うのと同じ方法でnode_modulesも適用できますか？

これが「あるべき」方法です。 ディレクトリツリーを検索して上記の名前のファイルを見つける現在の方法は、JS実行コンテキストとはまったく似ていません。

これはしばらくの間私のリストに載っています。 次のリリースでこれを取得しようとします。

私たち（ Booktrack ）はすべてのWeb開発にTypeScriptを使用しており、node.js開発者と同様の課題に直面しています。 Web開発者の声は、ノード開発者の声ほど大きくないように思われるので、私は声を上げます。

ソリューション（私たちにとって最悪の順に）：

1. node_modulesへのハードコードされたルックアップによるトップレベルの外部モジュール名の解決
2. トップレベルの外部モジュール名の解像度を制御できません
3. node_modulesディレクトリへのトップレベルの外部モジュール名のオプションの解決を制御するコンパイラフラグ
4. 指定されたパスへのトップレベルの外部モジュール名のオプションの解決を制御するコンパイラの「モジュール検索パス」パラメータ
5. すべての（トップレベルだけでなく）外部モジュール名を解決するJSプラグインをコンパイラに提供するコンパイラの「モジュールリゾルバ」パラメータ
6. 外部モジュールの名前解決を制御できるように、言語サービスへの適切なフック

オプション1はひどいです、私はむしろオプション2を望みます。

オプション5および6では、requirejsまたはwebpackプラグインを操作するときに見られるような、インポートステートメントのエキゾチックな使用が可能になります。 基本的な考え方：コンパイラは、すべての外部モジュール名のルックアップ（トップレベルだけでなく）をサードパーティ（プラグインまたはコールバック）に委任します。 デリゲートは、コンパイル中のモジュールへのパスと外部モジュール名を指定すると、ファイルシステムパスまたは指定されたモジュール名のタイプ情報をコンパイラに返します。

オプション4が実装されていれば幸いです。オプション6が実装されていれば嬉しく思います。また、オプション4とオプション6の両方が実装されていれば月を超えています。

モジュール検索ルートの--basePathはどうですか。すべてのモジュールのインポートは、そのパスを基準にして検索されます。 これはAMDにのみ適用されます。

ノードの問題ははるかに単純だと思います。それを強制する必要があります:)

ずっと前に@ Nemo157から実装（およびテスト）を実際に取得したことに注意してくださいhttps://github.com/Microsoft/TypeScript/issues/247#issuecomment -57422329

@ mark-buerと@mhegazyに同意します。オプション4は、検索パスを簡単に修正する必要があります。 言語サービス（オプション6）のより精巧なソリューションは、長期的には間違いなく必要です。

_追加する価値があります_：これだけでは、一般的な型参照＃1125の重複シンボルの問題のため、npmでのTypeScriptの再利用の問題は修正されません。 ///は本当に避ける必要があります.tsconfigファイルを使用し、＃17で提案されているように、パッケージを単一の外部型付きモジュールにバンドルすることで、これを適切に修正します。

typescriptコンパイラによってnode_modulesフォルダを認識させるための別の投票。

CommonJSモジュールの場合、typescriptは、require.resolveと同じファイル名解像度に従うのが理想的です（このページの疑似コードで概説されています：http：//nodejs.org/api/modules.html#modules_all_together 。

この機能は、typescriptコンパイラをbrowserifyなどの他のノードパッケージャに統合できるようにするために重要です。 @ Nemo157のパッチはうまく機能しますが、ほとんどがtypescriptの新しいバージョンに移行し、彼のコードと互換性がなくなったため、既存のパッケージャーで簡単にテストすることはできません。

node_modulesディレクトリはソースに対してどこにある必要がありますか？

Atom-TypeScriptは、すぐに使用できるtypescript.definitionをサポートするようになりました。 詳細： https ：//github.com/Microsoft/TypeScript/issues/2829

このようなパッケージは、atom-typescript：roseを使用して簡単に作成することもできます。＃2829を参照してください。

制限

外部ライブラリに依存しないパッケージを共有する場合は、_完璧に_機能します。 もしそうなら、モジュールの競合解決アルゴリズムが必要です。

私はこのケースの提案を受け入れていますが、私の計画は次のとおりです。

• TypeScriptに外部のreferenceコメントを与えないようなd.tsを読む際に、いくつかの賢いことをします（例：node.d.ts here https://github.com/TypeStrong/atom-typescript-examples / blob / master / node / node_modules / example-typescript-b / defined / sample-bdts）代わりに、タイピングに.d.tsがある場合は、それをポイントします。

これは2.0に向けて順調に進むのでしょうか？ これは、Node.jsを採用するための重要な機能のように思えます。これは、DefinitelyTypedなどを使用した場合でも、今のところ苦痛です。

これは、Node.jsを採用するための重要な機能のように思えます。これは、DefinitelyTypedなどを使用した場合でも、今のところ苦痛です。

@LPGhatguyhttps ：//github.com/Microsoft/TypeScript/issues/2338を参照してください。 @vladimaはそれに取り組んでいますが、まだマイルストーンが割り当てられているとは思わない：rose：

@LPGhatguyは、次のリリースでこれを取得しようとしています。 うまくいけばすぐに。

@mhegazy 1.6という意味ですか？ それは素晴らしいでしょう！

それは＃2338と関係がありますか？

TypeScript 1.6の場合は「はい」（少なくともこれが私たちがやろうとしていることです）、＃2338の場合は「はい」。 ＃3147と＃4154を含む、これに関する他のいくつかの変更と問題があります

それでは、なぜそれがマイルストーンとしてTypeScript 2.0としてタグ付けされたのですか？

@heycalmdownに感謝し、マイルストーンを削除しました。 通常、マイルストーンを提案にタグ付けすることはありません。 うまくいけば、この問題について1週間かそこら以内に更新があります。 乞うご期待。

ES6モジュールのサポートにもこれに従うようにお願いしたいと思います（私はそうなると思いますか？）

の入力

import mylib = require('mylib');
mylib.foo(mylib.bar);

と同じように動作する必要があります

import { foo, bar } from 'mylib';
foo(bar);

ES6モジュールのサポートにもこれに従うようにお願いしたいと思います（私はそうなると思いますか？

@DavidSoutherそれは_自動的に_そうなるでしょう。 2つの間のルックアップは一貫しています：rose：

これは＃4154によって処理されます。

毎晩使用している場合、明日から、ノードモジュールのインポートが「正常に機能する」ことを期待する必要がありますか？

質問：
私は、ファイルに名前を付けるのが一般的な慣習だと思います
commonJSの「インデックス」と
AMDの「メイン」
短いパスの場合。
上の質問では、作者はインポートします
/node_modules/concator/index.ts as
import concator = require('concator');

許してください-現在、インデックス解像度もサポートされているかどうかを調べています。AMDのindex.tsまたはmain.tsには `解像度が必要ですか？
また、 @ basaratにpingを送信して、 https：//github.com/TypeStrong/atom-typescriptでサポートされているかどうかを確認しています。これは、上記のようにindex.tsを要求できないためです。

@sebilasse 、今日typescript@nextを使用している場合、これは--module commonjsで機能するはずです

import concator = require('concator'); // resolves to node_modules/concator/index.ts

以前のリリースからAMDの解像度に変更はありません。

@DavidSouther今日はtypescript@nextにあるはずです。 試してみて、運賃を教えてください。

@mhegazy @basarat ：+1：わかりました。 しかし、main.tsまたはindex.tsのAMD解像度についてどう思いますか？将来的には一貫性があるべきではありませんか？

@ sebilasse 、AMDの場合、＃2338の@vladimaで指摘されているように何かを行う必要があると思います（セクション：RequireJS / ES6モジュールローダー）。

非常に素晴らしい！！ \ o /

@mhegazyまだ期待どおりに機能していません。

https://github.com/DavidSouther/typescript-example-using-nodeを「理想的な」ユースケースと一緒にまとめました。 tslibは、単一の関数をエクスポートする単純なライブラリです。 tsclientは、tslibと、Nodeパッケージのreadlineに依存しています。 セットアップスクリプトは、インストール、リンク、および実行に便利です。 実行を含め、予期しない部分にインラインコメントで注釈を付けました。

% ./setup
...
> [email protected] build ~/ts-node/tslib
> tsc --version ; tsc -p src/

message TS6029: Version 1.7.0-dev.20150831
...
> [email protected] build /Users/southerd/devel/tmp/ts-node/tsclient
> tsc --version ; tsc -p src/

message TS6029: Version 1.7.0-dev.20150831
# Expect this to find tslib, but fail type checking.
# See tsclient/app.ts for details
src/app.ts(4,21): error TS2307: Cannot find module 'tslib'.

+ node ./dist/app.js # This works as expected!
What would you ask? What is the meaning of life?
42
+ set +x

また、tsclient（VSCodeバージョン0.7.0（0.7.0））でのtslibインポートの言語サポートも受けていませんが、使用しているTSCや、それを変更する方法は完全にはわかりません。

@DavidSouther TypeScriptコンパイラは、package.jsonの「typings」フィールドをチェックして「.d.ts」ファイルを見つけます。 この変更により、正当なエラーのように見えるsrc/app.ts(13,7): error TS2322: Type 'string' is not assignable to type 'number'.が発生します

ああ、私はそのドキュメントを見逃したに違いありません。 私はまだ2番目の問題を抱えています-VSCodetscバージョンを変更するにはどうすればよいですか？

"typescript.tsdk"設定を介してカスタムTypeScript SDKの場所をVSCodeに提供できます。これは、 tsserver.jsファイルと標準の「.d.ts」ファイルを含むフォルダーを指している必要があります。 TypeScriptがnpmパッケージとしてインストールされている場合は、次のようになります。

// Place your settings in this file to overwrite the default settings
{   
    "typescript.tsdk": "C:\\Sources\\bugs\\node\\typescript-example-using-node\\tslib\\node_modules\\typescript\\lib"       
}

誰かがサンプルを動作させましたか？ 午後中ずっとこれで遊んでみましたが、いつも

error TS2307: Cannot find module

現時点では、コードはnode_modules / my-module /にあります。 そして、すべてのエクスポートを処理するindex.tsを定義し、typescript.mainの下のpackage.jsonでそれを参照しました。 コンシューマープロジェクトでは、「my-module」から{AClass}をインポートしようとしました。 my-module = require（ 'my-module'）;をインポートします。 どちらもtypescript1.7.0-dev.20150901で同じエラーが発生します。

--module commonjsの非相対名のモジュールを解決する場合、コンパイラはnode_modules\name\index.d.tsの名前と一致する.d.tsを検索するか、 package.jsonを検索します。プロパティtypingsの場合、それが指す.d.tsをロードします。

説明から、 index.tsに設定しているように見えますが、依存関係をコンパイルする必要はなく、型を使用するだけなので、代わりにindex.d.tsに設定する必要があります。

実装を反映するようにノードモジュール解決アルゴリズムの手順を更新しました： https ：//github.com/Microsoft/TypeScript/issues/2338

@DavidSoutherどうやらまったく同じ問題があります。 node_modulesの依存関係を使用してコンパイルすると、モジュールを解決できず、エラーが出力されますが、それでもjsが生成され、実行すると実行されます。 多分それは私が知らない私のセットアップのせいです。 私のd.tsはほとんど空です。多くの.tsファイルで定義されているモジュールのすべてのクラスのインポートと再エクスポートを処理するindex.tsがあります。 そして、私のd.tsファイルはこのindex.tsを参照し、次のようにindex.tsからすべてをエクスポートします。

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

declare module 'my_module' {
    export * from 'index';
}

また、どういうわけかまだnode_modulesからtsをコンパイルしているので、コンパイル後に削除するクリーンなタスクを追加する必要があります。 プロセスを要約する機能の説明はどこかにありますか？

編集：私はそれを動作させましたが、それは非常にハッキーであり、それでもエラーを出力します。 dts-generatorを使用してd.tsを作成し、次のようにクラスをインポートしました。

import MyClass from '../../node_modules/my_module/dist/MyClass';

'my_module / MyClass'からインポートMyClassを使用すると、エラーなしでコンパイルできますが、実行時にモジュール 'my_module / MyClass'が見つからないというエラーが発生します。 上記のソリューションでは、コンパイルされた.jsを直接指し、実行時にエラーが出力されても、コンパイル時にモジュールが見つかりません。

サブモジュールからのインポートにまだ問題があります（例：npm install angle2、 import { Inject, Binding } from 'angular2/di' 。今夜、含まれているテストケースの取得に取り組みます。

AngularがTypeScriptコンパイラで期待される方法でタイピングをすでにバンドルしているとは思わないでください。

それはおそらく本当です。 私は彼らと協力して、それがどこで終わるかを見ていきます。

この機能は、 https：//github.com/Nemo157/typescript_w_node_modules_exampleなどのtypescript1.1でうまく機能しています。

しかし、typescript 1.5.3で失敗します、何か変更されましたか？

- - - アップデート - - - - -

1.6でリリースされることはわかっています、ありがとう

この「半減期」は1.6.2でしか得られません

まず、 distディレクトリにmy-lib.d.tsを含むライブラリをパッケージ化し、 package.jsonファイルtypings属性でこのファイルをポイントします（例： "typings" : "dist/my-lib.d.ts" ）

次に、このライブラリをTest.ts TypeScriptファイルにインポートします。

import { MyObject } from "my-lib"

MyObjectは適切にインポートされ、変換時にjsコードが出力されます。
Visual Studio Codeは、 MyObjectでの補完も提供します

ただし、次のようなコンパイラの警告が表示されます。
Test.ts(10,60): error TS2306: File '[]/node_modules/my-lib/dist/my-lib.d.ts' is not a module.

Visual Studio Codeは、実際にはインポートをハードエラーとして表示します

ノードパッケージからインポートされたモジュールは、「アンビエントモジュール宣言」ではなく「外部モジュール」である必要があります。 つまり、 declare module "foo" {.. }宣言はありませんが、ファイル内の最上位のインポートまたはエクスポート宣言です。

したがって、パッケージ「my-lib」がtypescriptで記述されている場合は、 --declarationsでビルドし、タイプをメインモジュールの.d.tsファイルに設定します。 そうでない場合で、入力が自分で作成したものであるか、確実に入力したものである場合は、外部モジュールに変更するか、＃4665が解決されるまで待つ必要があります（できればすぐに）。

この制限の理由は、これがグローバルスコープの汚染を引き起こし、後でパッケージユーザーに競合を引き起こす可能性があるためです。 これについては＃4665で長い議論があります。

今後の検索に関するドキュメントは次のとおりです。https ：//github.com/Microsoft/TypeScript/wiki/Typings-for-npm-packages

@mhegazyJavascriptとTypeScriptの両方のコードで使用できるTypescriptで記述されたcommonjsライブラリのビルドを自動化するという私の探求に本当に役立った迅速な返信に感謝します。
import/exportの構文と解像度は最近非常に速く動いているので、私が今欠けていると思うのは、それを構築する方法についての決定的なガイドです。

私はそれを機能させました... 1つの警告（そしてそれ故に別の質問）

これがセットアップの簡略化されたビューです。

ライブラリは、2つのタイプスクリプトファイルA.tsおよびB.ts内の3つのオブジェクトA1、A2、およびBで構成されています。 何かのようなもの

ソース

A.ts

class A1{}
class A2{}
export { A1, A2 }

B.ts

class B{}
export { B }

公開したいものはindex.tsに集められます：

export * from './A'
export * from './B'

建てる
ビルドはgruntの助けを借りて行われ、 --module commonjsと--declarationフラグがtsc 1.6.2に設定されます
ビルドの最終結果は、次のようなツリーになります。

    package.json
    dist/
        js/
             A.js
             B.js
             index.js
        typings/
             A.d.ts
             B.d.ts
             index.d.ts

package.jsonには、次の2つのエントリが含まれています。

"main": "dist/js/index.js",
"typings": "dist/typings/index.d.ts"

TypeScript 1.6.2でこのライブラリを単純なimport {A1, A2, B} from "mylib"で使用すると、まったく問題なく機能します。 複数レベルの依存関係（つまり、ライブラリが相互にインポートする）も正常に機能します。

問題が発生するのは、ライブラリがTypeScriptライブラリではない別のライブラリに依存している場合です。
ライブラリがNode.jsに依存しているとしましょう。
ソースファイルの1つに、NodeJSの型指定への参照があります。
///<reference path="../typings/node/node.d.ts"/>

トランスパイルすると、 <reference >命令は対応する宣言ファイルに格納されます。 問題は、 node.d.tsへのパスが間違っているか存在しない可能性が高いことです。
これについて行くための推奨される方法はありますか？

_注_：この問題は、 index.tsファイルを使用してライブラリの興味深い部分を公開することで軽減されます。これは、 index.tsに<reference >命令を含める理由がなく、1.6であるためです。 .2、コンパイラはAdtsが参照命令に無効なパスを持っていることを気にしていないようです

@bgrieder tsconfig.jsonを使用してPhosphorでこれを処理します：
https://github.com/phosphorjs/phosphor-widget/blob/master/src/tsconfig.json

コンパイルされたファイルに必要な外部型を追加するだけです。 これは、これらの外部型のいずれかがパブリックインターフェイスの一部である場合、コードのコンシューマーもビルドの一部としてそれらの外部型を提供する必要があることを意味します。 _これは大丈夫です_。 これらの定義をバンドルし、コンシューマーが使用する他のlibが同じ定義をバンドルした場合、重複するシンボルの競合が発生します。

@sccolbertはい！
<reference ...>命令を削除すると、すべてのIDEのオートコンプリートが壊れるのではないかと心配していましたが、いいえ。少なくともVisual Studio Code 0.8.0は、 tsconfig.jsonからこれらの定義を選択するのに十分賢いようです。

referenceで完了。 優れた ！

@sccolbert

その中でプレーンなNode.jsプロジェクトと* .d.tsを使用している場合、 tsconfigソリューションはどのように役立ちますか？

@heycalmdown d.tsをtsconfigのfilesフィールドに追加するだけです。これを行う例を次に示します。

https://github.com/phosphorjs/phosphor-widget/blob/master/test/src/tsconfig.json#L11
https://github.com/phosphorjs/phosphor-widget/blob/master/test/src/index.ts#L10

ここでは、expect.jsのd.tsファイルが内部でどのように記述されているかという理由だけで、 import requireを使用する必要があることに注意してください。

わかった。 あなたのリポジトリは一種の良い例のように見えます。

これは実際にTypeScript1.6.2で実装されていますか？

もしそうなら、誰かが私がここで間違っていることを教えてもらえますか？：
https://github.com/chanon/typescript_module_example

おそらくes6インポート構文が必要です。

2015年11月4日水曜日、午前6時10分に[email protected]は次のように書いています。

これは実際にTypeScript1.6.2で実装されていますか？

もしそうなら、誰かが私がここで間違っていることを教えてもらえますか？：
https://github.com/chanon/typescript_module_example

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/Microsoft/TypeScript/issues/247#issuecomment -153688004
。

es6インポート構文を使用するように更新しましたが、同じエラーが発生します（モジュールが見つかりません）。

@chanon node_modulesパッケージのpackage.jsonには、 d.tsファイルを指すtypingsキーが必要ですが、 typescriptキーを指すことはありませんあなたが今持っているような.tsファイル。

PhosphorJS（TS 1.6.2）でノードモジュールの解像度を排他的に使用し、正常に動作します。 次に例を示します： https ：//github.com/phosphorjs/phosphor-widget/blob/f908341cb1d46ada8ad8149e695a75e7ea2fde57/package.json#L6

@sccolbertに感謝しますが、私の最初の提案（この問題の冒頭）は、$ package.jsonのtypescript.mainプロパティを許可することでした。これは、記述されたノードモジュールパッケージのメインのTypeScriptエントリポイントを指します。 TypeScriptで。

これにより、 d.ts入力ファイルを必要とせずにTypeScriptコードでTypeScriptモジュールをインポートできます（それらを生成する必要さえありません）。

@chanonコードを実行するために何をする必要があるかを指摘していました。

@sccolbertありがとうございます。

この特定の機能を要求する別の問題を作成する必要があるかどうかを知っている人が教えてもらえますか？

モジュール解決ロジック（これ以外）に関連する主な問題は、閉じている＃2338と、非常に複雑に見えるSystemJSスタイルのパス解決をサポートすることに関する＃5039のようです。

ただし、この問題で最初に要求されたような単純なCommonJSスタイルのインポートは忘れられているようです。 少なくともtypescript.mainとモジュールとしてのフォルダに関する部分は？

モジュールとモジュールコンシューマーの両方がすでにTypeScriptで記述されている場合、d.tsファイルを用意する必要がある（そして持っていることを望んでいる）ことを理解していません。

実際には、TypeScriptファイルをインポートするのとそれほど違いはありません。

する代わりに：
import * as lib from '../relative/path/to/typescriptFile.ts'

または：
import * as lib from '../../node_modules/myModule/index.ts'

TSCが、通常のnode_modulesパス解決を使用してインポートするtypescriptファイルを見つけられるようにするだけです。 そして、少なくともフォルダをモジュールとして（index.tsを使用して）インポートできるようにして、2番目の例で次のことができるようにします。

import * as lib from 'myModule'

それとも、「依存関係をコンパイルしたくないので、タイピングを消費したいだけなのか」という理由でしょうか。

@chanonあなたが概説する振る舞いは、現在マスターにあるものです。 typescript@nextを試してみてください。

＃2338の元の実装では、それが.d.tsであることを確認するためにいくつかの追加のチェックが追加されました。これは、主にあなたが言及した理由によるものです。 パッケージユーザーがコンパイラの呼び出しごとに「ソース」をコンパイルし、コンパイラオプションに基づいて異なる出力を取得することを望まない場合は、入力を共有するだけです。

ただし、両方のパッケージをビルドしている場合は、それらを繰り返しながらそれを実行することをお勧めします。 制限は＃5278で削除されました。

詳細については、npmパッケージを介してタイピングを共有するためのwikiページをご覧ください： https ：//github.com/Microsoft/TypeScript/wiki/Typings-for-npm-packages

明確化していただきありがとうございます@mhegazy！ やってみます。

@mhegazy typescript@nextで試してみましたが、期待どおりに機能します。

これは素晴らしい！！

そして、この問題と関連する問題に参加してくれた皆さんに感謝します：+1：

この機能が実際に実装されている方法を説明するために、上記の問題テキストに更新を追加しました。

地雷原に足を踏み入れるリスクがありますが、package.jsonにtypingsプロパティが_ない_昔ながらのnpmモジュールでこれがどのように機能することが期待されますか？ tapeまたはget-parameter-namesのいずれかを$＃ typescript@next $で使用しようとすると、パッケージがないためにそれらのパッケージを見つけることができないため、私の顔に爆発します。財産。

確かに、これらはタイプスクリプトモジュールではありませんが、回避策を見つけることができないようで、npmエコシステムのかなりの部分がロックアウトされています。

@danpantry通常、そのモジュール用に特別に作成された通常の.d.tsファイルを使用します。 DefinitelyTypedプロジェクトには、多くの一般的なモジュール用の.d.tsファイルがあります。 DefinitelyTypedからの.d.tsファイルのインストールと管理に役立つtsdユーティリティがあります。

通常のcommonjsrequire構文を使用するだけで、入力せずに通常のモジュールを使用できます。

例えば
var moduleName = require（ "moduleName"）

@chanonは、TypeScriptでES6構文を使用するときに「クラシック」 require構文を使用するのはちょっとしたハックのように感じるので、JavaScriptの依存関係を使用できますが、ありがとうございます。 tsdユーティリティについて聞いたことがありますが、これらの種類のモジュールに/// <reference path=...の使用を開始する必要がない限り、ES6インポートの使用にどのように影響するかわかりません。

はい、それは一方向です。 もう1つの方法は、tsconfig.jsonファイルを使用して、ルートtsd.d.tsファイルを最初のファイルとして配置することです。

tsdとタイピングをカバーするこれを読むことにも興味があるかもしれませんhttps://angularclass.com/the-state-of-typescript-packages/

@joewood情報をありがとう、私が最後にtypescriptを調べたのは、個々の.d.tsファイルの時代でした。 優れた記事

@chanon @danpantry fooのpackage.jsonに型がない場合、 import foo = require('foo') （node_modulesの下にfooがある）が機能しないのは少し残念です。

@wmonoええと、TypeScript 0.80またはそれ以前のimport foo = require('foo')構文は、型指定のあるモジュールをインポートするためだけのものだったので。 タイピングがない場合は、代わりにvar foo = require('foo')を使用します。 だから私はそれがそのままだと言うでしょう。

@chanonごめんなさい; ユーザーエラー。 webpackが「裸の」 requireに苦労しているように見えましたが、問題は他の場所にありました。

申し訳ありませんが、誰かが理由を明確にすることができます
var foo = require('foo');
入力せずに標準のnode_moduleで機能しますが、
import foo from 'foo';
そうじゃない？ それはただ恣意的に定義されたのですか？ 後者が機能しない理由がわかりません。外部JSライブラリに型が含まれているかどうかは関係ありません。

申し訳ありませんが、誰かが理由を明確にすることができます
var foo = require（ 'foo'）;
入力せずに標準のnode_moduleで機能しますが、
'foo'からfooをインポートします。
そうじゃない？ それはただ恣意的に定義されたのですか？ 後者が機能しない理由がわかりません-外部JSライブラリに型が含まれているかどうかは関係ありません。

@harangueは、 var requireが競合するモジュール構文の1つであり（これはcommonjsであり、リスト内の他のものにはamdが含まれます）、_型チェックシステムの外部で_サポートされていたためです。 型システムを使用したい場合は、 import requireを実行します。 ES6が：hammer：を取り、それらすべてを支配する1つの構文（：ring :)と言っている場合...そのモジュール構文をすぐに型チェックシステムでサポートすることは理にかなっています：rose：

@basarat説明してくれてありがとう。 アイコンも役に立ちました。 ;）ES6構文で型チェックが義務付けられている理由はまだわかりません。 コンパイラが「ああ、そのモジュールの型データが見つかりませんでしたが、とにかくインポートします」と言わないようにするにはどうすればよいですか。 この（かなり直感的なIMO）動作はどのような副作用を引き起こしますか？

これは、ES6からTypeScriptに移行する人（私のような）にとっては混乱を招きます。 ES6モジュールのインポート構文はTypeScriptでも同じように動作すると思いますが、残念ながら、ほとんどのnpmパッケージではまったく機能しません...

しかし残念ながら、ほとんどのnpmパッケージではまったく機能しません...

@teohhanhui私は混乱しています。 達成しようとしていることと、それを達成しようとしたコードの具体例を教えてください。 これは私があなたを助けることができるかもしれないためです：rose：

import koa from 'koa';

targetがes6 $の場合、$ Cannot find module 'koa'. (2307)を返します

koaは（もちろん） node_modulesあります

ただし、koaはプロジェクトでTypescriptタイピングを公開していません。 これは、プロジェクトで.d.tsを公開し、package.jsonにリストするパッケージ専用です。 koaはそうではないので、DefinitelyTypedからそれらの型定義を追加でインストールすることをお勧めします。

importステートメントがプレーンなES6モジュールの場合と同じように機能すると予想されるため、これは不適切な決定のように思われます。 （はい、私は知っています。 npmパッケージのほとんどはCommonJSモジュールですが、ここでそれらをサポートすることは賢明なことです。）

私はTypeScriptを初めて使用するので、おそらく間違った理解をしていますが、型の定義はオプションではありませんか？ タイプ定義なしでパッケージをインポートできないのはなぜですか？ 型定義の検索/作成を強制されたくありません。

es6ターゲットを使用する場合は許可されていないため、従来のTSモジュールのインポート構文に切り替えることはできません。

私はTypeScriptを初めて使用するので、おそらく間違った理解をしていますが、型の定義はオプションではありませんか？

それは正しくありません。 _独自のコード内の_型定義は暗黙的である可能性があります。これは、Typescriptコンパイラが「それを理解する」ことを意味します。 Typescriptコンパイラを介してサードパーティのライブラリを渡すことは決してないので、コンパイラはそれらのタイプが何であるかを知ることはありません。 サードパーティのコードを使用することを計画している場合は、 DefinitelyTypedとtsdツールの使用方法を実際に学ぶ必要があります。

@basaratによるこの回答はどうですか？

http://stackoverflow.com/a/27434010/1529493

タイプ定義のない非TypeScriptモジュールをそのままインポートできないのはなぜですか？

彼らはできる： const koa = require(‘koa’)

2016年1月21日14：47、Teoh [email protected]は次のように書いています。

型定義のないモジュールをそのままインポートできないのはなぜですか？

—
このメールに直接返信するか、GitHub https://github.com/Microsoft/TypeScript/issues/247#issuecomment-173574234で表示してください。

@ bgriederES6インポート構文を参照しています。

（つまり、commonjsを使用しています）そうでない場合は、Basaratの回答のdeclare varを使用します

2016年1月21日、14：48、Bruno Griederbruno。 [email protected]は書いた：

彼らはできる： const koa = require(‘koa’)

2016年1月21日14：47、Teoh Han Hui < notifications @ github.comnotifications @ github.com >は次のように書いています。

型定義のないモジュールをそのままインポートできないのはなぜですか？

—
このメールに直接返信するか、GitHub https://github.com/Microsoft/TypeScript/issues/247#issuecomment-173574234で表示してください。

TypeScriptの目標の1つは、有効なJSが有効なTSである必要があるということです。 ES6モジュール構文の場合、TSは、型宣言の有無にかかわらず、これをコンパイルする必要があります。 型宣言がない場合、 importステートメントはanyに解決されるはずです。

私はそれに完全に同意します。

@ジョーウッド👍

2016年1月21日の14:52に、JoeWoodの[email protected]は次のように書いています。

TypeScriptの目標の1つは、有効なJSが有効なTSである必要があるということです。 ES6モジュール構文の場合、TSは、型宣言の有無にかかわらず、これをコンパイルする必要があります。 型宣言がない場合、インポートステートメントはいずれかに解決する必要があります。

私はそれに完全に同意します。

—
このメールに直接返信するか、GitHub https://github.com/Microsoft/TypeScript/issues/247#issuecomment-173575301で表示してください。

FWIWこの動作（すべてのサードパーティライブラリが事前に入力されることを期待している）が、Flow overTypeScriptを使用する原因となっています。 TypeScriptはIDEをサポートしていますが、すべてが事前に入力されることを期待することは、特に次のようなライブラリがたくさんある場合は、実際には合理的ではありません。

• DefinitelyTypedではありません
• ./typingsフォルダーはありません
• 自分で入力する時間がありません

私は自分の成長を助けることを意図した何かと戦う必要はありません。

@ danpantry 、libエントリポイントをanyとして宣言しないのはなぜですか。コンパイラはそれに満足します。

declare var $: any;

これは回避策です。 しかし、TypeScriptがES6モジュールコードを尊重し、適切にフォールバックするのは良い考えだと思います。 トップレベルのモジュールが型指定されていない場合にエラーを報告するのではなく、インポートステートメントがanyにフォールバックできない理由がわかりません。

ランタイムの問題が気付かれずに忍び寄るのを許すよりも、コンパイラーが早くそして大声で失敗すること（現在の振る舞い）を望んでいます。 「これは安全ではなく、自分が何をしているのかを知っている」ことを示すために、明示的にdeclare var foo: any行を設定したいと思います。

型付けが利用できないときにES6インポート構文を許可しないのはなぜですか？「放出防止」エラーではなく、インポートがanyに解決されたことを警告する単純なコンパイラの問題ですか？

2016年1月21日18：42、 S。ChrisColbertnotifications @ github.comは次のように書いています。

ランタイムの問題が気付かれずに忍び寄ることを可能にするのではなく、コンパイラーが早期に大音量で失敗すること（現在の動作）を望んでいます。 私は明示的にdeclarevar fooを使用したいと思います。「これは安全ではなく、自分が何をしているのかを知っている」ことを示す任意の行です。

—
このメールに直接返信するか、GitHub https://github.com/Microsoft/TypeScript/issues/247#issuecomment-173649845で表示してください。

いずれにせよ、コンパイラは現在、モジュールが見つからないと主張していますが、実際には、型定義なしでモジュールをインポートすることを拒否しているだけです。 それはあまり役に立ちませんね。

^^^これは千回です。 私が最初にこの問題に遭遇したとき、私が何か間違ったことをしているという兆候はありませんでした。 何が起きているのかを最終的に理解するのに長い時間がかかりました（ちなみに、この問題はそれを文書化した唯一の見つけられる場所の1つだと思います）。 それはとても不要です。 そして、Angular 2がTypeScriptをより主流にしたことで、私はこの振る舞いからいくつのStackOverflowの質問が来るかを想像することしかできません。

不十分なエラー処理の説明に非常に同意し、そのままインポートします。

@sccolbert通知があるべきだということに同意しますが、それが失敗であるべきかどうかはわかりません-代わりに、おそらく警告です

@mhegazyと@sccolbertに同意します。

何かがおかしいと大声で文句を言うのは、本番ビルドスクリプト（つまりCIサーバー）の方がずっと好きです。

こんにちは、みんな、
この振る舞いは私を夢中にさせます。 定義ファイルが最新でないか、 package.jsonに登録されていません。
結局、 TypeScriptはJavaScript $を生成するので、私たち全員がこの言語に行くまで、plsはあなたのような他のトランスパイル言語で母国語のライブラリを提供する世界の他の地域に優しくします。
TypeScriptがJavaScriptエコシステムにとどまりたいのか（まだ存在しないように見えるので「統合する」と言います）、それとも離れた生活を送りたいのか、本当に知りたいです。 2番目のオプションでは、別の場所に移動します。
.tsconfigファイルの切り替えでうまくいくようにするには、厳密なインポートが必要かどうかを判断できます。
CIの大声での苦情については、 JavaScriptにそのためのテストフレームワークがあります。 とにかく、実行時に型チェックを取得することはありません。不十分なインポートチェックはそれほど重要ではありません。
ではごきげんよう。

@ devel-pa、エラーは、コンパイラがインポートが何であるかを認識していないことを通知するためのものです。 その後のインポートの使用は確認できません。

エラーをオフにしても問題は解決しません。 これらの「未知数」をシステム全体にサイレントにプッシュするだけです。 型情報がないと、コンパイラは何が安全で何が安全でないかについて警告することはできません。 それがTypeScriptの要点です:)

生成されたJSについて。 TSタイプのエラーはいずれも、出力の生成を停止しません。 タイプエラーを気にしない場合は、すべて無視してください。 コンパイラは、一致する.jsファイルを引き続き生成します。

欠落している定義の解決策は、それらを宣言することです。 モジュールの完全な形を宣言する必要はありませんが、名前だけを宣言する必要があります。 これにより、コンパイラはモジュール「myLibrary」があることを認識でき、モジュール名のタイプミスについて警告できます。さらに重要なことに、他のモジュールがチェックされないままになることはありません。

declare module "myLibrary" {
    var a: any;
    export = a;
}

＃6615で概説されているように、TypeScriptはまもなくこれの短い形式をサポートするはずです。

問題は、これがオンボーディングプロジェクトにもたらす苦痛だと思います。 この問題は暗黙のanyに類似していると思います。 現在、これらのインポートは本質的に暗黙のvoidです。 もちろん、エラーは無視できますが、それは多くのノイズを引き起こし、漸進的型付けの哲学に反し、有効なJSは有効なTSです。

TSを初めて使用する人にとって、ここでの混乱は理解できます。 JSでES6モジュール構文を積極的に使用している場合、TSで機能しないのはなぜですか？ var x = require import fromの何が特別なのか、これは暗黙のanyとして扱われます。 もともとインポートはTS固有のキーワードだったので、開発者がモジュールを型付きモジュールとして扱うことを望んでいたことを意味していました。 TSに限定されていないので、仮定を立てることはできないと思います。

暗黙的-エラーは型のない変数宣言にあります。 しかし、宣言されていない変数を使用することは、今日でもエラーです。 jqueryの場合、コンパイラが$というグローバル変数を使用するつもりであり、入力ミスだけではないことをコンパイラが認識できるようにするために、どこかにdeclare var $;が必要です。 モジュールの場合もほぼ同じです。コンパイラは、 "myLibrary"という名前のモジュールがあり、それが名前の入力ミスではないことを知る必要があります。 したがって、宣言を追加するだけです。

いずれにせよ、＃6615は、システム内のすべてのモジュールに一致するようにdeclare module "*";を追加することをサポートする必要がありますが、そうすると、ツールから何の助けも得られず、苦痛に備えることになります。後でそれを削除することにしたときに移行します。

@mhegazy私はあなたの推論を理解していますが、私はこの理論的根拠に本当に問題があります

基本的に、あなたは「プレースホルダー」モジュール定義を設計するように私たちに言っています、そして問題はなくなります。
このリスクは、しばらくすると、適度なサイズのプロジェクトで、これらの「プレースホルダー」定義が忍び寄り、一部のタイピングディレクトリに埋め込まれる可能性があることです。 警告がなくなると、誰もが警告を忘れてしまいます。問題が発生した場合、すべてのモジュール定義を調べて、どちらがプレースホルダーであるかを確認するのは面倒です。

型付きモジュール（package.jsonにtypingsエントリがあるモジュール）では、適切に型指定されていると想定される状況はさらに悪化し、実際にはそれらのプレースホルダーを内部で使用している可能性があります。

これらのプレースホルダーを防ぐことはできないことは理解していますが、少なくとも、推奨されないことを強く望んでいます。
推奨すべきことは、デフォルトでは、インポートはanyに解決され、コンパイラーはコンパイルのたびに警告を発行するということです。 したがって、少なくとも、コンパイラー/ CIログを見ると、何かが潜在的に怪しいものであり、改善する必要があることがわかります。

（余談ですが、typescriptlang.orgホームページに記載されているように、TypescriptはJavascriptの「スーパーセット」であり、IMHOでは有効なES6構文をそのまま飲み込む必要があります）

回避策とカーペットの下にゴミを隠すことは、私にとって起こりうる最悪の事態です（ES6スーパー以外）。
私は常にJSライブラリを使用しており、通常は仕事の一環として最新バージョンを使用し、自宅で追加のコーディングを行っています。 90％は型指定されていないか、古いdefがあり、9％はあまりよく型付けされていません（コンパイラーはすべてのファイルに対して1つのdefを作成することを知らないため）。 同じ前の理由と私のターゲットがJSであるという理由で、どちらの私のものも非常に良いdefを持っていません、私は元の言語を気にする必要はないと思います。
また、「不明な」ライブラリがある理由も確認しました。 いいえ、まったくありません。開発者がどのライブラリが使用されているのか、なぜそれらを気にするのか、なぜ私がものを使用しているのか、なぜスタックに追加しているのかを知らず、理解していない場合。 警告とテスト（存在する場合）で十分です。
pls、JavaScriptを最初に、これがターゲットでありエコシステムです。 TSは、コンパイル時のコーディングと型チェックを改善するための単なるアクセサリですが、これは私たちが構築しているものに限られます。 残りはtypescriptsビジネスではありません。
私もnmps peerDependenciesに反対していたことを述べたいと思います。私が選んだのはソフトウェアではなく、私です。 命令型プログラミング、ベイビー。

node_modulesではなくJSPMディレクトリからモジュールをインポートするのはどうですか？

編集：既存のチケットを見つけました-> https://github.com/Microsoft/TypeScript/issues/6012

SystemJSを使用してディレクトリをロードするときに、ノードモジュールの解決に関する問題が発生しました。

どうやら、Node（したがってTypeScript）はパスが実際にはディレクトリであることを理解しているため、代わりにindex.tsをロードしますが、SystemJSはそのようなことを行わないため、有効なTSコードは実際にはブラウザーにロードされません。

これは、index.ts / jsエントリポイントがあるノードモジュール、またはpackage.json mainプロパティを使用するノードモジュールにも当てはまります。 SystemJSにパッケージ構成を追加するのは簡単ですが（繰り返しですが）、これは操作が少し簡単です。 これは、任意のディレクトリを操作する場合はそれほど簡単ではありません。

これに対する適切な解決策は何ですか？

JSPM自動モジュール解決は現在サポートされていません。 これはhttps://github.com/Microsoft/TypeScript/issues/6012によって追跡されます。

パスマッピングモジュールの解決サポートを使用することをお勧めします。https：//github.com/Microsoft/TypeScript-Handbook/blob/release-2.0/pages/Module%20Resolution.md#path-mappingを参照してください。

上記の手順は始まりですが、一部の人は追加のことをする必要があるかもしれません...あなたは追加する必要があるかもしれません
<Folder Include="node_modules" />
.njsprojへ

より詳しい情報

私はgulpを使用してビルドしていて、.nsprojでTypeScriptCompileBlockedを使用していました。 VS 15 Preview 5でブレークポイントをデバッグする際の問題（「フレームがモジュールにありません」エラーが発生していました）と、インテリセンスで発生していた問題を修正するには、追加する必要がありました .njsprojに。 そのディレクトリは、プロジェクトをインポートしたときにすでに存在していましたが、git-ignoreに設定されていました。 これが、Visual Studioがそれを無視した理由に関する私の理論です（おそらく、node_modulesの自動例外があるはずですか？）

デバッグとインテリセンスの両方が機能するだけでなく、ビルド中にgulpから見たのとまったく同じエラーを超えて、インテリセンスエラーが表示されなくなりました。これは予想どおりです。