Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?

Разработчики 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, Вы можете попробовать его в действии с минимальными усилиями, развернув стартовый проект из генератора.

PnP JS Core - заслуживает ли внимания?

Довольно длительное время мы игнорировали PnP-JS-Core и предпочитали старый добрый JSOM или REST запросы с помощью jQuery.ajax или SP.RequestExecutor. "Зачем использовать дополнительные обертки над API, которые могут быть дополнительным узлом в отказоустойчивости решения?", вот такой вопрос лично я задавал сам себе и откладывал знакомство с PnP-JS-Core.

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

Что же это такое?

PnP-JS-Core является одним из проектов "Office 365 Developer Patterns and Practices" (инфраструктура проектов с отрытым исходным кодом Microsoft и сообщества с библиотеками, примерами и документации) для работы SharePoint с помощью JavaScript.

По сути дела, библиотека представляет собой обертку SharePoint REST API и набор "хелперов". PnP JS Core предоставляет fluent-подход по формированию обращений к REST методам, облегчая процесс разработки.

Стек и проект

Реализация библиотеки выполнена с использованием полюбившимися подходами и инструментарием: TypeScript, Gulp, NPM, Typings, Git, Serve... все, что так знакомо и привычно. Довольно просто разобраться в структуре проекта, логике и даже, по необходимости, расширить возможности по своим требованиям.

Разбираться в исходниках, впрочем, совсем не обязательно, но часто проще разобраться с задачей, глядя в код или примеры. В итоге, разобраться с PnP-JS-Core и начать ее использовать не составляет большого труда.

Использование

Установить PnP-JS-Core можно как с помощью NPM/YARN так и Bower. Библиотека может быть использована, как в составе проекта на TypeScript, так и для непосредственного подключения на странице с использованием в Valila JavaScript.

PnP-JS-Core использует протокол fetch и ES6 "промисы" (promises), поэтому для того, чтобы добавить поддержку аутсайдерам браузеров (я про IE), необходимо не забыть загрузить "полифилы" (polyfills) на страницу. Если упастить это из виду, проигнорировав упоминание в документации, то можно удивится, "что же в IE-то ничего не работает?", что это еще за сообщения в консоли "'Headers' is undefined?"”. Но, спокойно, с добавленными es-promise и fetch polyfills, библиотека отлично работает в IE и Edge.

Синтаксис

PnP-JS-Core использует базовый объект pnp (если используется подключение через импорт в TypeScript) и $pnp (если добавлять pnp.js в виде ссылки на странице для написания пода на чистом JS, например, в консоли или сниппетах).

REST запросы с использованием PnP строятся с использованием "флюент" (fluent) API цепочки-построители/хелперы с инициацией "промиса" запроса в конце выражения.

Например, для построения обращения к REST интерфейсу /_api/web/lists/getByTitle('Мой список')/items на PnP необходимо написать следующий под:

$pnp.sp.web 
  .lists.getByTitle('Мой список').items 
  .get() 
  .then(function(items) { 
    // результаты запроса в массиве `items`
  });

$pnp.sp.web.lists.getByTitle('Мой список').items – данный конструктор построить обращение, аналогичное вышеупомянутому URI.

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

Я все же крайне рекомендую четко представлять структуру REST API SharePoint и планировать получение преимуществ от использования PnP только после, либо совмещать библиотеку и понимание, что она выполняет на фоне.

После того, как составлена цепочка обращения к API, необходимо использовать метод get, который инициирует обращение запроса на сервер. Метод Get и некоторые другие возвращают "промис", у него необходимо вызывать методы then и catch для обработки результатов выполнения.

"Флюент" API, на самом деле, отличный помощник. Предоставляющий в том числе и параметры запросов, такие как, $select, $filter, $extend, $top и др. в виде "хелперов". Тем не менее, не все REST API обернуто в библиотеку, часто возникают случаи отсутствия, особенно, нововведений.

К примеру, сходу наткнулся на отсутствие возможности получание списка по URL (web.getList('url')), который я считаю единственным правильным способом обращения к спискам и библиотекам. Руки бы отрывать тем, кто для этого использует Display Name или GUID (которые влегкую могут быть либо изменены пользователем, либо меняться от деплоя к деплою). ;) Однако, это не остановило меня от того, чтобы "форкнуть" проект, добавить метод и оформить "пулл реквест". Теперь pnp.sp.web.getList в наличии и можно обращаться к спискам по человечески /_api/web/getlist(‘/sites/site/web/list/name’).

