Величезна кількість файлів, створених для кожного кутового проекту


594

Я хотів запустити просту світову програму привіт для Angular.

Коли я дотримувався вказівок на офіційному швидкому запуску, установка створила 32 000 файлів у моєму проекті.

Я подумав, що це якась помилка або я щось пропустив, тому вирішив використовувати angular-cli , але після налаштування проекту я нарахував 41 000 файлів.

Де я помилився? Невже я пропускаю щось справді очевидне?


98
Це нормально для проектів, що працюють на базі NPM.
Everettss

115
@hendrix тому, що моє розгортання (двигун додатків google) дозволяє лише 10К файлів
Моше Шахам

49
Для всіх, хто цікавиться кількістю голосів за це питання та його відповідями, це зробило головну сторінку НН. news.ycombinator.com/item?id=12209028
ceejayoz

50
@hendrix - Я сподіваюся, що ви також зобов'язуєтеся .DS_Store файли також git.
Мартін Конечний

61
Я думаю, що "якщо ваш привіт світовий додаток працює, все добре", це не найкраща філософія, особливо для того, хто навчається. ОП цілком правильно запитує, чому так багато файлів створено. Сам приклад посилається лише на 5 файлів. І якщо чесно, будь-яка програма, яка має більше файлів, ніж букв на виході, має поставити під сумнів.
Шон

Відповіді:


362

У вашій конфігурації немає нічого поганого.

Кутова (починаючи з версії 2.0) використовує npm-модулі та залежності для розробки. Це єдина причина, коли ви бачите таку величезну кількість файлів.

Основна установка Angular містить транспілятор, типізація залежностей, яка має важливе значення лише для розробки.

Після того, як ви закінчите розробку, все, що вам потрібно буде зробити, - це поєднати цю програму.

Після комплектування програми буде лише один bundle.jsфайл, який ви зможете потім розгорнути на своєму сервері.

"Транспілер" - це лише компілятор, дякуючи @omninonsense за додавання цього.


7
Він, як правило, приносить дані тестів та тести та створює інструменти для залежностей та їх залежностей тощо.
Бенджамін Груенбаум

63
"Транспілер" - це лише компілятор.
omninonsense

31
але компілюється на іншу мову замість байт-коду чи машинного коду
Hunter McMillen

32
@HunterMcMillen байт-код та / або машинний код - інша мова. Термін "транспілер" не має додаткового значення, ніж "компілятор".
Брендон Бак

76
Що стосується всіх причетних, я не впевнений, що аргумент семантики дійсно стосується питання ОП ^^
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

[ див. це для процесу з’єднання ⇗ ]


24
Напевно -3, дали за те, що не зробили суму, але зараз я маю :)
Анкіт Сінгх

1
що ви маєте на увазі під реальними файлами світу?
агаман

1
@yeahman "Файли реального світу" - це кількість файлів під час розгортання проекту або у виробництві .
Маарті

Також кількість розмірів, всього 3 файли, але вони можуть бути величезними (для Інтернету)
pdem

51

З конфігурацією вашої розробки немає нічого поганого .

У вашій виробничій конфігурації щось не так .

Коли ви розробляєте "Кутовий проект 2" або "Будь-який проект, який базується на JS", ви можете використовувати всі файли, ви можете спробувати всі файли, ви можете імпортувати всі файли. Але якщо ви хочете обслуговувати цей проект, вам потрібно ОБ'ЄДНАТИ всі структуровані файли та позбутися непотрібних файлів.

Існує маса варіантів комбінування цих файлів разом:


2
Ви не повинні (потрібне цитування) об'єднувати файли разом на сервері. Щонайбільше, я б використовував транспілер.
Комора Ден

1
@DanPantry Transpilers - це компілятори від джерела до джерела. Я думаю, що вони можуть змінити лише "X" на "JS". Кількість файлів однакова.
ураган

