Musings and Solutions for SharePoint, O365, and Azure

2007 2010 2013 2016 ALM Development Javascript Language SharePoint Online SharePoint Version TypeScript

Conquer your dev toolchain in ‘Classic’ SharePoint – Part 4

January 16, 2018

Conquer your dev toolchain in ‘Classic’ SharePoint – Part 4

This entry is part 4 of 4 in the series Conquer your dev toolchain in 'Classic' SharePoint

For this last post I want to take what we’ve learned and add the final pieces that have you creating web parts in the same way you would modern SPFx web parts and solutions. We’re going to start by discussing TypeScript and then briefly touch on Sass and how to include these languages into your new Webpack/Gulp environment.

TypeScript is becoming almost ubiquitous in modern web development. The pros are numerous, my favorites are the ability to write code to target older browser with modern capabilities, and the ability to use a version of intellisense to validate your objects properties and methods. In my experience both of these features makes development go faster. The cons are that you’ll need to transpile your code as well as utilize typings for the libraries you want to include. By using Visual Studio Code, or another IDE as your development environment TypeScript is pretty much built in. If you are coming from C#, or some other compiled language, you’re going to find that you feel significantly more comfortable writing TypeScript than JavaScript, mainly because many of the conventions you’re used to have an equivalent in the TypeScript language and thus patterns like MVVM are easily implemented.

As I’ve mentioned in many of my other posts I tend to use AngularJS as my development framework of choice simply because it works well and supports dynamic binding which is needed for web part development. That’s changing with the introduction of Web Components and Angular 5’s – Angular Elements but at this moment that’s super cutting edge and I’m not going to address it.

If you are interested in Angular Elements check out both Andrew Connell’s post (Solve the SharePoint Framework + Angular Challenge with Angular 5.0 Elements) and Sébastien Levert’s series (SHAREPOINT FRAMEWORK & ANGULAR ELEMENTS : BUILDING YOUR FIRST WEB PART)

All that said that doesn’t mean AngularJS has to be the framework you choose, or that you need to choose a framework at all. All it means is that I’m going to show an example below of how I add the typings for spinning up an AngularJS project. If you’re interested in some good reading and further links around the framework wars you might check out Angular, React or Vue – Which Web Framework to Focus on for SPFx? where Andrew Connell gives you a lot of resources to help you learn about the different frameworks, and some good advice…. Try before you ‘buy’!

TypeScript

Enough introduction, on to the actual process. First we’re going to update our package.json file by adding TypeScript. Now if you’re using a tool like WebStorm they provide a “bundled” version of TypeScript (Visual Studio Code provides language support but not the transpiler, you will need to add it as I describe). Again, per my discussions in the previous posts I have run into version incompatibility issues and so I’ve taken to including my own version and not installing it globally or relying on the bundled version. You should choose what works for you but if you’re going to pick your version then you need to add it to you devDependencies section of your package.json.

typescript Provides typescript processing

In addition, I need to add the typings for my third-party libraries. Typings are the “intellisense” for your code. They allow the transpiler to check that you’ve correctly utilized the various properties and methods your referencing before it actually “builds” it. The “cool” way to add typings to your project is to use the @types pattern, you can look up your favorites in NPM. Here I’m adding the typing for AngularJS to my dependencies.

@types/angular Provides typescript support for AngularJS

We also need to add Webpack support for our TypeScript files. So, we’ll add the following:

ts-loader This is the typescript loader for webpack.

Then we’ll modify our webpack.config.js file to reference and use ts-loader. Note other modifications to support our switch to TypeScript including changing our entry file, adding ts-loader to our modules section, and the addition of the “resolve” section which helps Webpack configure how modules are resolved. By including extensions section we’re telling Webpack to automatically resolve files with these extensions.

Now if I run an “npm i” all these dependencies will be loaded into my node_modules folder, and I can start my “npm build” process to start transpiling and webpacking my TypeScript based solution.

SASS/SCSS

Sass stands for “Syntactically Awesome Style Sheets” and its file extension is scss. Once I tried Sass I’ve never looked back as it makes those things that you should be able to do in stylesheets easy by providing features like variables, nesting, partials, inheritance, and operators. If you’ve never tried it check out the Sass site for some easy getting started snippets. To include Sass files in your project you need to include a few modules to help Webpack out.

node-sass A dependency of sass-loader that must be manually included.
sass-loader Compiles the scss file into a css file so that webpack and include it in the bundle.

And then to our modules section of the webpack.config.js we need to add a rule for our scss files which is basically the same rules as css files but with the sass processor first (or last, processors work from last to first.. so the file will go through the sass-loader, then the css-loader, then the style-loader).

And Beyond

There are so many other things we could add to our chain at this point. Linters, testing frameworks, etc, etc but this series covers what we at Sympraxis do at a minimum for our projects that reside in classic SharePoint. I really hope you’ve enjoyed reading them and if you have any questions please feel free to leave a comment below. If you’re interested, you can download the complete files that I’ve discussed in my series from my GitHub repo under the “Development Toolchain” folder.

Happy Coding!

Series Navigation<< Conquer your dev toolchain in ‘Classic’ SharePoint – Part 3

    Julie has been building software on primarily the Microsoft platform for over 20 years. With a degree in Electrical Engineering specializing in microprocessor system design from Worcester Polytechnic Institute she came at software initially from a very low level but quickly realized a love and aptitude for developing rich user experiences and solutions. She worked her way up through internal IT ranks reaching a Director of IT position before realizing more impact could be made in consulting and really focused in on the SharePoint platform in 2007. Since then her focus has been on the SharePoint platform, Office 365, Azure, and client side development. She's the co-author of the Widget Wrangler JavaScript library and continues to try and help innovate SharePoint and Office 365 solutions for her clients. She is a 2017 recipient of the Microsoft MVP award for Office Servers and Services.


    Leave a comment

    Leave a Reply

    %d bloggers like this: