Горячее обновление скриптов в SharePoint

Разработчики SharePoint все больше привыкают в современным подходам клиентской разработки. Сама front-end разработка для SharePoint превращается в некий гибрид использования Visual Studio Code, Gulp задач и инструментов разработки Chrome (Dev Tools + Workspaces).

Все больше подходов и инструментов из "хипстерской тусовки" оседают как профессиональные средства, без которых сам процесс кодинга кажется уже невозможным. Однако, всегда есть что-то, чего не хватает для полноты картины. Чтобы хотелось видеть после того, как в редакторе кода нажимется "Ctrl+S"? Правильно, чтобы изменение было сразу отображено на живой странице портала. Возможно кто-то скажет - "А как же BrowserSync (это модуль, позволяющий динамически отслеживать изменения в локальных исходниках и обновлять страницу отладки)?". "А Вы пробовали его подружить с SharePoint?", отвечу я.

В SharePoint есть ряд специфических нюансов, которые не позволят BrowserSync предоставить все, что хотелось бы. К счастью, теперь есть альтернатива.

Не так давно я обернул используемый нашей командой подход в библиотеку, оформленную в виде подключаемого NPM модуля - sp-live-reload.

С помощью sp-live-reload возможно сохранять локально редктируемые файлы front-end проекта, такие как javascript, css, html (источник для CEWP), apsx (например, layout без серверного кода), masterpage и сразу полсле сохранения видеть применившиеся измеенния в браузере без необходимости вручную перезагружать страницу:

SP Live Reload

Для подключения библиотеки в Node.js проект необходимо выполнить в консоли:

npm install sp-live-reload --save-dev

После чего, возможно будет создать и запустить Gulp задачу, как описано в документации к проекту.

Мы используем горячее обновление в комбинации с SPSave, модулем, позволяющем загружать/публиковать файлы проекта непосредственно в библиотеки "ассетов" SharePoint (например, /_catalogs/masterpage/namespace). Так же можно использовать sp-live-reload в связке с альтернативами принцип один и тот же.

var gulp = require('gulp');
var spsave = require("gulp-spsave");
var watch = require('gulp-watch');
var through = require('through2');
var LiveReload = require('sp-live-reload');

var config = require('./gulp.config');

gulp.task("watch-assets", function () {
    console.log("Отслеживание изменений...");
    console.log("Убедитесь в том, что на странице развернут скрипт мониторинга.");
    var liveReload = new LiveReload(config);
    liveReload.runServer();
    return watch(config.watchAssets, function (event) {
        console.log(event.path);
        gulp.src(event.path, {
            base: config.watchBase
        }).pipe(spsave(config.spsaveCoreOptions, config.spsaveCreds))
        .pipe(through.obj(function (chunk, enc, cb) {
            var chunkPath = chunk.path;
            liveReload.emitUpdatedPath(chunkPath);
            cb(null, chunk);
        }));
    });
});

Обозначу соображение, из которых мы исходим, предоставляя решение:

  • Горячее обновление это для разработки и только для сред разработки, ни в коем случае не для Production-сред
  • При работе нескольких разработчиков на одной среде (SPSite) потенципльно могут быть конфликты, которые нужно обходить в зависимости от схемы совместной работы
  • Должны поддерживаться все основные браузеры

Наш подход в реализации горячего обновления следующий:

  • Скрипт мониторинга изменений может быть развернут в SharePoint двумя способами:
    • Ручной (или точечный) непосредственно на страницу, где производится отладка
    • Глобальный (custom action в рамках SPSite) - на всех страницах узла
  • Скрипт мониторинга обращается к локально запускаемому серверу на машине разработчика, который отправляет информацию об обновленных ресурсах сразу после их доставки в SharePoint
  • Для глобального развертывания можно использовать Gulp задачи по развертыванию и удалению сustom action, глобальное развертывание целесообразно, если в SPSite работает продолжительное время единственный разработчик, но могут быть и исключения
  • Когда с одинм SPSite работают 2 и более разработчика скрипт мониторинга провизится только в одном экземпляре, при этом на всех машинах разработки должны быть одинаковые настройки URL и порта сервера
  • Для обновления скрипт мониторинга учитывает только ресурсы, присутствующие на открытой страницы, изменение ассетов, не задействованных на странице игнорируется

Пару слов об архитектуре реализации. Клиент и сервер мониторинга используют сокетные соединения предоставляемые Socket.io для транспорта сообщений в реальном времени. Все браузеры, поддерживающие Socket.io и SharePoint автоматически поддерживаются sp-live-reload. Сервер мониторинга изменений запускается в рамках задачи Gulp по отслеживанию ресурсов для публикации. Может быть не обязательно Gulp, но дня него есть поддержка "из коробки". При изменении, сразу после публикации измененного файла, сервер транслирует сообщение с путем до файла. Клиент мониторинга получает все сообщения от сервера и, в зависимости от наличия данных ресурсов на странице, производит перезагрузку страницы или самих ресурсов (как в случае с css - обновление происходит без необходимости перезагрузки). Клиент учитывает особенности SHarePoint, перезагрузку вызывают не только обновления скриптов, но и HTML, которые могут быть источником содержимого CEWP веб-частей, а так же ASPX с шаблонами отображения страниц публикации (layouts) или же используемая главная страница (masterpage).

Горячее обновление работает как с On-Premises установками SharePoint (2016 и 2013), так и SharePoint Online. В случае с SharePoint Online есть пара нюансов: во-первых, работа через HTTPS - необходимо запускать локальный сервер тоже на HTTPS, для этого немного нужно один раз повозиться с сертификатами, во-вторых, готовьтесь, что SharePoint Online медленный как черепаха! =)

sp-live-reload так же интегрирован в generator-sppp, Вы можете попробовать его в действии с минимальными усилиями, развернув стартовый проект из генератора.


Опубликовано: 15.12.2016
Автор: Андрей Кольтяков