SharePoint Framework – Part 6 (How the tool chain works)

Please read previous posts if you want to know about Development toolchain comparison.

The first thing you do if you gona build a new SharePoint Framework Web Part is you install SharePoint Generator.

Using Yeoman – your yeoman template get scaffold complete projects or useful parts and then go and build your custom solution using Visual studio code or whatever editor you choose to use.

Once you have done that – you get to play with a really cool new feature that we call the Workbench.

You will be able to build your Web Part and test it locally on your DEV machine.

So if you are familiar with SharePoint Development today – this is always been a bit of a pain. Either needed to be tailored, need to be have access to the servers, you needed to upload something. Microsoft realize that the lot of the development effort needs to be local and then deployed.

And so this gives you the edibility. You can build your client side web part, test it out locally using this work bench (Or we can say local emulator of SharePoint), you can have some data in there.

You can play with it and you can do bunch of round trips until you get your web part the way you want it and then deploy it.

Using gulp deploy and get your web part up into the servers.

There are really two parts of this point.

You get a package that could be deployed as an App to the app catalog. You are doing – loading a manifest, deploying so bunch of js files sitting in your CDN.

You do not worry about uploading the solution again, just update your javascript files and upload into CDN. You are done with the changes.

This is how the tool chain works while we are building or developing a SharePoint Framework Client Side Web Part.

 

In next post I will explain bit on how the client-side web part build flow look a like