모든 Angular 프로젝트에 대해 생성 된 엄청난 수의 파일

594

Angular에 대한 간단한 hello world 앱을 시작하고 싶었습니다.

공식 빠른 시작 의 지침에 따라 설치시 프로젝트에 32,000 개의 파일이 생성되었습니다.

나는 이것이 실수이거나 무언가를 놓쳤다 고 생각했기 때문에 angular-cli 을 사용하기로 결정 했지만 프로젝트를 설정 한 후 41,000 개의 파일을 계산했습니다.

내가 어디로 잘못 갔니? 내가 정말로 분명한 것을 놓치고 있습니까?

javascript  angular 
— 모쉐 샤함
소스
98
NPM으로 구동되는 프로젝트는 정상입니다.
— Everettss
115
내 배포 (Google 앱 엔진)에서 10K 파일 만 허용하기 때문에 @hendrix
— Moshe Shaham
49
이 질문에 대한 투표 수와 그 답변에 대해 궁금한 사람은 HN 첫 페이지를 만들었습니다. news.ycombinator.com/item?id=12209028
— ceejayoz
50
@hendrix-.DS_Store 파일을 git에 커밋합니다.
— Martin Konecny
61
"hello world 앱이 작동하면 모든 것이 정상입니다."는 특히 배우는 사람에게 따라야 할 좋은 철학이 아닙니다. OP는 왜 그렇게 많은 파일이 만들어 졌는지 의문을 제기 할 권리입니다. 예제 자체는 5 개의 파일 만 참조합니다. 그리고 솔직히, 출력에 문자보다 많은 파일을 가진 응용 프로그램은 질문해야합니다.
— Shawn

답변:

362

구성에 아무런 문제가 없습니다.

Angular (버전 2.0부터)는 개발을 위해 npm 모듈과 종속성을 사용합니다. 그것이 수많은 파일을 보는 유일한 이유입니다.

각도의 기본 설정은 transpiler, typings 종속성이 포함되어 필수 개발 용으로 만 사용합니다.

개발이 끝나면이 응용 프로그램을 번들로 제공하기 만하면됩니다.

응용 프로그램을 번들링 한 후에는 bundle.js서버에 배포 할 수있는 파일이 하나만 있습니다.

'transpiler' 는 컴파일러 일뿐입니다. @omninonsense를 추가해 주셔서 감사합니다.

— 부샨가 데카르
소스
7
또한 일반적으로 테스트 데이터 및 테스트를 제공하고 종속성 및 해당 종속성 등에 대한 도구를 빌드합니다.
— Benjamin Gruenbaum
63
"변환기"는 단지 컴파일러 일뿐입니다.
— omninonsense
31
바이트 코드 나 머신 코드 대신 다른 언어로 컴파일
— Hunter McMillen
32
@HunterMcMillen 바이트 코드 및 / 또는 머신 코드는 다른 언어입니다. "트랜스 파일러"라는 용어는 "컴파일러"라는 추가 의미가 없습니다.
— Brandon Buck
76
관련된 모든 것과 관련하여 의미 론적 논증이 OP의 질문과 실제로 관련이 있는지 확실하지 않습니다 ^^
— Dan Pantry
144 
                                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

[ 동고 과정은 see ]

— 안킷 싱
소스
24
나는 -3합계를하지 않은 것으로 생각 했지만 지금은 :)
— Ankit Singh
1
실제 파일은 무엇을 의미합니까?
— yeahman
1
@yeahman "실제 파일" 은 프로젝트가 배포 되거나 프로덕션 환경에 있을 때의 파일 수입니다 .
— Maarti
또한 크기의 수는 만 3 파일, 그러나 그들은 (웹) 거대한 수 있습니다
— pdem
51

개발 구성 에는 아무런 문제가 없습니다 .

프로덕션 구성에 문제가 있습니다 .

"Angular 2 프로젝트"또는 "JS 기반의 모든 프로젝트"를 개발할 때 모든 파일을 사용할 수 있으며 모든 파일을 시도 할 수 있으며 모든 파일을 가져올 수 있습니다. 이 프로젝트를 제공하려는 경우하지만 당신은 할 필요가 COMBINE 모든 구성 파일 및 쓸모없는 파일을 제거.

이 파일들을 결합하기위한 많은 옵션이 있습니다 :

— 허리케인
소스
2
서버에서 파일을 함께 연결하지 않아야합니다 (인용 필요). 기껏해야 트랜스 파일러를 사용합니다.
— Dan Pantry
1
@DanPantry Transpilers는 소스-소스 컴파일러입니다. "X"를 "JS"로만 변경할 수 있다고 생각합니다. 파일 수는 동일합니다.
— 허리케인
1
그렇습니다. 그러나 당신의 요점은 확실하지 않습니다. 내 요점은 아마도 파일을 연결하고 파일 크기를 줄임으로써 서버 코드를 축소하려고 시도해서는 안된다는 것입니다. async / await와 같은 출혈 기능을 사용하는 경우 코드에서 Babel을 사용해야합니다.
— Dan Pantry
2
@ DanPantry 동의합니다. 그러나 의견에 따르면 "내 배포 (Google 앱 엔진)는 10K 파일 만 허용하기 때문에"라고 말합니다. 이러한 조건에서는 파일 수를 줄여야합니다.
— 허리케인
4
동의하지만 OP는 XY 문제가있는 것 같습니다
— Dan Pantry
30

