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

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

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

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

Я говорю об Angular Elements, angular.io/guide/elements.
Оно ещё очень сырое, но нас подходит, мы начнем готовить некоторые элементы как раз под описанный выше случай.
Более-менее production-ready это всё будет уже к 7 релизу.
Основных мотиваций для обновления было две:
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.
Angular 6 по-умолчанию использует Webpack 4

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

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

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

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


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

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


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

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

А вот новый SplitChunksPlugin пришлось осознавать довольно долго.
каких-то проблем по переходу с Angular 5 на Angular 6 я не увидел.

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

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


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

Неделя времени не так и много учитывая что у CLI много преимуществ в случае работы в команде и над долгосрочным проектом. Хотя он и кривоватый местами, и не дает возможность пост-конфигурирования вебпак конфига.
В свое время просто сделал eject конфига из Angular CLI, выбросил то что не нужно было и таким образом без CLI живу с 4й версии. С выходом новой версии повторял процесс, это муторно на самом деле, но зато понятнее что они там понаделали с вебпаком. Но это для простого опенсорс проекта, в случае работы в команде и в компании выбрал бы CLI конечно.
НЛО прилетело и опубликовало эту надпись здесь
Простота вебпак конфига для проекта который не требует много фарша.
НЛО прилетело и опубликовало эту надпись здесь
В некоторых случаях нужна возможность влиять на процесс сборки (кастомизировать вебпак конфиг). Кроме этого CLI тянет много зависимостей не всегда нужных и навязывает некоторые вещи не всегда удобные. Но по хорошему лучше изначально все так проектировать чтобы CLI было достаточно.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.