Question: Correct way to deploy solutions depending on library component solution

[diabhoil]

What type of issue is this?

Question

What SharePoint development model, framework, SDK or API is this about?

💥 SharePoint Framework

Target SharePoint environment

SharePoint Online

What browser(s) / client(s) have you tested

• [ ] 💥 Internet Explorer
• [ ] 💥 Microsoft Edge
• [ ] 💥 Google Chrome
• [ ] 💥 FireFox
• [ ] 💥 Safari
• [ ] mobile (iOS/iPadOS)
• [ ] mobile (Android)
• [ ] not applicable
• [ ] other (enter in the "Additional environment details" area below)

Additional environment details

Question for all browsers and all SPFx versions

Issue description

Its not an issue, its a question: What is the right way to deploy solutions. We have several solutions with webparts and one solution with an library component to share some code.

When we update one solution and the library component solution we often have the problem that the webparts wont load anymore:

The issue is that some new (added in the newest version) function in the library component solution is not found. When I look in the console/source explorer I can see, that the library component is an older version. Its maybe loaded from another solution on the page, which we didnt update.

Do we have to update all solutions which depend on the library component solution if the library is deployed in a new version? Even if we didnt change "existing" code in the library and just added newer code? Where does the "old" library code come from when we replaced it to a new version in the tenant app catalog?

[Amey-MSFT]

Hello @diabhoil, Thank you for bringing this issue to our attention. We will look into it and get back to you shortly. If you don’t receive a reply within two working days, please use this escalation form to escalate.

[diabhoil]

I was digging a bit deeper. When the aspx loads it contains a "spClientSidePageContext" Object, which holds a huge array of manifests. This array contains 2 entries for my library component. And one of these is the old version, leading to the old JS file.

So my question is: how do we ensure, that there is only one instance of the solution in this manifest array? Why there are two? Where do they come from and how can we manage the deployment process correctly.

[Ashlesha-MSFT]

@diabhoil, I came across https://www.eliostruyf.com/important-version-sync-library-component-sharepoint-framework/ which answers the question. The reason you are seeing two entries for the same library component inside the spClientSidePageContext.manifests array is because multiple SPFx solutions installed on the site are embedding different versions of the same library component.

• Why two manifests appear

Each SPFx solution that depends on a library component includes the library’s manifest inside its own .sppkg package at build time. So when:

• The library component is updated (v2.0.0)
• But some dependent solutions are still using the older version (v1.0.0)

The page loads both:

1. The NEW library manifest from the updated library package
2. The OLD library manifest still embedded in other solutions This creates two manifest entries, and the runtime sometimes picks the older version, which is why the webparts fail to load.

• How to ensure only one manifest entry

To ensure only one version of the library is loaded: Every SPFx solution that depends on the library must be rebuilt and redeployed whenever the library component version changes. This keeps all consuming solutions in sync and removes the old embedded manifest from the page.