Preparing development machine for client-side SharePoint projects (Mac and PC)

This article is created and could be helpful for those who are planning to develop client-side SharePoint solutions using up-to-date tool sets

Let’s prepare our shiny new and naked development machine from scratch. We’re going to use package managers because they are the thing.

Initial installation is slightly different on OS X and Windows but the subsequent process of development and capabilities are the same.

Soft to install

We need the following tools:

  • Visual Studio Code – for ninja text editing
  • Chrome – if your developer position is in any way connected with the word “web” use this guy, there is nothing better than Chrome Dev Tools then you need to debug or tweak JS or CSS in browser
  • Node.js – it’s an engine and a heart of development workflow automation
  • Git client – for source control operations
  • Cmder – splendid console emulator [for Windows] (Cmd could be used as well or Terminal on Mac OS)

Windows

Chocolatey

On a PC we’ll get the sugar out of Chocolatey, it’s a package manager for windows.

Chocolatey installation is as easy as run one-line command in CMD (run as administrator for sure):

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

Packages

Here are the benefits, to install all the soft you need it enough to run this (as administrator):

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

Now relax and take your favorite drink. Coffee in my case. =)

OS X

Homebrew

In a Mac world, Homebrew is responsible for the same stuff, it extends App Store, as its authors say “missing package manager”.

One-line command again in Terminal:

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

Packages

Time saver is:

brew install node git  

Unfortunately, there is no formula for Visual Studio Code or Chrome in Homebrew. Chrome could be installed via App Store. VSC has to be downloaded and installed manually, yet all of this won't take much time.

Node environment

Now we’re are ready to check the environment by requesting a version for node and its package manager (yeah, one more package manager, this one is used very often) and, of course, Git.

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

This should return Node.js version, NPM version, then Git version each after another. Commands are combined together and could be split up.

Also, a good point is to check if the VSC is added to Path environment variable. The best option to check if is to navigate somewhere in your file system in the Console/Terminal and type (there should be a space between “code” and “dot”):

code .  

VSC should run with a current folder, where we were in a console, opened.

Before you will be able to use NPM modules, project should be initiated by:

npm init -y  

This will create package.json in your project folder. Package.json is a definition of the project.

Node modules

There is a variety of node modules. You can find thousands of them on NPM site.

Some of the modules could be good, some of them not. So always check the author and community behind the module. As Node application is capable of anything on your machine double check before trust forever.

If you came from .Net world, NPM modules are just like NuGets but for the Node.js.

Modules can be installed globally and locally in the specific project.

Global modules

Global module installation example:

npm install gulp -g  

Flag -g corresponds to “global”, without it installed module will be placed inside node_modules folder inside your project.

Modules that are better to install globally as they going to be used a lot in our projects are:

  • gulp – will automate your developer’s routine
  • bower – yet… oh, yet another package manager we need, this one delivers libraries which are used in a browser (such stuff as React, jQuery, Bootstrap, Knockout, well, all your favorite browser libraries)
  • yeoman – is a scaffolding tool for creating projects start point
  • eslint – is a brilliant static code analyzer for JS
  • … let’s stop on that right now, don’t install too many modules until there is clear understanding why a specific module is needed OK, so these can be installed with:
npm install gulp bower yo eslint -g  

Local modules

Local modules are a part of your project, dependencies with easily delivering, updating, restoring, that make you reuse community’s efforts and abstract your application.

On most SharePoint assets or let’s say it UI development projects, you can benefit from:

  • gulp – you might say “Stop it’s already installed globally”, but it also is needed locally (global installation allows to run “gulp [task]” in a console, but local installation makes it’s possible to use “require(‘gulp’)” in a code and define automation tasks)
  • spsave or gulp-spsave – allow to publish files from local folders to SharePoint document libraries, so there is no need to deploy assets manually
  • sppull – is responsible for downloading existing files from SharePoint programmatically to your project, so you can ensure easily if the project's assets files were changed somehow and have any differences with the Git HEAD using Git Diff algorithm
  • … any other modules depending on the tasks Before going next, a few words about local modules installation save options.

By installing something like:

npm install sppull  

A module and all its dependencies will be downloaded to node_modules and you will be able to require it in the code, but one thing, if your project is in Git repository you might and should want to exclude modules folder from being stored in your repo.

But it’s weird to remember all the references then you clone a project from a remote Git repo, that’s why --save flag should be used.

So a dependency module installation looks like:

npm install sp-request --save-dev  

--save-dev adds a module to development dependencies, --save – to production dependencies. The difference is following: --save-dev is applied when a module is used while code creation (it is the support libraries, all that gulp-* libs, sppull, spsave, they help to do stuff when you coding, but they are not included in the project app or dist assets that will be running in SharePoint). For SharePoint UI projects you likely won’t need any npm modules to save in prod.

If npm modules were installed with save option later on after cloning or pulling the project, you will need to run “npm install” and all the references will be downloaded and applied automatically.

Bower modules

Bower modules concepts and commands are very similar to NPM, the difference is that it manages browsers libraries. I’m not going to stop on Bower for long. Let’s check the command:

bower install jquery#1.4.1 --save  

Isn’t it identical? In the case of jQuery I’m fetching a specific version I need, otherwise, the latest will be downloaded.

Git

Hey, folks! You know a lot about Git, don’t you? ;)

Final steps

  1. Create a project in Git (GitHub, BitBucket, Visual Studio Online, no matter)
  2. git clone [yourprojecturl]
  3. Navigate to your project directory
  4. NPM init/install:
    • npm init -y – in the case if it is a new blank project
    • npm install – in the case of cloning already initiated project from Git code .
  5. ... and, with VSC and console opened, you are ready to rock-n-roll

Next time there will be a lot of code and config’s, I’ll describe project setup for instant publishing to SharePoint and fetching and merging files back from running instance. Hope all of this makes sense. Stay tuned. And welcome to the comment section below.