Multiple List View Command Sets With Different SPFx Versions

[anthonywhite]

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
• [x] 💥 Microsoft Edge
• [x] 💥 Google Chrome
• [ ] 💥 FireFox
• [ ] 💥 Safari
• [ ] mobile (iOS/iPadOS)
• [ ] mobile (Android)
• [ ] not applicable
• [ ] other (enter in the "Additional environment details" area below)

Additional environment details

• browser version LATEST
• SPFx version 1.13, 1.20
• Node.js version as required (NVM)

Issue description

Two different SPFx solutions deployed to app catalog One built with SPFx 1.13 2nd built with SPFx 1.20 Both deliver List View Command buttons 1.13 buttons appear but 1.20 button does not

Is this a bug or not supported for some reason?

[Amey-MSFT]

Hello @anthonywhite , Thank you for bringing this issue to our attention. We will look into it and get back to you shortly.

[anthonywhite]

Hello @anthonywhite , This is expected behavior due to SPFx versioning differences. When multiple extensions target the same list view, only one command set is loaded—typically the one from the older SPFx version. To resolve this, ensure both solutions are using the same SPFx version, ideally the latest supported.

Reference: Use extensions with SharePoint Framework

Let me if further help is required on the same. Thanks!!

@Amey-MSFT thx for the update, however the document you linked to does not seem to describe the version restriction/behaviour you outlined?

[anthonywhite]

Hello @anthonywhite , While the general guidance on SPFx extensions doesn't explicitly state this versioning interaction, this behavior stems from how SharePoint handles multiple command set extensions targeting the same scope. When multiple command sets are registered for the same list view, SharePoint typically resolves to load a single command set—often the one deployed first or associated with the older framework version, as observed in this case.

@Amey-MSFT I would like more clarity on this (I'm guessing other SPFx users might too) - hence the request for documentation. Does this apply to other customisation types e.g. web parts? What happens if two separate web parts on a page are built with different SPFx versions? And so on with the other types. Given that all SPFx versions ever created (AFAIK) are still supported, and that we don't all have the bandwidth to continually upgrade all our code to the latest SPFx (a forever task with very little business value), this feels like it could be a regular issue for SPFx developers?

Would be interested to hear thoughts from @VesaJuvonen or @andrewconnell too...

[andrewconnell]

@anthonywhite said:

What happens if two separate web parts on a page are built with different SPFx versions?

Each SPFx component's manifest (regardless of whether it's a web part or extension) specifies its dependencies for the SPFx runtime to process. This includes the JS bundle(s) the component needs to run, SPFx libraries needed (ie: @microsoft/sp-http), and other libraries the developer marked as external dependencies.

When the SPFx runtime adds a SPFx component to the page, it uses this manifest to start loading what it needs, including the correct version of the SPFx libraries that the component requires.

This means if you have 2 web parts that use 2 different versions of the SPFx, both versions are loaded in the page.

[anthonywhite]

Thanks @andrewconnell, but this doesn't seem to apply to Command buttons as discussed above?

[andrewconnell]

@anthonywhite said:

... this doesn't seem to apply to Command buttons as discussed above?

Correct... the way it was mentioned above would be news to me. What I said is how I've understood it.

But with that being said, when the Lists team rolled out the new UX, they broke all extensibility as they didn't test any SPFx customizations. As a result, they had to rollback and have been working on addressing things. I (and many others) have challenges keeping up with the status of what they've done. IMHO, it's very frustrating and has been poorly handled by Microsoft. 🤷‍♂️

[anthonywhite]

Wow. I see...very disappointing to hear, thought SPFx was valued.

[andrewconnell]

@anthonywhite said:

thought SPFx was valued

IMHO, I don't think that's fair... It's not exclusive to SPFx... It's complicated...

SPFx, just like Lists, is part of a big organization. IMHO, M365 has had growing pains, not realizing that what they're doing will impact other teams. The same is true vice versa...

It is what it is, and when there's a conflict, it's up to customers & the community to bring it to Microsoft's attention.

FWIW, I could very well be wrong with what I said in my comment, the way it's explained here would be news to me.

[Tanddant]

This is expected behavior due to SPFx versioning differences. When multiple extensions target the same list view, only one command set is loaded—typically the one from the older SPFx version. To resolve this, ensure both solutions are using the same SPFx version, ideally the latest supported.

This certainly has not always been the case, and I hope it's not the case going forward, what happens if I have a solution from a vendor that's still running SPFx 1.4.0? - does that mean I can not not use a separate solution I purchased from a vendor who's running SPFx 1.20.0?

IMHO One of the big selling points of SPFx is the whole "don't worry about it" if you deploy it and it works "we" (Microsoft) will keep it running, it has often been mentioned how someone could write code 7 years ago in SPFx 1.0.0 that still runs today in SharePoint Online, and it'll run nicely alongside any new extensibility (And it does for web parts) - and used to for command sets

@Amey-MSFT Can you either point us to a place where this is mentioned in the documentation, or get the documentation updated to reflect this change - ideally with guidance for how ISVs should deal with this change that could now break their products.

[Amey-MSFT]

Hello @anthonywhite , @Tanddant, Will connect with the Engineering and let you know on the updates. Thanks!!

[anthonywhite]

Hello @anthonywhite , @Tanddant, Will connect with the Engineering and let you know on the updates. Thanks!!

@Amey-MSFT can you take the "awaiting author" label off this please - it's awaiting Microsoft now!

[andrewconnell]

There you go @anthonywhite ... fixed it for you ;)

[anthonywhite]

@Amey-MSFT any update on this please?

[Amey-MSFT]

Hello @anthonywhite, We were able to reproduce the issue, and we are investigating it. We have logged this as a bug, and our engineering team will look into it. Thank you!

[anthonywhite]

Hello @anthonywhite, We were able to reproduce the issue, and we are investigating it. We have logged this as a bug, and our engineering team will look into it. Thank you!

ok, thx. I guess the only workaround meanwhile is to align the SPFx versions of all solutions?

[VesaJuvonen]

@anthonywhite - really sorry for the delay here from the engineering side.

Can you check one thing on this - if you still have the solutions for the issue. My guess is that the solution command names are overlapping and therefore they override each other. This is something which was in detailed discussed at #10202, which will be resolved.

I'm assuming that what you are seeing is related on the same issue. Would love to get the situation confirmed if you have the solutions close by. I get that this is way overdue, but we are working now actively through the issues - to stay up to date on the queue.

[anthonywhite]

@VesaJuvonen thanks - on looking over our code we now have all solutions on 1.21.1 and also unique command names 🙂 - so either of those may have fixed the issue. It is still possible that we had a duplicate default COMMAND_1 name at the time of report, but without digging back in Git history, difficult to confirm.