Такие вот преимущества проектов с исходным кодом, которые к тому же и допольно активно развиваются. Как минимум не стоят на месте.

Пакетные запросы

Довольно известный факт, что REST API штука допольно "говорливая". Одним из преимуществ JSOM, например, всегда была возможность сформировать очередь из обращений к серверу и запустить ее одним физическим запросом (executeQueryAsync). Это конечно так. Но знали ли Вы, что в REST так же есть возможность формировать пакетные запросы? Оно конечно есть только SharePoint Online и SharePoint 2016. Однако, /_api/$batch - стоит того.

PnP значительно упрощает использование пакетных запросов. Запросы могут быть добавлены в очередь и вызываться пакетно следующим образом:

var batchResults = [];
var batch = new $pnp.sp.createBatch();
$pnp.sp.web.getList('/sites/dev01/lists/custom01').items.inBatch(batch).get().then(function(d) {
  batchResults.push({ 
    custom01: d 
  });
});
$pnp.sp.web.getList('/sites/dev01/lists/custom02').items.inBatch(batch).get().then(function(d) {
  batchResults.push({ 
    custom02: d 
  });
});
for (var i = 0, len = 10; i < len; i += 1) {
  $pnp.sp.web.getList('/sites/dev01/lists/custom03').inBatch(batch).items.add({ 
    Title: 'Item ' + i 
  });
}
batch.execute().then(function() {
  console.log("All is done!", batchResults);
});

Было очень приятно обнаружить такую простоту и мощь одновременно.

Жаль конечно, что "батчи" в REST отсутствуют в SharePoint 2013, на нем все еще подовляющее большинство проектов.

Заключение

За последние годы вокруг PnP было довольно много шумихи, на удивление, многие, кто ссылается на PnP зачастую понятия не имеют, о чем они говорят, никогда не углубляясь в подробности реализации, а только повторяя PnP как мантру. Особенно это касается провизии в PnP, которая, мягко говоря, ужасна и рядом не стояла с ближайшим конкурентом, но сейчас не об этом.

PnP-JS-Core - это не про провизию, это простая, легкая обертка над REST API, заслуживающая внимания и шанса использования в рабочих проектах. Как минимум, я дам библиотеке шанс, задейстовав PnP-JS-Core на очередном проекте.

UPD:

Попробовал PnP-JS-Core в связке с sp-rest-proxy, что-то даже работает! :)

* Такая связка конечно будет только работать для GET запросов в силу специфики реализациим sp-rest-proxy и pnp.

На одном из недавних вебкастов, посвященных SharePoint Framework, проводимому Rencore (вебинар "SPFx Deep Dive") с Биллом Беером (Bill Baer) в качества ведущего докладчика, было довольно много интересных идей и рекомендаций.

Конечно, формат мероприятия не позволяет раскрыть должным образом всех нюансов и деталей и, по сути дела, основное время уходит на расскрытие обстановки проекта. Данный вебинар не стал исключением и все свелось к история платформы SharePoint, обзор инструментария разработки и демонстрации пары несложных примеров. Однако, были интересные нюансы.

Одна из "крутых фишек" SPFx это возпожность запустить режим "serve" потем задачи Gulp gulp serve, после чего будет запущен локальный сервер с отслеживанием изменений в коде и интерфейсом для локальной отладки workbench. Workbench позволяет в режиме эмуляции новой страницы (Modern Pages) добавлять разрабатываемые веб-части и производить разработку, сразу видя результаты.

Однако, локально запущенные workbench не может работать с данными из SharePoint, для ряда сценарием локальной разработки предлагается генерировать искуственные данные нужной структуры и использовать их для отладки. Такой подход имеет плаво на жизнь, но требует больше времени и не всегда удобен. Как по мне, то работа с живыми тестовыми данными более продуктивна, а иногда и обязательна.

Уверен, что в дальнейшем в фреймворке будет добавлен режим проксирования API SharePoint в рамказ workbench без необходимости публикации решения. В рамках текущих обстоятельств, было бы достаточно REST API.