1
.. Так, але я не впевнений у вашій точці. Моя думка, ви, мабуть, не повинні намагатися мінімізувати код сервера (шляхом об'єднання файлів і зменшення розміру файлу). Щонайбільше, ви повинні використовувати Babel у своєму коді, якщо ви використовуєте такі функції кровотечі, як асинхронізація / очікування.
Dan Pantry

2
@DanPantry Я згоден з вами. Але на коментарі опитувальник каже, "оскільки мій розгортання (двигун програми Google) дозволяє лише 10 К файлів". У цих умовах нам потрібно мінімізувати кількість файлів.
ураган

4
Я погоджуся з вами, але, здається, у ОП є проблема 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 1. *, оскільки воно мінімізує накладні витрати для кожного запиту Http. У вас є лише запит на ваш index.html та кожен пакет, але не для 100 - 200 файлів. На даний момент це шлях.

Http 2, з іншого боку, намагається мінімізувати накладні витрати Http, тому він заснований на протоколі потоку. Цей потік здатний спілкуватися в обох напрямках (Клієнт <--> Сервер), і тому причиною цього є більш розумна завантаження ресурсів (Ви завантажуєте лише потрібні файли). Потік усуває велику частину натхнення Http (Менше Http туристів).

Але це те саме, що і з IPv6: Мине кілька років, поки люди дійсно використовуватимуть Http 2


1
Однак це не потрібно, оскільки згадується про використання програми, angular-cliяка вже постачається з пакетом (той самий запропонований веб-пакет).
mattarau

2
@mdentinho Так, у більш сучасних випусках. Але в 2016 році SystemJS та CLI - це саме шлях (радісно, ​​що зараз у нас webpack)
swaechter

21

Вам потрібно переконатися, що ви просто розгортаєте папку dist (скорочується для розповсюдження) зі свого проекту, породженого Angular CLI . Це дозволяє інструменту приймати ваш вихідний код та його залежність та надавати лише те, що вам потрібно для запуску програми.

Як було сказано, існує / була проблема з кутовим CLI щодо виробничих нарощувань за допомогою `ng build --prod

Вчора (2 серпня 2016 року) було здійснено випуск, який переключив механізм збирання з броколі + systemjs на webpack, який успішно обробляє нарощування виробництва.

На основі цих кроків:

ng new test-project
ng build --prod

Я бачу distпапку розміром 1,1 Мб у 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

Примітка. Для встановлення версії кутового кліпу для веб-упаковки необхідно запустити ...npm install angular-cli@webpack -g



12

Схоже, ніхто не згадував попередню компіляцію, як описано тут: https://angular.io/docs/ts/latest/cookbook/aot-compiler.html

Мій досвід роботи з Angular до цих пір полягає в тому, що AoT створює найменші склади майже без часу завантаження. І найголовніше, що стосується питання - вам потрібно лише доставити кілька файлів до виробництва.

Це, мабуть, тому, що кутовий компілятор не буде поставлений із складаннями виробництва, оскільки шаблони складаються "Попереду часу". Також дуже здорово бачити, як розмітка вашого шаблону HTML трансформується в інструкції javascript, які дуже важко повернути інженеру в оригінальний HTML.

Я створив просте відео, де демонструю розмір завантаження, кількість файлів тощо для програми Angular у складі dev vs AoT - яку ви можете побачити тут:

https://youtu.be/ZoZDCgQwnmQ

Тут ви знайдете вихідний код демо-версії:

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

І - як тут говорили всі інші - нічого поганого немає у вашому середовищі розробки. Ось як це відбувається з усіма залежностями, що поставляються з Angular та багатьма іншими сучасними рамками. Але різниця тут полягає в тому, що при доставці на виробництво ви повинні мати можливість упакувати його в кілька файлів. Крім того, ви не хочете, щоб усі ці файли залежностей були у вашому сховищі git.


8

Це насправді не кутовий характер, це трапляється практично з будь-яким проектом, який використовує екосистему NodeJs / npm для своїх інструментів.

Ці проекти знаходяться у ваших папках node_modules і є транзитними залежностями, для яких потрібні ваші прямі залежності.

Модулі екосистем у вузлі зазвичай малі, це означає, що замість того, щоб самі розвивати речі, ми прагнемо імпортувати більшу частину того, що нам потрібно під формою модуля. Сюди можна віднести такі дрібні речі, як знаменита функція лівої панелі, навіщо писати її самі, якщо не як вправу?

Отже, маючи багато файлів - це насправді гарна річ, це означає, що все дуже модульно, і автори модулів часто використовують інші модулі. Така простота модульності є, мабуть, однією з головних причин, чому екосистема вузла росла так швидко.

У принципі це не повинно викликати жодних проблем, але, здається, ви натрапили на обмеження кількості файлів двигуна програми Google. У такому випадку я пропоную не завантажувати node_modules в двигун додатків.

натомість будуйте додаток локально та завантажуйте в механізм додатків google лише пакетні файлиn, але не вбудований у сам движок додатків.


8

Якщо ви використовуєте нову версію кутового кліпу, використовуйте ng build --prod

Це створить dist папку, у якій буде менше файлів, і швидкість проекту збільшиться.

Також для тестування в локальних з найкращими характеристиками кутових кліпів, які ви можете використовувати ng serve --prod


6

якщо ви використовуєте Angular CLI, ви завжди можете використовувати - мінімальний прапор під час створення проекту

ng new name --minimal

Я тільки що запустив його з прапором, і він створює 24 600 файлів і ng build --prodстворює папку dist 212 KB

Тож якщо у вашому проекті вам не потрібні фонтани з водою або ви просто хочете швидко щось випробувати, я думаю, що це дуже корисно


5

Нещодавно створення нового проекту з кутовим кліпом та папкою node_modules склало 270 мб, так, так, це нормально, але я впевнений, що більшість нових розробників для кутового світу ставлять під сумнів це і справедливо. Для простого нового проекту було б доцільно трохи зменшити залежність;) Не знаючи, від чого залежать усі пакунки, це може бути трохи непосильним, особливо для нових розробників, які спершу випробовують кліп. Додайте до того, що більшість основних навчальних посібників не обговорюють налаштування розгортання, щоб отримати лише необхідні експортовані файли. Я не вірю, що навіть підручник, запропонований на офіційному веб-сайті, розповідає про те, як розгорнути простий проект.

Схоже, винуватцем є папка node_modules



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, у нього можуть бути багато інших залежностей, які насправді не потрібні для першого кутового додатка 2-го рівня привіт :)

  • переконайтеся, що у вас є кутові залежності -rxjs -gulp -typescript -tslint -docker
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.