Сценарий: сегодня полдень понедельника, вы только что получили запрос от нового клиента исправить явную ошибку JS на их производственном сайте, но ваш бюрократический мачете еще не прошел через дебри бюрократии достаточно далеко, чтобы увидеть набор рабочей среды разработки. вверх. Вы знаете, что на внедрение этого исправления уйдет всего час, если у вас будет необходимый доступ, вы знаете, действительно коснитесь дефектного кода. Если бы только разработка была такой же простой, как и просто разработка, не так ли?
Хорошо, возможно, ваша ситуация не так драматична, как вышеупомянутая, но вам все равно нужно решение, которое позволяет загружать действующий сайт и настраивать отдельные ресурсы, будь то скрипты или стили. Если вы похожи на меня, то вам нравится возиться с изменениями и видеть их прямые результаты, а не ждать, пока код стабилизируется, построит, протестирует, развернет и т. Д. Инструменты разработки помогут вам так далеко, но не так ли? было бы здорово, если бы вы могли редактировать определенные файлы на своем локальном компьютере и сразу же просматривать их в контексте действующего производственного сайта, не беспокоясь о том, что все в процессе сломается?
Что ж, это ваш счастливый день, потому что я собираюсь показать вам, как использовать удивительный прокси-сервер Browsersync и функции перезаписи правил для редактирования действующего сайта, как будто это локальная среда разработки! В этом примере мы будем настраивать домашнюю страницу Википедии, хотя я использовал это в прошлом, чтобы быстро работать над реализациями AEM, которые иногда бывает трудно получить надлежащий доступ для разработки, особенно для фронтенд-разработки.
Во-первых, нам нужно создать новый проект на нашей локальной машине разработки. Я создам свой в «~ / Sites / wikipedia». Оттуда мы создадим подкаталог под названием «assets» для размещения наших пользовательских файлов JS и CSS. Затем перейдите в корень вашего проекта («~ / Sites / wikipedia») и инициализируйте новый пакет NPM. Мы будем устанавливать некоторые модули Node, и это самый простой способ сохранить нашу конфигурацию. Используйте приведенные ниже команды, чтобы настроить пакет и установить нужную нам зависимость Browsersync. Поскольку мы не планируем публиковать этот модуль Node, детали приглашения «npm init» не важны. Позже вы можете вернуться и заполнить оставшуюся часть сгенерированного файла package.json, если вы хотите создать полный проект, но это не является целью данной статьи.
cd ~/Sites/wikipedia npm init npm install --save browser-sync
Затем мы создадим файл Browsersync, который будет запускаться Node для создания локального сервера Browsersync, который проксирует активный сайт и заменяет любые локальные ресурсы, которые мы хотим. Создайте новый файл с именем «bs.js» в корне проекта. Нам нужно будет включить только что установленный нами пакет Browsersync. Затем мы вызовем модуль browserSync и прокси-сервер Wikipedia:
С помощью этого кода мы можем запустить наш сервер Browsersync, который будет отображать Wikipedia.org с нашего локального хоста на порту 3000. Из корня проекта запустите команду 'node bs', и в окне браузера откроется 'https: // localhost : 3000 ', отображающий веб-сайт Википедии. Вы даже можете получить доступ к панели управления Browsersync через порт 3001, здорово!
Однако на самом деле мы хотим обслуживать локальные ресурсы вместо их удаленных аналогов на серверах Википедии. Для этого нам нужно добавить еще несколько строк кода в наш файл «bs.js».
Если вы проверите страницу по адресу https: // localhost: 3000 и откроете вкладку сети, вы можете отфильтровать все файлы JS. Мы собираемся изменить JS-файл главной страницы, который называется примерно так: index - ####. Js. Откройте этот файл в Chrome и скопируйте его содержимое в файл на вашем локальном компьютере разработки под названием /assets/js/index.js. Вы заметите, что Википедия разумно уменьшила этот файл, но мы предполагаем, что если вы будете использовать этот процесс на своем собственном сайте, у вас будет доступ к неминифицированной версии кода.
Теперь, когда у нас есть локальный JS-файл, мы можем указать Browsersync обслуживать его вместо удаленного файла, используя правила перезаписи. Добавьте следующие параметры конфигурации в bs.js:
Массив files содержит список локальных путей для Browsersync для отслеживания изменений файлов, чтобы он мог автоматически обновлять сайт по адресу http: // localhost: 3000 по мере разработки! Массив serveStatic содержит список локальных путей для обслуживания на http: // localhost: 3000 с использованием промежуточного программного обеспечения. Если запрос соответствует файлу в одном из этих путей, Browsersync будет обслуживать его, в противном случае он перенаправит запрос на проксируемый действующий сайт. Это то, что позволяет нам смешивать локальные активы с удаленными активами.
Массив rewriteRules содержит список правил для замены определенных текстовых строк. Мы будем использовать его для замены URL-адреса удаленного JS-файла на адрес нашего локального. Обязательно измените регулярное выражение, чтобы оно соответствовало пути удаленного файла, который вы хотите заменить.
Теперь, когда мы настроили наш сервер Browsersync для замены index-6adef12f4f.js нашим локальным файлом index.js, мы можем перезапустить сервер Browsersync с помощью «node bs». Поскольку мы скопировали содержимое удаленного JS-файла в наш локальный JS-файл, все должно работать так же, как и раньше. Однако теперь мы можем редактировать локальный JS-файл и видеть обновления, которые будут применяться к действующему сайту. Попробуйте, добавив "console.log (" Hello world! ");" Вверху index.js. Обратите внимание, что Browsersync обнаруживает изменение и автоматически перезагружает страницу браузера с обновленным кодом! Для определенных типов ресурсов, таких как CSS или изображения, Browsersync внесет изменения вместо перезагрузки страницы, что очень удобно, если вы, скажем, стилизуете модальное окно или 5-ю страницу формы.
Итак, у вас есть: используя этот метод, мы можем заменить любой удаленный ресурс локальной версией, добавив дополнительные правила перезаписи в наш файл конфигурации Browsersync. Мы даже можем использовать эти настройки в более сложной конфигурации Browsersync + Gulp, которая может выполнять еще больше задач, таких как компиляция Sass и добавление автопрефиксов и исходных карт. Ознакомьтесь с Рецептами Browsersync, чтобы узнать, как можно добавить дополнительные задачи.
Особая благодарность Флорану Вершельде, который создал суть, показывающую, как реализовать этот метод.
