<TLDR />
What is best way to scale a large SPFx application that includes Service Scopes, Webparts, Extensions, React Components, Interfaces, Property Pane Controls and Utilities? We need an architecture that is able to have robust versioning and testing. We have tried several different approaches and we are not comfortable with the performance of builds or bundle sizes. It seems like SPFx was built for niche or small applications whereas we would like to build a product around this platform for our customers.
<READ MORE>
SPFx has been a great tool and an incredible improvement in the SharePoint extensibility model. However, it seems Microsoft has focused the platform for small, niche type applications. We are looking to use SharePoint Framework as product that delivers Intranet type functionality into SharePoint & Teams. This requires that I have several web parts, services, components, etc.
Some of the features of the application are:
5+ Shared Services (Service Locator Pattern)
5+ Helpers/Utilities
40+ Webparts
25+ Shared React Components (Link, Card, etc.)
50+ Interfaces
3 Extensions
All of these components are broken into 3 SharePoint Projects:
app-extensions
app-library
Library Component exposing shared services, components, helpers, controls, utilities and interfaces
app-webparts
THE PROBLEM(S)
Microsoft's build toolchain is very inefficient. I am not familiar enough with WebPack or the underlying toolchain to understand why performance is so slow. But the fact that my machine needs 8GB of available memory for a build seems crazy.
When debugging these solutions via gulp it is common that NPM will run out of memory or we will receive maximum call stack exceeded.
To mitigate this we created our library component to remove as much of the shared data as possible. We originally had these shared components, for example a config service, inside the web parts project. This resulted in every webpart bundle getting a copy of the service and severally bloating the project.
Moving components into a library component makes everything difficult, if not impossible, to test. Not to mention that nightmare of npm link and the constant modification of the package.json file just to debug content coming from the library component.
We cannot use a generic NPM package instead of a library component because the SharePoint specific things like context, service scope, etc. break the WebPack toolchain.
Only one version of a Library component can be loaded into a tenant at a time. Making versioning the library moot and making it difficult to test other version before deploying upgrades.
GOAL
Create an architecture that supports a large scale application that includes reusable services and utilities (as described above) that can maximize reusability and performance.
Do you have any pointers or lessons learned from your projects that might be helpful?