Огромное количество файлов, сгенерированных для каждого проекта Angular

594

Я хотел запустить простое приложение Hello World для Angular.

Когда я следовал инструкциям в официальном быстром запуске, установка создала 32 000 файлов в моем проекте.

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

Где я неправ? Я что-то упускаю действительно очевидное?

javascript angular Моше Шахам
источник

98

Это нормально для проектов, работающих на NPM.

Эвереттс

115

@hendrix, потому что мое развертывание (механизм приложений Google) позволяет только 10K файлов

Моше Шахам

49

Любой, кто интересуется количеством голосов по этому вопросу и его ответами, сделал первую полосу HN. news.ycombinator.com/item?id=12209028

ceejayoz

50

@hendrix - держу пари, что вы также делаете файлы .DS_Store для git.

Мартин Конечни

61

Я думаю, что «если ваше приложение hello world работает, все в порядке», это плохая философия, которой нужно следовать, особенно для тех, кто учится. ОП точно задает вопрос, почему было создано так много файлов. Сам пример ссылается только на 5 файлов. И, честно говоря, любое приложение, которое имеет больше файлов, чем букв на выходе, должно быть подвергнуто сомнению.

Шон

362

В вашей конфигурации нет ничего плохого.

Angular (начиная с версии 2.0) использует модули npm и зависимости для разработки. Это единственная причина, по которой вы видите такое огромное количество файлов.

Базовая настройка Angular содержит транспортер, зависимости типов, которые необходимы только для разработки.

Когда вы закончите разработку, все, что вам нужно будет сделать, это связать это приложение.

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

'transpiler' - это просто компилятор, спасибо @omninonsense за добавление этого.

Бхушан Гадекар
источник

7

Он также обычно приносит тестовые данные и тесты и инструменты сборки для зависимостей и их зависимостей и так далее.

Бенджамин Грюнбаум

63

«Транспортер» - это просто компилятор.

omninonsense

32

но компилируется на другой язык вместо байтового кода или машинного кода

Хантер МакМиллен

32

@HunterMcMillen Байт-код и / или машинный код - это другой язык. Термин «транспортер» не имеет никакого дополнительного значения, чем «компилятор».

Брэндон Бак

76

Что касается всех участников, я не уверен, что аргумент семантики действительно имеет отношение к вопросу OP ^^

Дэн Пантри

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

В вашей конфигурации разработки нет ничего плохого .

Что-то не так с вашей производственной конфигурацией.

Когда вы разрабатываете «Angular 2 Project» или «Any Project, основанный на JS», вы можете использовать все файлы, вы можете попробовать все файлы, вы можете импортировать все файлы. Но если вы хотите обслуживать этот проект, вам нужно объединить все структурированные файлы и избавиться от ненужных файлов.

Существует множество вариантов объединения этих файлов:

Компрессор YUI
Google Closure Compiler
Для серверной части (я думаю, что это лучше) GULP

ураган
источник

2

Вы не должны (необходима цитата) объединять файлы вместе на сервере. Самое большее, я бы использовал транспортер.

Дэн Кладовая

1

@DanPantry Transpilers - это компиляторы исходного кода. Я думаю, что они могут изменить только «X» на «JS». Количество файлов одинаковое.

ураган

1

Да, но я не уверен в вашей точке зрения. Я хочу сказать, что вам, вероятно, не следует пытаться минимизировать код сервера (путем объединения файлов и, следовательно, уменьшения размера файла). Самое большее, вы должны использовать Babel в своем коде, если вы используете такие функции, как async / await.

Дэн Кладовая

2

@DanPantry Я согласен с вами. Но в комментариях спрашивающий говорит: «потому что мое развертывание (механизм приложений Google) допускает только 10K файлов». В этих условиях нам нужно минимизировать количество файлов.

ураган

4

Я бы с тобой согласился, но у ОП, похоже, тут проблема с XY

Дэн Пантри

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 linting, compiling, minification и т. Д.)
3 файла для развертывания -> только несколько запросов Http

Недостатки:

Более высокое время сборки
Не лучшее решение для проектов Http 2 (см. Заявление об отказе от ответственности)

Отказ от ответственности: Это хорошее решение для Http 1. *, поскольку оно минимизирует накладные расходы для каждого запроса Http. У вас есть запрос только для вашего index.html и каждого пакета, но не для 100-200 файлов. На данный момент это путь.

Http 2, с другой стороны, пытается минимизировать издержки Http, поэтому он основан на потоковом протоколе. Этот поток может обмениваться данными в обоих направлениях (клиент <-> сервер), и по этой причине возможна более интеллектуальная загрузка ресурсов (вы загружаете только необходимые файлы). Поток устраняет большую часть издержек Http (Меньше обходов Http).

Но это то же самое, что и с IPv6: пройдет несколько лет, пока люди действительно будут использовать Http 2

swaechter
источник

1

Однако нет необходимости, поскольку в OP упоминается использование, angular-cliкоторое уже поставляется с пакетом (тот же предложенный веб-пакет).

Маттарау

2