여러 사람들이 이미 언급했듯이 node_modules 디렉토리의 모든 파일 (패키지의 NPM 위치)은 프로젝트 종속성 (소위 직접 종속성)의 일부입니다. 그 외에도 종속성은 고유 한 종속성 등을 가질 수 있습니다 (소위 전이 종속성). 수만 개의 파일은 특별한 것이 아닙니다.

10,000 개의 파일 만 업로드 할 수 있기 때문에 (댓글 참조) 번 들러 엔진을 사용합니다. 이 엔진은 모든 JavaScript, 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 린트, 컴파일, 축소 등)
  • 배포 용 파일 3 개-> 몇 개의 HTTP 요청 만

단점 :

  • 더 높은 빌드 시간
  • Http 2 프로젝트에 가장 적합한 솔루션은 아님 (면책 조항 참조)

면책 조항 : 이것은 각 HTTP 요청에 대한 오버 헤드를 최소화하기 때문에 Http 1. *에 대한 좋은 솔루션입니다. index.html 및 각 번들에 대한 요청 만 있지만 100-200 파일에 대한 요청은 없습니다. 현재, 이것은 갈 길입니다.

반면에 Http 2는 Http 오버 헤드를 최소화하려고 시도하므로 스트림 프로토콜을 기반으로합니다. 이 스트림은 양방향 (클라이언트 <-> 서버)으로 통신 할 수 있으며 그로 인해보다 지능적인 리소스로드가 가능합니다 (필요한 파일 만로드). 이 스트림은 많은 Http 오버 헤드 (Http 왕복이 적음)를 제거합니다.

그러나 IPv6과 동일합니다. 사람들이 실제로 Http 2를 사용할 때까지 몇 년이 걸립니다.

— Swaechter
소스
1
OP angular-cli는 이미 번 들러 (동일한 제안 된 웹 팩)와 함께 제공되는 것을 사용했기 때문에 필요하지 않습니다 .
— mattarau
2
@mdentinho 예,보다 현대적인 릴리스입니다. 그러나 2016 년에 SystemJS와 CLI는 갈 길이었습니다 (현재 우리는 웹팩을 가지고 있습니다)
— swaechter
21

Angular CLI에 의해 생성 된 프로젝트에서 dist (배포 가능)의 폴더를 배포해야합니다 . 이를 통해 도구가 소스 코드와 종속성을 가져 와서 응용 프로그램을 실행하는 데 필요한 것만 제공 할 수 있습니다.

ng build --prod를 통한 프로덕션 빌드와 관련하여 Angular CLI에 문제가 있다고합니다.

어제 (2016 년 8 월 2 일) 제작 메커니즘을 브로콜리 + systemjs 에서 웹팩 으로 전환하여 프로덕션 빌드를 성공적으로 처리 하는 릴리스가 완료 되었습니다.

이 단계를 기반으로 :

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

참고 현재 각도 cli의 웹팩 버전을 설치하려면 다음을 실행해야합니다.npm install angular-cli@webpack -g

— 브로코
소스
12

아무도 여기에 설명 된대로 Ahead-of-Time Compilation을 언급하지 않은 것 같습니다 : https://angular.io/docs/ts/latest/cookbook/aot-compiler.html

지금까지 Angular에 대한 나의 경험은 AoT가 로딩 시간이 거의없이 가장 작은 빌드를 생성한다는 것입니다. 여기서 가장 중요한 질문은 프로덕션에 몇 개의 파일 만 보내면됩니다.

템플릿이 "Ahead of Time"으로 컴파일되므로 Angular 컴파일러는 프로덕션 빌드와 함께 제공되지 않기 때문입니다. HTML 템플릿 마크 업이 자바 스크립트 명령어로 변환되어 원래의 HTML로 리버스 엔지니어링하기가 매우 어려울 수도 있습니다.

dev에서 AoT 빌드의 Angular 앱에 대한 다운로드 크기, 파일 수 등을 보여주는 간단한 비디오를 만들었습니다. 여기에서 볼 수 있습니다.

https://youtu.be/ZoZDCgQwnmQ

데모 소스 코드는 다음과 같습니다.

https://github.com/fintechneo/angular2-templates

그리고 다른 모든 사람들이 여기에서 말했듯이 개발 환경에 많은 파일이있을 때 아무런 문제가 없습니다. 이것이 Angular와 함께 제공되는 모든 의존성 및 다른 많은 현대 프레임 워크와 함께하는 방식입니다. 그러나 여기서 차이점은 프로덕션으로 배송 할 때 몇 개의 파일로 압축 할 수 있어야한다는 것입니다. 또한 git 저장소에 이러한 종속성 파일을 모두 원하지는 않습니다.