Почему я так уверен? Да потому что, как только данная идея пришла в голову, как что-то необходимое, я сел с реализацией и за пятничный вечер удалось создать прокси для REST запросов SharePoint API на Node.js и Express, который позволяет со страницы вне домена портала отправлять локально запросы, которые перенаправляются в экземпляр SharePoint.

На такой локальной странице, без какого либо развертывания, можно выполянть GET или POST запросы, как будто бы они были выполнены на странице SharePoint, например, /_api/web/lists вернет данные о перечне списков ~site/_api/web/lists.

GET и POST запрсы, отправляемые на /_api/* транслируются в SharePoint на заданный узел (SPWeb) с использованием заданной схемой авторизации, определяемыми в настройках прокси.

Конечно, подобный способ имеет ряд ограничений, в том числе и используемыми API, только REST (UPD: Недавно была добавлена экспериментальная поддержка SOAP запросов). Реализовать проксирование JSOM, например, может быть уже сложнее (но возможно).

REST в SharePoint все значительнее становится приоритетной технологией программной коммуникации с API. Этому есть все предпосылки: простота, универсальность, кроссплатформенность и независимость от языка программирования.

Созданный проект представляет из себя в большей степени концепт, он свободно доступен на GitHub'е и опубликован в NPM в виде подключаемой библиотеки.

Подготовка компьютера для front-end разработки для проектов SharePoint (для Mac и PC)

Данная статья создана и может быть полезна тем, что планирует разработке front-end решений для SharePoint с использованием современных инструментов разработки

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

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

Установка программного обеспечения

Для разработки нам понадобится следующее ПО:

  • Visual Studio Code – для мастерского редактирования кода
  • Chrome – если в Вашей должности присутствует слово "web" и Вы себя уважаете, то в качестве основных инструментов для отладки веб-решения выступают именно инструменты разработчика Chrome
  • Node.js – основа для локальной автоматизации рутинных действий и рабочего процесса разработки
  • Git клиент – мы же используем Git-репозиторий
  • Cmder – замечательный эмулятор консоли [для Windows] (так же может быть и стандартный Cmd или Terminal если Вы на Mac)

Windows

Chocolatey

На Windows мы воспользуемся пакетным менеджером Chocolatey.

Установка пакетного менеджера может быть выполнена одной лишь строчкой в консоли, которую необходимо запустить из-под администратора:

@powershell -NoProfile -ExecutionPolicy Bypass -Command "iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))" && SET "PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin"

Пакеты

Непосредственная мощь пакетных менеджеров - это простота и автоматизация установки. Не надо ничего качать и запускать мастера-установщики. Достаточно нескольких строк в консоли (из под администратора):

choco install visualstudiocode googlechrome nodejs.install git.install cmder -y

Так мы за один раз запустим установку всего требуемого нам софта.

Можно расслабиться и пойти попить чая. Или, в моем случае, кофе. =)

OS X

Homebrew

В мире OS X слегка по-другому. Часть софта подставится из App Store, что-то придется скачать, а остальные пакеты нам установит Homebrew. Brew - это пакетный менеджер, содержащий в своем репозитории пакеты, отсутствующие в App Store.

Установка, как и в случае Chocolatey тривиальна:

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Пакеты

Сэкономим время на установке Node.js и Git.

brew install node git

Visual Studio Code, к сожалению придется скачать и установить вручную, а Chrome поставить из App Store. Но в целом это так же очень простой процесс.

Окружение Node.js

После выполненных действий желательно убедится в корректности установки и доступности пакетов в командной строке. Проверим версии Node.js, NPM - пакетный менеджер для Node.js (да, еще один пакетный менеджер, но этим придется пользоваться довольно часто) и, конечно же, Git.

node -v && npm -v && git --version

В результате мы должны увидеть версию Node, NPM и Git, одну за другой. Консольная команда объединена в одну строку, но можно и отдельно.

Так же, желательно проверить, что VSC так же добавлена в переменные среды. Проще всего это проверить, выполнив в консоли:

code .

Должен запустить экземпляр VSC с открытой текущей директорией.

Для инициализации проекта Node.js необходимо выполнить:

npm init -y

Данная команда создаст файл-описание проекта (package.json) в текущей папке проекта.

Модули Node

Существует огромное количество модулей для Node. В реестре NPM можно найти тысячи модулей на все случаи жизни.

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

Если у Вы знакомы с .Net, то NPM можно сравнить с NuGet'ами, но только для Node.js.

Модули могут быть установлены глобально и локально в директорию проекта.

Глобальные модули

Пример установки модули глобально:

npm install gulp -g

Флаг -g отвечает за глобальную установки, без него модуль будет установлен в контекст текущего каталога.

Среди модулей, которые потребуется установить глобально, можно отметить следующие:

  • gulp – автоматизирует различные задачи связанные с процессом разработки
  • bower – еще… еще один пакетный менеджер, позволяет управлять зависимостями библиотек, используемых в контексте браузера (такие как React, jQuery, Bootstrap, Knockout, все наши любимые front-end библиотеки)
  • yeoman – генератор структур проектов по шаблонам
  • eslint – замечательный статический анализатор кода
  • … давайте на этом сейчас остановимся. Золотое правило - не устанавливать чрезмерное количество модулей, до тех пор, пока нет понимания какой модуль и для чего нужен как глобально, так и в проекте.

Итак, вышеперечисленные модули можно установить за раз:

npm install gulp bower yo eslint -g

Локальные модули

Локальные модули непосредственно устанавливаются в проект.

Модули с легкостью можно устанавливать, обновлять, восстанавливать из Git проекта. Хороший способ абстрагировать Ваше приложение, внедрив в него функциональность надежного модуля, решающего определенную технологическую или прикладную задачу.

На большинстве SharePoint front-end проектах целесообразно использование следующих модулей:

  • gulp – кто-то возразит "Уже же установлено глобально!", но локальная установка так же необходима (глобальная установка позволяет использовать команду “gulp [task]” в консоли, а локальная установка позволяет ссылаться на gulp библиотеку в коде проекта (“require(‘gulp’)”)
  • spsave или gulp-spsave – позволяют автоматизировать публикацию файлов проекта в SharePoint, исключив необходимость ручного развертывания решения
  • sppull – позволяет скачивать файлы и папки из библиотек SharePoint, сценариев использования может быть несколько, например, обратная синхронизация для проверки отличие состояния решения в SharePoint и в текущей точке проекта с помощью алгоритма Git Diff
  • … любые другие в зависимости от задач автоматизации

Прежде чем продолжить, пара слов об опции сохранения.

Устанавливая модуль следующим образом:

npm install sppull

Сам модуль и все зависимости скачиваются в папку node_modules в рамках проекта и можно будет пользоваться модулями, но, так делать категорически не стоит. Во первых, устанавливаемые модули нет смысла хранить в Git (каталог node_modules обычно исключается из Git). Во вторых, информация о зависимостях все же должна быть частью проекта. При клонировании из Git должна быть возможность легко восстановить зависимости, а так же при необходимости обновить версии зависимостей.

Конечно запоминать, что было установлено в проект не нужно. А при установке необходимо использовать ключ --save.

Установка модуля будет выглядеть:

npm install sp-request --save-dev

Ключ --save-dev добавляет модуль в зависимости проекта в режиме разработки, --save – в зависимости проекта в режиме исполнения. Иными словами, если модуль - часть приложения, то он устанавливается с --save, а если модуль - часть проекта и автоматизирует процесс разработки, то --save-dev.

Для front-end проектов SharePoint, скорее всего, устанавливать модули с ключом --save не потребуется.

В случае, если модули устанавливались с ключами save, то после клонирования проектов, достаточно будет запустить команду npm install, все зависимости будет скачены и установлены автоматически пакетным менеджером.

Bower компоненты

Концепт использования и команды Bower практически идентичны NPM, за тем исключением, что Bower управляет библиотеками, используемыми в браузере.

Не буду заострять особого внимания, давайте рассмотрим команду:

bower install jquery#1.4.1 --save

Правда, тоже самое? В данном случае устанавливается зависимость jQuery с версией 1.4.1, если версию не указать, то скачается последняя. Не всегда это так критично, как в случае с jQuery.

Git

Ведь уже все переехали на Git? Никто не ловит слоупоков? ;)

Подытожим действия

  • Создать проект в Git (GitHub, BitBucket, Visual Studio Online, не принципиально)
  • git clone [url-репозитория]
  • Перейти в папку проекта
  • Инициировать NPM и установить зависимости:
    • npm init -y – в случае нового проекта
    • npm install – в случае клонирования проекта с уже установленными модулями
  • code .
  • ... у нас инициирован проект, открыт редактор, можно начинать кодить решение!

SharePoint front-end разработка из шаблона

Данная статья является продолжением моей предыдущей (Подготовка компьютера для front-end разработки для проектов SharePoint).

Я остановился на моменте, когда на компьютер для front-end разработки было установлено все необходимое программное обеспечение для начала написания кода.

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

Наверное, Вы уже слышали о SharePoint Framework (сокращенно SPFx)? Что команда SPFx предлагает для быстрого развертывания шаблона проекта? Предлагается Yeoman генератор. Возможно многие сейчас возразить по поводу SPFx "Это слишком сложно для моей задачи на текущий момент", "Я пишу под SharePoint On-Premises и Apps у меня не настроены", "Мне нужно только редактировать файлы в активах сайтов" или "У меня такие задачи, что SPFx не поможет" это же только для разработки веб-частей.

Для того, чтобы в "переходный" период можно было начать делать проекты по-новому и не зависеть от нюансов SPFx, а потом и быстрее адаптироваться под него, созданы другие генераторы с альтернативной схемой доставки приложений в SharePoint. Альтернатива, которую я опишу, проще в использовании и уже сейчас позволит освоить и применять Git, VSC (или любой другой редактор), Node.js, задачи автоматизации, причем в очень простом и понятном исполнении. Однако данный переход сейчас может оказаться сверх полезным.

Для развертывания шаблона проекта мы будем использовать SP Pull-n-Push генератор для Yeoman. Данный генератор создает проект из шаблона с задачами для "вытягивания" файлов из SharePoint и публикации обратно в момент сохранения в редакторе.

Если Вы следовали пунктам статьи по подготовке среды, то у Вас уже должен быть установлен Yeoman и другие нужные глобальные модули. Если нет, то вот консольная команда:

npm install -g gulp bower yo 

Теперь давайте установим генератор:

npm install -g generator-sppp

Примечание: SP Pull-n-Push (sppp) - довольно молодой генератор, поэтому замечания по ошибкам и предложения приветствуются на странице GitHub'а.

Стоит не забывать, что при выходе новых версий генераторов, на их необходимо обновлять, если требуется применить обновленный шаблон при инициализации нового проекта. Для обновления генераторов нужно воспользоваться командой yo в консоли и выбрать пункт "Update your generators".

Для создания проекта по шаблону необходимо создать папку (а лучше же клонировать пустой проект из Git) и запустить yo-команду в консоли в директории проекта:

yo sppp [ИмяВашегоПроекта]

После данной команды запустится мастер. В мастере необходимо предоставить параметры приложения и связки проекта со средой разработки SharePoint:

Yeoman SP Pull-n-Push генератор

Все запрашиваемые параметры в дальнейшем могут быть изменены в конфигурационных файлах проекта.

Мастер Yeoman скопирует все нужные файлы и директории и запустит установку NPM и Bower компонент в случае такой необходимости.

В текущей версии генератора представлено 2 задачи автоматизации:

  1. Скачивание файлов из целевой папки "ассетов" SharePoint в локальную папку проекта ("./src").

Данная задача может быть полезна в ряде сценариев. Например, когда нужно изначально скачать все существующие файлы модуля в SharePoint, когда они каким-то образом уже существуют. Можно конечно скопировать вручную, но я, например, слишком ленив для этого. ;)

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

Для скачивания файлов используется задача sppull:

gulp sppull-all

После ее запуска, через какое-то время, файлы из SharePoint будут скачены в проект.

  1. Вторая задача уже для частого использования. На самом деле ее нужно запускать каждый раз перед тем, как вы открыли проект и собираетесь вносить изменения, ожидая моментального применения изменений в SharePoint.
gulp watch-assets

Данная задача запускает мониторинг изменения файлов в "./src" и отправляет изменения в SharePoint. Задача использует gulp-spsave модуль Node.js для публикации файлов.

Проект, созданный с использованием sppp генератора, можно расширить путем конфигурации дополнительных задач и модулей под Ваш проект, а полученный опыт может стать отправной точкой на пути к современной разработке под SharePoint и переходу к SPFx.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.