[javascript] Angular 프로젝트마다 생성되는 엄청난 수의 파일



Answers

                                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

[ 번들 프로세스 & nbsp; ]

Question

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

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

나는 이것이 실수라고 생각했거나 뭔가를 놓쳤다. 그래서 나는 angular-cli 를 사용하기로 결정했다. 그러나 프로젝트를 세운 후에 나는 41,000 개의 파일을 세었다.

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




여러 사람이 이미 언급했듯이 : node_modules 디렉토리의 모든 파일 (패키지의 NPM 위치)은 프로젝트 종속성의 일부분입니다 (직접 종속성이라고 함). 그것에 덧붙여서, 여러분의 의존성은 그들 자신의 의존성 등을 가질 수 있습니다 (이를테면 전이 의존성이라고 부릅니다). 수십만 개의 파일은 특별한 것이 아닙니다.

10'000 개의 파일 만 업로드 할 수 있으므로 (의견보기), 나는 번들러 엔진을 사용할 것입니다. 이 엔진은 모든 자바 스크립트, CSS, HTML 등을 묶어서 하나의 묶음을 만듭니다. index.html이이 번들을로드하면됩니다.

나는 webpack을 좋아하기 때문에 webpack 솔루션은 애플리케이션 번들과 벤더 번들을 생성 할 것이다. (전체 작동 애플리케이션은 https://github.com/swaechter/project-collection/tree/master/web-angular2-example ) :

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, compiling, minification 등)
  • 배포 용 파일 3 개 -> 몇 Http 요청 만

단점 :

  • 빌드 시간 증가
  • 가장 좋은 해결책은 Http 2 프로젝트에 해당하지 않습니다 (면책 조항 참조).

면책 조항 : 이것은 Http 1에 대한 좋은 해결책입니다. 왜냐하면 각 Http 요청에 대한 오버 헤드를 최소화하기 때문입니다. index.html 및 각 번들에 대한 요청 만 있지만 100 - 200 개 파일에 대한 요청은 아닙니다. 현재이 방법이 있습니다.

반면에 HTTP2는 HTTP 오버 헤드를 최소화하려고하므로 스트림 프로토콜을 기반으로합니다. 이 스트림은 양방향 (클라이언트 <-> 서버)으로 통신 할 수 있으며 더 지능적인 리소스로드가 가능하다는 이유로 (필요한 파일 만로드합니다). 스트림은 Http 오버 헤드 (HTTP 라운드 트립 감소)의 대부분을 제거합니다.

하지만 IPv6와 동일합니다. 사람들이 실제로 Http 2를 사용할 때까지 몇 년이 걸립니다.




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

git hub 프로젝트의 일부를 다운로드했다면, 각도 2의 첫 번째 hello world app에 실제로 필요하지 않은 다른 의존성이 많이있을 수 있습니다.

  • 각 의존성이 있는지 확인하십시오. -rxjs -gulp -typescript -tslint -docker



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

ng new name --minimal

방금 플래그로 실행했고 ng build --prod 개의 파일을 만들고 ng build --prod 는 212 KB dist 폴더를 생성합니다.

그래서 프로젝트에서 물 샘이 필요하지 않거나 빠르게 테스트 해보고 싶다면 꽤 유용하다고 생각합니다.




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

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

노드에서 생태계 모듈은 일반적으로 작습니다. 즉, 스스로를 개발하는 대신 우리가 필요한 것을 모듈 형태로 가져 오는 경향이 있습니다. 여기에는 유명한 왼쪽 패드 기능과 같은 작은 것들이 포함될 수 있습니다. 왜 운동이 아니라면 스스로 쓰십시오?

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

원칙적으로 이것은 어떤 문제도 발생해서는 안되지만 Google 앱 엔진 파일 개수 제한에 부합하는 것으로 보입니다. 그 경우에는 node_modules을 앱 엔진에 업로드하지 않는 것이 좋습니다.

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







Related