— 피터 살로몬 센
소스
8

이것은 실제로 Angular에 국한된 것이 아니며, NodeJs / npm 생태계를 툴링에 사용하는 거의 모든 프로젝트에서 발생합니다.

이러한 프로젝트는 node_modules 폴더 안에 있으며 직접 종속성을 실행해야하는 통과 종속성입니다.

노드 생태계 모듈은 일반적으로 작기 때문에 자체 개발하는 대신 모듈 형태로 필요한 것을 대부분 가져 오는 경향이 있습니다. 여기에는 유명한 왼쪽 패드 기능과 같은 작은 것들이 포함될 수 있습니다. 왜 운동이 아닌 경우 직접 작성합니까?

따라서 실제로 많은 파일을 보유하고있는 것은 모든 것이 매우 모듈 식이며 모듈 작성자는 다른 모듈을 자주 재사용한다는 의미입니다. 이러한 모듈 식의 용이성은 아마도 노드 생태계가 그렇게 빠르게 성장한 주된 이유 중 하나 일 것입니다.

원칙적으로 이것은 문제를 일으키지 않아야하지만 Google 앱 엔진 파일 수 제한에 도달 한 것 같습니다. 이 경우 node_modules를 앱 엔진에 업로드하지 않는 것이 좋습니다.

대신 응용 프로그램을 로컬로 빌드하고 번들 파일로만 Google 앱 엔진에 업로드하지만 앱 엔진 자체에는 빌드하지 마십시오.

— 앵귤러 대학교
소스
8

앵귤러 클리의 최신 버전을 사용하는 경우 ng build --prod

파일이 적은 dist 폴더를 생성 하고 프로젝트 속도가 증가합니다.

또한 각진 클리닉의 최고 성능으로 로컬 테스트를 위해 사용할 수 있습니다 ng serve --prod

— 할레이 오자
소스
6

Angular CLI를 사용하는 경우 프로젝트를 만들 때 항상 --minimal 플래그를 사용할 수 있습니다 

ng new name --minimal

방금 플래그로 실행했으며 24600 파일을 만들고 ng build --prod212KB dist 폴더를 생성합니다.

프로젝트에 분수가 필요하지 않거나 무언가를 빨리 테스트하고 싶다면 꽤 유용하다고 생각합니다.

— 세 볼렌
소스
5

최근에 각도 cli를 사용하여 새 프로젝트를 만들고 node_modules 폴더가 270MB이므로 그렇습니다. 그러나 각도 세계에 대한 대부분의 새로운 개발자는 이것이 확실하며 유효합니다. 간단한 새 프로젝트의 경우 종속성을 조금씩 낮추는 것이 합리적입니다.) 모든 패키지가 무엇에 의존하는지 알지 못하는 것은 특히 처음으로 클리프를 시도하는 새로운 개발자에게 다소 방해가 될 수 있습니다. 대부분의 기본 자습서에서는 내 보낸 파일 만 필요한 배치 설정에 대해 설명하지 않습니다. 나는 각도 공식 웹 사이트에서 제공되는 자습서조차도 간단한 프로젝트를 배포하는 방법에 대해 이야기한다고 생각하지 않습니다.

node_modules 폴더가 범인처럼 보입니다.

— 마가이
소스
4

다음은 각도 프로젝트에서 더 많은 공간을 차지하는 것을 비교 한 것입니다. 여기에 이미지 설명을 입력하십시오

— 자가 데샤 NH
소스
3

파일 시스템이 심볼릭 링크를 지원하는 경우 최소한 이러한 파일을 모두 숨겨진 폴더로 전달할 수 있으므로 스마트 도구와 같은 스마트 도구 tree는 기본적으로 표시되지 않습니다.

mv node_modules .blergyblerp && ln -s .blergyblerp node_modules

이를 위해 숨겨진 폴더를 사용하면 파일이 개정 관리에 저장하거나 배포에서 직접 사용할 필요가없는 빌드 관련 중간 파일이라는 것을 이해하는 데 도움이 될 수 있습니다.

— 노바
소스
내 이동 경로가 사라 부패가 있지만 여기가 의미있는 작업은 다음과 같습니다 web.archive.org/web/20150216184318/https://docs.npmjs.com/misc/...
— nobar
2

아무 문제가 없다. 이들은 package.json에서 언급 한 모든 노드 종속성입니다.

git hub 프로젝트 중 일부를 다운로드 한 경우 조심하십시오 .angular 2 first hello world 앱에는 실제로 필요하지 않은 다른 종속성이 많이있을 수 있습니다 :)

  • 각도 의존성이 있는지 확인하십시오 -rxjs -gulp -typescript -tslint -docker
— 피유 안 웨카
소스
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.