すべてのファイルに対して膨大な数のファイルが生成されます。 Angular プロジェクト
Angular用の簡単なHello Worldアプリを起動したいと思いました。
公式の quickstart の指示に従ったとき、インストールによって私のプロジェクトに32,000ファイルが作成されました。
私はこれがいくつかの間違いであることを考え出したか私が何かを逃したので、私は angular-cli を使用することにしました、しかし私は41,000ファイルを数えました。
どこで私は間違えましたか？私は本当に本当に明白な何かが足りないのですか？
設定に問題はありません。
Angular（バージョン2.0以降）は、開発にnpmモジュールと依存関係を使用します。それがあなたがそのような膨大な数のファイルを見ている唯一の理由です。
Angularの基本設定にはtranspilerが含まれています。これは開発目的のためだけに essential の依存関係をタイプするためのものです。
開発が終わったら、このアプリケーションをバンドルするだけです。
アプリケーションをバンドルした後は、bundle.jsファイルが1つだけになり、それをサーバーにデプロイできます。
'transpiler' は単なるコンパイラです。追加してくれてありがとう@omninononsense。
Typical Angular2 Project
NPMパッケージ ファイル（開発） 実世界のファイル（配置）
@angular 3,236 1
rxJS 1,349 1*
core-js 1,341 2
typings 1,488 0
gulp 1,218 0
gulp-TypeScript 1,243 0
lite-server 5,654 0
systemjs-builder 6,470 0
__________________________________________________________________
Total 21,999 3
*：bundled with @angular
development の設定に問題はありません。
production 設定に問題があります。
「Angular 2プロジェクト」または「JSをベースにした任意のプロジェクト」を開発するときは、すべてのファイルを使用できます。すべてのファイルを試してみることも、すべてのファイルをインポートすることもできます。しかし、このプロジェクトを提供したいのであれば、すべての構造化ファイルを _結合_ 結合して、不要なファイルを削除する必要があります。
これらのファイルを組み合わせるためのオプションはたくさんあります。
- ゆいコンプレッサー
- Googleクロージャコンパイラ
- サーバー側（私はそれが一番だと思います） _ gulp _
何人かの人がすでに述べたように、node_modulesディレクトリ（パッケージのNPMの場所）内のすべてのファイルは、プロジェクトの依存関係の一部です（いわゆる直接依存関係）。それに加えて、あなたの依存関係はそれ自身の依存関係などを持つこともできます（いわゆる推移的依存関係）。数万のファイルは特別なものではありません。
あなたは10'000のファイルをアップロードすることしか許されていないので（コメントを見てください）、私はバンドラーエンジンを使うでしょう。このエンジンはあなたのすべてのJavaScript、CSS、HTMLなどをバンドルし、単一のバンドルを作成します（それらを指定した場合はそれ以上）。あなたのindex.htmlはこのバンドルをロードするでしょう、そしてそれはそれです。
私はWebPackのファンなので、私のWebPackソリューションはアプリケーションバンドルとベンダーバンドルを作成します（完全に機能するアプリケーションについては、こちらをご覧ください https://github.com/swaechter/project-collection/tree/master/web-角度2の例 ）：
index.html
<!DOCTYPE html>
<html>
<head>
<base href="/">
<title>Webcms</title>
</head>
<body>
<webcms-application>Applikation wird geladen, bitte warten...</webcms-application>
<script type="text/javascript" src="vendor.bundle.js"></script>
<script type="text/javascript" src="main.bundle.js"></script>
</body>
</html>
webpack.config.js
var webpack = require("webpack");
var path = require('path');
var ProvidePlugin = require('webpack/lib/ProvidePlugin');
var CommonsChunkPlugin = require('webpack/lib/optimize/CommonsChunkPlugin');
var UglifyJsPlugin = require('webpack/lib/optimize/UglifyJsPlugin');
/*
* Configuration
*/
module.exports = {
devtool: 'source-map',
debug: true,
entry: {
'main': './app/main.ts'
},
// Bundle configuration
output: {
path: root('dist'),
filename: '[name].bundle.js',
sourceMapFilename: '[name].map',
chunkFilename: '[id].chunk.js'
},
// Include configuration
resolve: {
extensions: ['', '.ts', '.js', '.css', '.html']
},
// Module configuration
module: {
preLoaders: [
// Lint all TypeScript files
{test: /\.ts$/, loader: 'tslint-loader'}
],
loaders: [
// Include all TypeScript files
{test: /\.ts$/, loader: 'ts-loader'},
// Include all HTML files
{test: /\.html$/, loader: 'raw-loader'},
// Include all CSS files
{test: /\.css$/, loader: 'raw-loader'},
]
},
// Plugin configuration
plugins: [
// Bundle all third party libraries
new CommonsChunkPlugin({name: 'vendor', filename: 'vendor.bundle.js', minChunks: Infinity}),
// Uglify all bundles
new UglifyJsPlugin({compress: {warnings: false}}),
],
// Linter configuration
tslint: {
emitErrors: false,
failOnHint: false
}
};
// Helper functions
function root(args) {
args = Array.prototype.slice.call(arguments, 0);
return path.join.apply(path, [__dirname].concat(args));
}
利点：
- フルビルドライン（TSリンティング、コンパイル、縮小など）
- デプロイ用の3つのファイル - >少数のHTTPリクエストのみ
デメリット：
- より長い構築時間
- Http 2プロジェクトに最適な解決策ではありません（免責条項を参照）
免責事項： これは、Http 1 *に適した解決策です。Httpリクエストごとのオーバーヘッドを最小限に抑えるためです。 index.htmlと各バンドルに対するリクエストのみがあります - 100〜200ファイルに対するリクエストはありません。現時点では、これが進むべき道です。
一方、Http 2はHttpのオーバーヘッドを最小化しようとしているので、それはストリームプロトコルに基づいています。このストリームは両方向（Client <--> Server）と、よりインテリジェントなリソースローディングが可能であるという理由で（あなたは必要なファイルだけをロードする）通信することができます。このストリームは、HTTPのオーバーヘッド（Httpのラウンドトリップの減少）の大部分を排除します。
しかし、それはIPv6と同じです。人々が本当にHttp 2を使うようになるまでには数年かかるでしょう
Angular CLI によって生成されたプロジェクトからdist（配布可能の略）フォルダを展開するだけであることを確認する必要があります。これにより、ツールはソースコードとその依存関係を取得し、アプリケーションを実行するために必要なものだけを提供することができます。
`ng build --prod 'を介したプロダクションビルドに関してAngular CLIに問題がある/あったと言われている
昨日（2016年8月2日）、ビルドメカニズムを broccoli + systemjs から webpack に変更して、本番ビルドを正常に処理するリリースが行われました。
これらのステップに基づきます。
ng new test-project
ng build --prod
distフォルダサイズが 1.1 MB にまたがる 14個のファイル がここにリストされています。
./app/index.js
./app/size-check.component.css
./app/size-check.component.html
./favicon.ico
./index.html
./main.js
./system-config.js
./tsconfig.json
./vendor/es6-shim/es6-shim.js
./vendor/reflect-metadata/Reflect.js
./vendor/systemjs/dist/system.src.js
./vendor/zone.js/dist/zone.js
注 現在、角型クリップのWebパックバージョンをインストールするには、実行する必要があります... npm install angular-cli@webpack -g
Angular自体には多くの依存関係があり、ベータ版のCLIではさらに4倍のファイルがダウンロードされます。
これは簡単なプロジェクトを作成する方法ですファイルが少なくなります（「唯一の」10Kファイル） https://yakovfain.com/2016/05/06/starting-an-angular-2-rc-1-project/
ここで説明されているように誰もがAhead-of-Time Compilationを言及していないようです： https://angular.io/docs/ts/latest/cookbook/aot-compiler.html
これまでのAngularでの経験は、AoTがロード時間をほとんど必要とせずに最小のビルドを作成するということです。そして、ここでの質問が最も重要である - あなたは本番に少数のファイルを出荷するだけでよいです。
これは、テンプレートが "Ahead of Time"でコンパイルされているため、Angularコンパイラがプロダクションビルドに同梱されないためです。 HTMLテンプレートのマークアップが、元のHTMLにリバースエンジニアリングするのが非常に難しいJavaScriptの命令に変換されているのも非常にクールです。
Dev vs AoTビルドのAngularアプリのダウンロードサイズ、ファイル数などを説明した簡単なビデオを作成しました。こちらをご覧ください。
デモのソースコードはここにあります。
https://github.com/fintechneo/angular2-templates
そして、他のすべての人がここで言っているように、開発環境にたくさんのファイルがあっても問題はありません。それが、Angularや他の多くの現代的なフレームワークに付随するすべての依存関係と同じです。しかし、ここでの違いは、プロダクションへの出荷時には、それをいくつかのファイルにまとめることができるはずだということです。また、これらの依存関係ファイルすべてをあなたのgitリポジトリに入れたくないでしょう。
これは実際にはAngular固有のものではなく、そのツールとしてNodeJs/npmエコシステムを使用するほとんどすべてのプロジェクトで発生します。
それらのプロジェクトはあなたのnode_modulesフォルダの中にあり、あなたの直接の依存関係が実行する必要がある一時的な依存関係です。
通常、ノードのエコシステムモジュールは小さく、自分自身で開発するのではなく、必要なもののほとんどをモジュールの形でインポートする傾向があることを意味します。これは、有名な左パッド機能のような小さなことを含むことができます、なぜ練習としてではないにしても私たち自身でそれを書いてください？
それで、たくさんのファイルを持っていることは実際には良いことです、それはすべてが非常にモジュラーで、モジュールの作者が他のモジュールを頻繁に再利用したことを意味します。このモジュール性の容易さは、おそらくノードエコシステムがそれほど速く成長した主な理由の1つです。
原則としてこれは問題にならないはずですが、Google App Engineのファイルカウント制限に遭遇するようです。その場合は、node_modulesをアプリエンジンにアップロードしないことをお勧めします。
代わりに、アプリケーションをローカルでビルドし、バンドルされたファイルのみをGoogle App Engineにアップロードしますが、App Engine自体のビルドにはアップロードしません。
角度クリの新しいバージョンを使用している場合はng build --prodを使用してください。
dist フォルダが作成され、ファイル数が少なくなり、プロジェクトの速度が上がります。
また、角度クリの最高のパフォーマンスを備えたローカルでのテストには、ng serve --prodを使用できます。
Angular CLIを使用する場合は、プロジェクトを作成するときに常に--minimalフラグを使用できます。
ng new name --minimal
フラグを付けて実行したところ、24 600個のファイルが作成され、ng build --prodによって212 KBのdistフォルダが作成されます。
あなたがあなたのプロジェクトで噴水を必要としないか、単に何かこれを素早くテストしたいのであれば、私はかなり便利だと思います
これは角度のあるプロジェクトでより多くのスペースを取るものの比較です。 
ファイルシステムがシンボリックリンクをサポートしている場合は、少なくともこれらすべてのファイルを隠しフォルダに委任することができます。そのため、treeのようなスマートツールではデフォルトで表示されません。
mv node_modules .blergyblerp && ln -s .blergyblerp node_modules
このために隠しフォルダを使用すると、これらはリビジョン管理に保存する必要がない、またはデプロイメントで直接使用する必要がないビルド関連の中間ファイルであるという理解を深めることもできます。
何も問題ありません。これらは、package.jsonに記載されているすべてのノード依存関係です。
Git Hubプロジェクトの一部をダウンロードした場合は注意してください。角度2の最初のhello worldアプリには実際には必要ではない他の依存関係が多数ある可能性があります。
- 角度依存性があることを確認してください。-rxjs -gulp -TypeScript -tslint -docker
最近angular cliで新しいプロジェクトを作成し、node_modulesフォルダーが270 mbだったので、これは正常ですが、angularの世界のほとんどの新しい開発者はこれに疑問を持ち、有効です。単純な新しいプロジェクトの場合、依存関係を少し減らすことは理にかなっています。すべてのパッケージが依存しているものがわからないことは、特に新しい開発者が初めてcliを試してみると少し不安になります。事実に加えて、最も基本的なチュートリアルでは、必要なだけエクスポートされたファイルを取得するための展開設定については説明していません。 angular公式Webサイトで提供されているチュートリアルでさえ、単純なプロジェクトを展開する方法について話しているとは思わない。
