В этой статье рассказывается о приключении при обновлении проекта 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 меняет правила игры. Цель заключалась в том, чтобы облегчить работу с кодовой базой для других разработчиков. Кроме того, мы доказали, что можно разумно модернизировать вашу систему, даже если ваша кодовая база ужасна.
Переписывать все приложение - это катастрофа, потому что вы потенциально тратите годы тяжелой работы. Вместо этого постарайтесь сделать свою кодовую базу более читаемой, поддерживаемой и модульной. Когда старый код требует рефакторинга, вы можете делать это шаг за шагом.
Не зацикливайтесь на своей старой кодовой базе и не говорите, что ничего не можете с ней сделать. Попробуйте внести изменения самостоятельно - живите с новыми вещами, новыми обновлениями и новыми технологиями, которые сделают вас счастливыми.
Я пишу для людей впервые! Если вам понравилась эта статья, поделитесь ею с другими людьми вокруг вас.