The SharePoint Framework is a complicated beast, and there are a multitude of concepts that this relatively new developer has been struggling to understand.

I’m getting there though!

Here are links to all of the posts in this series:

Just create a library and reference it in all your projects yo!

.NET developers will all be familiar with the simplicity of writing a .dll file within C#, and simply referencing that assembly within any required project (gross generalisations notwithstanding).

Developers in all major languages and frameworks enjoy the same freedoms in 2019, Right? Right???

I began scratching the surface, and boy was I surprised…

Shared Libraries aren’t supported within the SharePoint Framework - wait, what???

This next section is slightly out of date now. SPFx 1.8 introduced Library components which is great, but there are still glaring issues; the functionality is in preview as at May 10th 2019, and you can only have a single component - let’s continue then shall we?

Once you’ve spent a few months within the SharePoint Framework you’ll no doubt become familiar with what I have; there’s no supported way to share your code between multiple projects (yet).

You’ll have:

  • Multiple projects.
  • Multiple copies of similar code implementations, be they utility functions, service wrappers for the various SharePoint APIs, or SharePoint Search query builders.
  • Projects with near identical utility functionality that really should be shared.

There are many people much smarter than I am, that much is obvious. Some have even blogged about this very topic of course, but from the perspective of a Production solution, I’ve found what I’ve been reading to be either:

  • Overly generalised for production use and unacceptable for our clients:

    So take my word for it, add all your SPFx components to a single package and create multi-component bundles

    Our clients pay only for specific component bundles. Bundling them all together opens us up to having to contractually support a component they’ve not paid for, but have managed to access through potential user error.

  • Or working perfectly albeit not officially supported:

    The feature should be coming shortly. No public ETA has been shared but it shouldn’t take much longer.

I’ve used up a huge amount of my product development time this month on this topic, and have learned a lot from the multitude of articles I’ve read through, including the ones previously linked.

The holy grail?

I very much doubt it, but I am very happy with what I’ve implemented.

We now have a simple shared TypeScript library project that is built using Azure Pipelines CI and published to an Azure Artifacts feed. Configuring the feed with upstream sources enabled me to use that feed as an npm Registry replacement.

We can simply npm install project_name@latest and access the private shared code project including typings directly, along with all of the other lovely npm functionality that comes with an implementation such as this.

The solution works very well for our needs and has allowed us to build a shared code project that has been deployed independently of our production SPFx Web Part and Extension projects.

Has there been any tangible benefit from this exercise?

Absolutely! Though I am not sure that this approach will work for everyones’ use case.

With this decoupling comes much better code re-use and complete separation of concerns from the consuming projects. This separation has been at the behest of ease of debugging though - I’m still trying to figure out how best to handle this outside of Unit Testing.

This was a long process and there are many steps that, I’m sure you can tell, have not even been mentioned in this post. Check back for new posts where I will go into detail about how this was implemented, configured within Azure DevOps CI to build and publish the project package, and consumed within our SPFx projects…

Want to read more? Clicky -> Why? - SPFx projects and Shared Libraries - part deux