В этой статье рассказывается о приключении при обновлении проекта AngularJS с Grunt до Webpack.

Первое, что пришло в голову, это рефакторинг всего приложения для использования webpack, модулей, babel и es6. После исследования можно сделать это без какого-либо рефакторинга кодовой базы. Но перед добавлением веб-пакета в проект необходимо решить множество проблем.

Проблемы, которые следует рассмотреть перед началом работы

  • Как решить проблему объекта окна, потому что webpack показывает файлы в виде дерева файлов, которые разговаривают друг с другом.
  • Как внести меньше изменений в проект без проблем слияния.
  • Как разделить разработку и производство.
  • Как удалить зависимости bower.
  • Как обновление до webpack решает проблему большого размера файлов JavaScript.

Начни разбивать вещи на шаги

Обновите версию узла с 0.10 до последней доступной версии

Перед тем, как перейти к использованию webpack, необходимо обновить Node.js. Но Grunt использует старую версию node.js и множество устаревших вещей.

Во-первых, на старом grunt-sass & node-sass возникла ошибка. Эта версия Node. Чтобы исправить это, grunt-sass обновляется с «0.18.1» до «2.0.0», а затем node-sass обновляется до «4.7.2».

Во-вторых, попытка обновить grunt с «0.4.5» до «1.0.0» не сработала, потому что подключаемым модулям grunt требуется [email protected] как одноранговая зависимость. Так что застрял с версией 0.4.5.

Удалить устаревшие вещи

  • Атрибут отладки из grunt-express, потому что он устарел в новой версии инспектора узлов.
  • Удалите из проекта задачу bower-install.

Начните с добавления веб-пакета

Я добавил в проект webpack, используя npm install webpack--save-dev. Затем я добавил файл webpack.config.json.

Когда я начал этот шаг, я застрял, потому что в структуре проекта нет точки входа. Весь проект зависит от одного источника - окна. Webpack нужна точка входа для начала и точка выхода в конце.

Чтобы решить эту проблему, я создал точку входа. Я установил на него все необходимые файлы и назвал его таким же именем в конфигурации GruntJS, чтобы объединить его, как это делала старая сборка. Но на это потребовалось много времени, потому что в index.html было включено около 550 элементов.

Чтобы решить эту проблему, я использовал RegExp /”(.*?)"/ig и заменил значения на require(src), чтобы получить источники из атрибута src и преобразовать его в require(src).. Я вставил его в entry.js в том же порядке, что и старый index.html.

После этого в результате получился значительный JS-файл, содержащий все скрипты. Но ничего не вышло! После изучения происходящего выяснилось, что webpack по умолчанию работает как модули. Если в том же файле есть экспорт или экспорт по умолчанию, ничего не будет экспортировано вовне, даже если вы включите его с помощью require js.

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

Добавив это в webpack.config.js, все файлы стали доступны как старое поведение!

И теперь все заработало.

Следующий шаг

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

Чтобы это произошло, я создаю новый файл с именем inject-HTML.files.json.. Этот файл содержит все исходные файлы для использования с usemenPrepare в Grunt и webpack для создания записей в виде нескольких элементов в виде массивов, взятых из файлов Inject-HTML JSON.

Обновите старый файл конфигурации Grunt

Добавить файлы в concat

Проверьте, собирается ли Webpack, затем удалите JS из конфигураций.

Добавить новый скрипт npm

Файл Webpack.config.js

Файл Webpack.prod.js

Мотивации

Ремонтопригодность и качество кода

  • Решите проблему с созданием файлов, так как проект быстро растет.
  • Решите проблему, что к окну без причины прикреплено слишком много вещей.
  • Сделайте кодовую базу более понятной.

Эффективность развития

  • Bower устарела.
  • Нельзя использовать какие-либо вещи в пакетах npm, потому что процесс сборки этого не обеспечивает.

Представление

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

Разделение кода

  • После использования разбиение кода веб-пакета станет проще.
  • Разделите новые функции на модули.

Наконец, использование пакетов npm меняет правила игры. Цель заключалась в том, чтобы облегчить работу с кодовой базой для других разработчиков. Кроме того, мы доказали, что можно разумно модернизировать вашу систему, даже если ваша кодовая база ужасна.

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

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

Я пишу для людей впервые! Если вам понравилась эта статья, поделитесь ею с другими людьми вокруг вас.