Обновляем Angular до 6-ой версии в проекте без использования CLI

[supersmeh]

А какие такие изменения, привнесенные в 6-ю версию, заставили вас на него перейти?
Мы вот до сих пор на 4.4 сидим и вроде всё устраивает…

[kovalevsky]

установка пакетов через ng add, которая без «открой X, вставить туда строчку Y»
ng update, который вас практически избавит от ручного обновления пакетов
RxJS 6.0 и улучшенный tree-shaking
Анимации без полифоллов
Компоненты без ангуляра (например, чтоб шерить их между основным сайтом и лендингом на WP)

это как минимум

[LionSoft]

Компоненты без ангуляра (например, чтоб шерить их между основным сайтом и лендингом на WP)

А можно об этом поподробнее? Или ссылку скиньте, плз.

[kovalevsky]

Там не совсем без ангуляра, там идея упаковки компонента со всеми его зависимостями в нативный web component.

Я говорю об Angular Elements, angular.io/guide/elements.
Оно ещё очень сырое, но нас подходит, мы начнем готовить некоторые элементы как раз под описанный выше случай.
Более-менее production-ready это всё будет уже к 7 релизу.

[Sumbad]

Основных мотиваций для обновления было две:
1. Хотелось ускорить сборку проекта. Уже давно следим за новостями по Webpack 4. В этом видео Sean Larkin рассказывает подробнее. Angular 6 по-умолчанию использует Webpack 4 поэтому решили обновлять совместно. В итоге сейчас проект стал собираться на 40 секунд быстрее (думаю можно будет еще ускорить, но уже приятно).
2. С каждым обновлением команда Angular вносит ряд изменений в фреймворк, которые требуют переработки компонентов. Если затягивать с обновлением, то потом придется менять слишком много кода. Даже в update.angular.io если указать переход через несколько мажорных версии они напишут предупреждение:

Warning: We do not recommend moving across multiple major versions.

[serf]

Angular 6 по-умолчанию использует Webpack 4

Angular CLI, самому Angular Webpack без надобности.

[Sumbad]

Говоря Angular 6 я подразумеваю экосистему Angular — это и rxjs внутри него и CLI и все остальное необходимое для получения конечного приложения, способного запуститься в браузере пользователя. Если рассматривать экосистему Angular 6 то по-умолчанию (здесь можно трактовать по-умолчанию=Angular CLI) в ней используется Webpack 4. Хотя, конечно, Angular 6 можно попробовать собрать Webpack 3 и даже rollup.js :)

[kemsky]

Если не используете какие-то специфичные фичи angular-cli, то может быть выгоднее самим написать сборку, а вместо uglify (которым и жмет вебпак) можно использовать google closure compiler, многопоточный, на джаве.

[Sumbad]

Наш первый конфиг в общем то это и делал, но это опасный путь) Есть высокая степень вероятности, что при очередном обновлении проект не запустится т.к. разработчики Angular добавили новый «аспект», который учитывается в @ngtools/webpack а вот в ts-loader или awesome-typescript-loader его ещё нужно правильно обработать. По поводу uglify, знаю, что внутри CLI при сборке он тоже используется, про google closure compiler ничего сказать не могу, не использовал.

[supersmeh]

«dependencies»: {
"@angular/common": «4.4.6»,
"@angular/compiler": «4.4.6»,
"@angular/core": «4.4.6»,
"@angular/forms": «4.4.6»,
"@angular/http": «4.4.6»,
"@angular/platform-browser": «4.4.6»,
"@angular/platform-browser-dynamic": «4.4.6»,
"@angular/animations": «4.4.6»,
"@angular/router": «4.4.6»,
"@angular/compiler-cli": «4.4.6»,
«angular-in-memory-web-api»: «0.5.1»,
«bootstrap»: «3.3.7»,
«core-js»: «2.5.1»,
«eonasdan-bootstrap-datetimepicker»: «4.17.47»,
«font-awesome»: «4.7.0»,
«ie-shim»: «0.1.0»,
«moment»: «2.15.1»,
«reflect-metadata»: "^0.1.10",
«rxjs»: «5.5.2»,
«zone.js»: «0.8.18»,
«aspnet-prerendering»: «2.0.3»,
«aspnet-webpack»: «2.0.1»,
«file-saver»: «1.3.3»,
«d3»: «4.7.4»
},

[justboris]

Очень интересно, как у вас работал старый конфиг вебпака вот с этой строкой

transpileOnly: !process.env.NODE_ENV === 'production'

Порядок операций такой, что это эквивалентно: false === 'production', то есть всегда false.

Радует, что в финальной версии конфига этой строки уже нет :)

[Sumbad]

Да, точно, спасибо поправил :)
Это в ходе экспериментов так выключал/включал дополнительные проверки в попытках ускорить сборку, а обратно для статьи поменять забыл.

[devpreview]

@ngtools/webpack работает и с Webpack 3, в моём случае приложение, обновлённое до Angular 6, прекрасно собиралось с Webpack 3. А из-за того что изначально использовался @ngtools/webpack (ещё с беты), каких-то проблем по переходу с Angular 5 на Angular 6 я не увидел.

А вот новый SplitChunksPlugin пришлось осознавать довольно долго.

[serf]

каких-то проблем по переходу с Angular 5 на Angular 6 я не увидел.

Потому что проблем нет, тоже без CLI обновлялся, по сути только небольшиме изменения связанные RxJS потребовались и они выполнялись автоматически скриптом предоставленным самой же RxJS командой.

[MooooM]

Спасибо за пост. Сам хотел нечто подобное описать, т.к. был очень схожий болезненный опыт перехода, но на 5ую версию. Проект также работал без CLI и был довольно увесистый.

Мы решили, что наиболее правильным решением будет перейти на CLI, и несмотря на огромное количество убитого времени (неделя боли и страданий) проект стал работать через CLI и даже с AOT компиляцией. Правда это стало последним каплей и следующие проекты мы делали уже на другом фреймворке...

[serf]

Неделя времени не так и много учитывая что у CLI много преимуществ в случае работы в команде и над долгосрочным проектом. Хотя он и кривоватый местами, и не дает возможность пост-конфигурирования вебпак конфига.

[serf]

В свое время просто сделал eject конфига из Angular CLI, выбросил то что не нужно было и таким образом без CLI живу с 4й версии. С выходом новой версии повторял процесс, это муторно на самом деле, но зато понятнее что они там понаделали с вебпаком. Но это для простого опенсорс проекта, в случае работы в команде и в компании выбрал бы CLI конечно.

[serf]

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

[serf]

В некоторых случаях нужна возможность влиять на процесс сборки (кастомизировать вебпак конфиг). Кроме этого CLI тянет много зависимостей не всегда нужных и навязывает некоторые вещи не всегда удобные. Но по хорошему лучше изначально все так проектировать чтобы CLI было достаточно.