모든 Angular 프로젝트에 대해 생성되는 엄청난 수의 파일
Angular를위한 간단한 hello world 앱을 시작하고 싶었습니다.
공식 빠른 시작 의 지침을 따랐을 때 설치 과정에서 내 프로젝트에 32,000 개의 파일이 생성되었습니다.
나는 이것이 실수라고 생각하거나 뭔가 놓친 것 같아서 angular-cli 를 사용하기로 결정 했지만 프로젝트를 설정 한 후 41,000 개의 파일을 계산했습니다.
내가 어디로 잘못 되었습니까? 정말 분명한 게 빠졌나요?
구성에 문제가 없습니다.
Angular (버전 2.0부터)는 개발을 위해 npm 모듈과 종속성을 사용합니다. 이것이 엄청난 수의 파일을 보는 유일한 이유입니다.
Angular의 기본 설정에는 개발 목적에만 필수적인 종속성을 입력하는 트랜스 파일러가 포함되어 있습니다 .
개발이 완료되면이 애플리케이션을 번들링하기 만하면됩니다.
애플리케이션을 번들링 한 후에는 bundle.js서버에 배포 할 수있는 파일이 하나만 있습니다.
'transpiler' 는 컴파일러 일뿐입니다. 추가해 주신 @omninonsense에게 감사드립니다.
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
[ 번들링 과정은 이쪽 ⇗ ]
개발 구성에 문제가 없습니다 .
프로덕션 구성에 문제가 있습니다 .
"Angular 2 프로젝트"또는 "JS를 기반으로하는 모든 프로젝트"를 개발할 때 모든 파일을 사용할 수 있으며 모든 파일을 시도 할 수 있으며 모든 파일을 가져올 수 있습니다. 이 프로젝트를 제공하려는 경우하지만 당신은 할 필요가 COMBINE 모든 구성 파일 및 쓸모없는 파일을 제거.
이러한 파일을 함께 결합하는 데는 많은 옵션이 있습니다.
- YUI 압축기
- Google 클로저 컴파일러
- 서버 측 (최고라고 생각합니다) GULP
여러 사람이 이미 언급했듯이 node_modules 디렉터리 (패키지의 NPM 위치)에있는 모든 파일은 프로젝트 종속성 (소위 직접 종속성)의 일부입니다. 그 외에도 종속성은 자체 종속성 등을 가질 수 있습니다 (소위 전이 종속성). 수만 개의 파일은 특별한 것이 아닙니다.
10,000 개의 파일 만 업로드 할 수 있기 때문에 (댓글 참조) 번 들러 엔진을 사용하겠습니다. 이 엔진은 모든 자바 스크립트, CSS, HTML 등을 번들로 묶고 단일 번들을 생성합니다 (또는 지정하는 경우 그 이상). index.html이이 번들을로드하고 그게 전부입니다.
저는 웹팩의 팬이므로 제 웹팩 솔루션은 애플리케이션 번들과 공급 업체 번들을 생성합니다 (전체 작동 애플리케이션은 여기 https://github.com/swaechter/project-collection/tree/master/web-angular2- 참조). 예 ) :
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 linting, 컴파일, 축소 등)
- 배포 용 파일 3 개-> Http 요청이 거의 없음
단점 :
- 더 높은 빌드 시간
- Http 2 프로젝트에 가장 적합한 솔루션이 아닙니다 (면책 조항 참조).
Disclaimer: This is a good solution for Http 1.*, because it minimizes the overhead for each Http request. You only have a request for your index.html and each bundle - but not for 100 - 200 files. At the moment, this is the way to go.
Http 2, on the other hand, tries to minimize the Http overhead, so it's based on a stream protocol. This stream is able to communicate in both direction (Client <--> Server) and as a reason of that, a more intelligent resource loading is possible (You only load the required files). The stream eliminates much of the Http overhead (Less Http round trips).
But it's the same as with IPv6: It will take a few years until people will really use Http 2
You need to ensure that you're just deploying the dist (short for distributable) folder from your project generated by the Angular CLI. This allows the tool to take your source code and it's dependencies and only give you what you need in order to run your application.
That being said there is/was an issue with the Angular CLI in regards to production builds via `ng build --prod
Yesterday (August 2, 2016) a release was done which switched the build mechanism from broccoli + systemjs to webpack which successfully handles production builds.
Based upon these steps:
ng new test-project
ng build --prod
I am seeing a dist folder size of 1.1 MB across the 14 files listed here:
./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
Note Currently to install the webpack version of the angular cli, you must run... npm install angular-cli@webpack -g
Angular itself has lots of dependencies, and the beta version of CLI downloads four times more files.
This is how to create a simple project will less files ("only" 10K files) https://yakovfain.com/2016/05/06/starting-an-angular-2-rc-1-project/
Seems like nobody have mentioned Ahead-of-Time Compilation as described here: https://angular.io/docs/ts/latest/cookbook/aot-compiler.html
My experience with Angular so far is that AoT creates the smallest builds with almost no loading time. And most important as the question here is about - you only need to ship a few files to production.
This seems to be because the Angular compiler will not be shipped with the production builds as the templates are compiled "Ahead of Time". It's also very cool to see your HTML template markup transformed to javascript instructions that would be very hard to reverse engineer into the original HTML.
I've made a simple video where I demonstrate download size, number of files etc. for an Angular app in dev vs AoT build - which you can see here:
You'll find the source code for the demo here:
https://github.com/fintechneo/angular2-templates
And - as all the others said here - there's nothing wrong when there are many files in your development environment. That's how it is with all the dependencies that comes with Angular, and many other modern frameworks. But the difference here is that when shipping to production you should be able to pack it into a few files. Also you don't want all of these dependency files in your git repository.
This is actually not Angular specific, it happens with almost any project that uses the NodeJs / npm ecosystem for its tooling.
Those project are inside your node_modules folders, and are the transititve dependencies that your direct dependencies need to run.
In the node ecosystem modules are usually small, meaning that instead of developing things ourselves we tend to import most of what we need under the form of a module. This can include such small things like the famous left-pad function, why write it ourselves if not as an exercise ?
So having a lot of files its actually a good thing, it means everything is very modular and module authors frequently reused other modules. This ease of modularity is probably one of the main reasons why the node ecosystem grew so fast.
In principle this should not cause any issue, but it seems you run into a google app engine file count limit. In that I case I suggest to not upload node_modules to app engine.
instead build the application locally and upload to google app engine only the bundled filesn but don't to the build in app engine itself.
If you are using angular cli's newer version use ng build --prod
It will create dist folder which have less files and speed of project will increased.
Also for testing in local with best performance of angular cli you can use ng serve --prod
if you use Angular CLI you can always use --minimal flag when you create a project
ng new name --minimal
I've just run it with the flag and it creates 24 600 files and ng build --prod produces 212 KB dist folder
So if you don't need water fountains in your project or just want to quickly test something out this I think is pretty useful
Here is a comparison of what takes more space in angular projects. 
If your file system supports symbolic links, then you can at least relegate all of these files to a hidden folder -- so that a smart tool like tree won't display them by default.
mv node_modules .blergyblerp && ln -s .blergyblerp node_modules
Using a hidden folder for this may also encourage the understanding that these are build-related intermediate files that don't need to be saved to revision control -- or used directly in your deployment.
There is nothing wrong. These are all the node dependencies that you have mentioned in the package.json.
Just be careful if you have download some of the git hub project, it might have lot of other dependencies that are not actually require for angular 2 first hello world app :)
- make sure you have angular dependencies -rxjs -gulp -typescript -tslint -docker
Creating a new project with angular cli recently and the node_modules folder was 270 mb, so yes this is normal but I'm sure most new devs to the angular world question this and is valid. For a simple new project it would make sense to pare the dependencies down maybe a bit;) Not knowing what all the packages depend on can be a bit unnerving especially to new devs trying the cli out for the first time. Add to the fact most basic tutorials don't discuss the deployment settings to get the exported files only needed. I don't believe even the tutorial offered on the angular official website talks about how to deploy the simple project.
'Program Tip' 카테고리의 다른 글
| 코코아 : 프레임과 경계의 차이점은 무엇입니까? (0) | 2020.10.03 |
|---|---|
| jQuery를 사용하여“Please Wait, Loading…”애니메이션을 어떻게 만들 수 있습니까? (0) | 2020.10.03 |
| 분기 된 저장소에서 풀 요청을 업데이트하는 방법은 무엇입니까? (0) | 2020.10.03 |
| Java 용 소멸자가 있습니까? (0) | 2020.10.03 |
| Entity Framework의 SqlException-세션에서 실행중인 다른 스레드가 있으므로 새 트랜잭션이 허용되지 않습니다. (0) | 2020.10.03 |