Modern SharePoint Developer tooling stack

Intro

A lot of the SharePoint developers, in recent days, are switching from usual dev tools and workflows to something new, more universal and cross-platform. Please recall anything you have seen in modern MS-related video tutorials, how often have you seen OS X on a host’s machine? The answer is likely to be “Very often”.

Soon you might probably forget about using legacy SharePoint Designer and Visual Studio for most cases. Of course, there will be always a place for Visual Studio, especially for code base provisioning and provided-hosted .Net stuff (no one has invented something better than SPMeta2, for example), but I can’t even recall when did I need to open SPD or VS for my daily development routine.

At the same time, due to my job, I have to write tons of code for SharePoint almost each day. And I prefer to avoid manual routines and automate my work as much as possible. The ideal scenario is “when I press Ctrl+S or Ctrl+B in my editor of choice I want to see changes immediately in a Dev environment”, you could add to this “immediate static code analysis and transpiling” and also “Git-connected-first approach”.

Yeah, I’m talking about front end part mostly. But not all the way, 20-30% is still something that I have to deploy on a server side, but this server side is actually a client side for SharePoint itself. So why don’t use the same Development tools stack for both too? Luckily it’s possible.

Now we’re switching to tooling of my choice.

Stack & tools

Languages

As most of you have already understood, I’m going to mention JavaScript here. It’s not only ES5. Sometimes it can be ES2015 and Babel or TypeScript as a nice tool to avoid tons of issues, enhance your code and more.

I’m not even mentioning frameworks, it’s out of this topic. Just will say, yes you should definitely take advantage of frameworks that are your friends.

If there is a lot of styling in the project it reasonable to take advantages of stylesheet meta languages, I prefer Sass with Scss syntax.

Source control

I am confident that you all agree with me on this, Git is the best. I used TFVS before and will never go back.

Editors

When code editors are discussed everyone has his or her own preference. I will strongly recommend taking a look at Visual Studio Code or VSC for short. It is lightning fast, has OOTB Git integration, really cool debugger (for a server-side JS) and with most of the plugins support. Alternatively, ATOM is great, but I use VSC for more than a year in my day to day work. It is awesome and its awesomeness is growing with each release. VSC team evolves their product nicely, I can’t say about some other MS products. ;)

Static code analysis

This one is must have for any project and team and… well… any coder in almost any situation. Yeah, really. I can’t bear without ESLint when writing JS (even with a compiler inside the brain, static analysis is the thing!) and TSLint in a case of TypeScript. Also, a good thing is to deploy linting tools globally to all team members. Just remember, it saves time and nervous.

It’s nice to have a linting tool as a plugin in an editor and also as a part of build process step.

Automated tasks

I can’t see myself doing any project larger to tiny without the automated tasks in the background and on-demand. Gulp is a great choice for almost any case. Watching, linting, combining, uglifying, automated tests, publishing - all the stuff. If you are not familiar with Gulp and want to minimize your manual work I would recommend taking a look at it.

Some might prefer Webpack or Grunt. No problem they are also the great tools. My choice is Gulp as it is code over config and it has modules to work with SharePoint.

To achieve instant publishing, I use gulp watch and gulp-spsave module, which allows delivering local project files right to the SharePoint assets library with publish state and feeding the metadata, when needed.

Testing

I’m not very good in testing but came to the understanding that automated testing is necessary, especially on the long-running projects. Right now I’m trying to implement unit testing on Mocha and the UI testing with use of Nightwatch (which uses Selenium drivers and written in JS) on some projects. Testing is a separate story as it’s not about tooling. One thing, if you have tests they definitely should be a part of your build process as a tool saving your time tremendously.

Package managers

NPM for Node.js and Bower for browser libraries. I do not know what to add, they are straightforward and easy. Just use it! And never ever spend your time to go to vendor site to find, download and place a library to your project. Seriously, one line in a console and almost any library is delivered to your project.

Cross library references are also viable here. Especially when you have your private commercial super-duper library inside your private repo. Yet, it’s easy to reference to a library within the package using git+[your_private_git_repo_url]#version.

Node.js

Oh, Node.js, it is outstanding and is a baseline for the tasks automation, package managers, most of the plugins and it’s opening the eyes to the fact that JS lives not only in the browser but also on the server or even a desktop application. Did you know that VSC is made using JS? But this is a completely different story.

Conclusion

So we came to the end of the article.

Tools are very important. Sometimes how we do something could be at the first place over what we do. Right tools and techniques save our time, help to resolve potential issues.

In the world of SharePoint is also possible to use all that nice and shiny tools which are used in modern JavaScript world. As SharePoint is very close saying that JS is a number one technology for its customization. And we are the part of it.

Let’s combine: Git <---> VSC + Node.js + Gulp --> SharePoint = happy coding!