@mdentinho Да, в более современных выпусках. Но в 2016 году SystemJS и CLI были подходом (с радостью у нас теперь есть веб-пакет)

swaechter

21

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

Тем не менее, есть / была проблема с Angular CLI в отношении производственных сборок через `ng build --prod

Вчера (2 августа 2016 г.) был выпущен релиз, который переключил механизм сборки с broccoli + 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

Примечание. В настоящее время для установки веб-пакета angular cli вы должны запустить ...npm install angular-cli@webpack -g

Brocco
источник

14

Сам Angular имеет много зависимостей, а бета-версия CLI загружает в четыре раза больше файлов.

Это как создать простой проект с меньшим количеством файлов («только» 10K файлов) https://yakovfain.com/2016/05/06/starting-an-angular-2-rc-1-project/

Яков Файн
источник

12

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

До сих пор мой опыт работы с Angular заключался в том, что AoT создает самые маленькие сборки практически без времени загрузки. И самое главное, поскольку вопрос здесь о - вам нужно только отправить несколько файлов в производство.

Похоже, это связано с тем, что компилятор Angular не будет поставляться с производственными сборками, поскольку шаблоны компилируются «впереди времени». Также очень здорово видеть, как разметка вашего HTML-шаблона преобразована в инструкции javascript, которые было бы очень трудно преобразовать в исходный HTML-код.

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

https://youtu.be/ZoZDCgQwnmQ

Вы найдете исходный код для демонстрации здесь:

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

И - как все остальные говорили здесь - нет ничего плохого, когда в вашей среде разработки много файлов. Так обстоит дело со всеми зависимостями, входящими в состав Angular и многих других современных сред. Но разница здесь в том, что при доставке в производство вы можете упаковать его в несколько файлов. Также вам не нужны все эти файлы зависимостей в вашем git-репозитории.

Питер Саломонсен
источник

8

На самом деле это не специфично для Angular, это происходит практически с любым проектом, который использует экосистему NodeJs / npm для своего инструментария.

Эти проекты находятся в ваших папках node_modules и являются транзитными зависимостями, которые должны запускать ваши прямые зависимости.

В узле экосистемные модули, как правило, небольшие, что означает, что вместо того, чтобы самим что-то разрабатывать, мы склонны импортировать большую часть того, что нам нужно, в форме модуля. Это может включать такие мелочи, как знаменитая функция левой панели, зачем писать сами, если не в качестве упражнения?

Так что наличие большого количества файлов - это действительно хорошая вещь, это означает, что все очень модульно, и авторы модулей часто используют другие модули. Эта простота модульности, вероятно, является одной из основных причин, почему экосистема узлов росла так быстро.

В принципе, это не должно вызывать каких-либо проблем, но кажется, что вы столкнулись с ограничением числа файлов в движке Google. В этом случае я предлагаю не загружать node_modules в движок приложения.

вместо этого создайте приложение локально и загрузите в механизм приложений Google только связанные файлы, но не добавляйте его в сам механизм приложений.

Угловой университет
источник

8

Если вы используете более новую версию Angular Cli, используйте ng build --prod

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

Также для тестирования в местном масштабе с лучшими характеристиками угловых вы можете использовать ng serve --prod

Джалай Оза
источник

6

если вы используете Angular CLI, вы всегда можете использовать флаг --minimal при создании проекта

ng new name --minimal

Я только что запустил его с флагом, и он создает 24 600 файлов и ng build --prodсоздает папку dist 212 КБ

Так что если вам не нужны фонтаны в вашем проекте или вы просто хотите быстро что-то проверить, я думаю, что это очень полезно

SebOlens
источник

5

Создание нового проекта с angular cli и папкой node_modules было 270 Мб, так что да, это нормально, но я уверен, что большинство новых разработчиков в angular world ставят это под сомнение и действительно. Для простого нового проекта имеет смысл урезать зависимости, может быть, чуть-чуть;) Незнание того, от чего зависят все пакеты, может немного нервировать, особенно для новых разработчиков, которые впервые попробовали отключиться. Добавьте к тому, что в большинстве базовых руководств не обсуждаются параметры развертывания, чтобы получить только необходимые экспортированные файлы. Я не верю, что даже учебник, предлагаемый на официальном официальном сайте, рассказывает о том, как развернуть простой проект.

maguy
источник

4

Вот сравнение того, что занимает больше места в угловых проектах.

Ягадеша Н.Х.
источник

3

Если ваша файловая система поддерживает символические ссылки, вы можете, по крайней мере, переместить все эти файлы в скрытую папку, чтобы умный инструмент, например tree, не отображал их по умолчанию.

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

Использование скрытой папки для этого также может способствовать пониманию того, что это промежуточные файлы, связанные со сборкой, которые не нужно сохранять в системе контроля версий или использовать непосредственно в вашем развертывании.

nobar
источник

Моя крошка пошел несвежий, но вот то , что он относится к: 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

Пиюш Анвекар
источник

Огромное количество файлов, сгенерированных для каждого проекта Angular

Ответы: