Please specify what version of the library you are using: [2.0.11]
Please specify what version(s) of SharePoint you are targeting: [Online ]
I have a .sppkg that contains 1 _Web Part_ and 2 _ApplicationCustomizer Extensions_ which provide analytics on site usage. The intention of the web part is to install it on a single site collection to provide an interface to configure and deploy the extensions onto other modern sites selected from a list.
I'm struggling to gain access to a single component from within the .sppkg in the tenant app catalog and install _just_ that extension onto site, without having to apply the entire .sppkg. So far I'm only able to install the entire .sppkg which adds the web part to the site. This is undesirable.
Is this possible? Any guidance would be appreciated.
I'm aware that I could package the extensions in their own .sppkg and upload both the web part and extensions the tenant app catalog as separate packages, but this goes against the customer requirement of having a single self contained solution that does not use the tenant deploy.
You can't do what you're looking to do without two sppkg (solution) files.
That said, because the scenario you want to support is to have the extensions run but not have the web part, you could make the web part not available in the catalog and therefore even though the application is deployed to that other site collection the users would never see the web part because it's not in the toolbox.
In your web part's manifest.json file you would add the following property:
"hiddenFromToolbox": true,
The better option to my mind would be packaging the web part and the extensions separately but then deploying the web part to the site collection that will be where the solution is run from via a site collection app catalog. Then deploy the solution with the extensions to the tenant app catalog (obviously not tenant wide deployed) and then you can have the web part add the extensions package to whichever site collections it wants to.
When building a SPA like solution via SPFx I always leverage the site collection app catalog for that scenario as well as changing the supportedHosts property in the manifest.json from "SharePointWebPart" to "SharePointFullPage", but that's just me. Good luck.
You can't do what you're looking to do without two sppkg (solution) files.
That said, because the scenario you want to support is to have the extensions run but not have the web part, you could make the web part not available in the catalog and therefore even though the application is deployed to that other site collection the users would never see the web part because it's not in the toolbox.
In your web part's manifest.json file you would add the following property:
"hiddenFromToolbox": true,The better option to my mind would be packaging the web part and the extensions separately but then deploying the web part to the site collection that will be where the solution is run from via a site collection app catalog. Then deploy the solution with the extensions to the tenant app catalog (obviously not tenant wide deployed) and then you can have the web part add the extensions package to whichever site collections it wants to.
When building a SPA like solution via SPFx I always leverage the site collection app catalog for that scenario as well as changing the
supportedHostsproperty in the manifest.json from "SharePointWebPart" to "SharePointFullPage", but that's just me. Good luck.
I suspected as much. Thanks for the confirmation.
If we use the hiddenFromToolbox option, I assume we'll need to ensure the web part provisions a page and inserts itself when installed on the desired site.
I'm about to start looking into this, but maybe you know off the top of your head. Is there any sort of provisioning logic to say that a web part can only provision the SP Full Page on certain pages? If there's a way to block it creating assets when installed on some sites, that could mean we don't have to split our extension out as a separate package and could potentially allow the web part on the "main" site to deploy itself to other sites so the extension component is added, but not be visible on those site otherwise.
If we use the hiddenFromToolbox option, I assume we'll need to ensure the web part provisions a page and inserts itself when installed on the desired site.
So, yes, you'd have to use something like PowerShell or the M365CLI to provision the web part to the page in the site collection. What is really confusing about this question is that you said "inserts itself when installed on the desired site" I thought there was only 1 site with the web part in it.
I'm not following the scenario where you need the web part auto provisioned to a bunch of sites but not all the sites, I thought the web part was only there as an administrative app to control where the extensions get deployed.
If we use the hiddenFromToolbox option, I assume we'll need to ensure the web part provisions a page and inserts itself when installed on the desired site.
So, yes, you'd have to use something like PowerShell or the M365CLI to provision the web part to the page in the site collection. What is really confusing about this question is that you said "inserts itself when installed on the desired site" I thought there was only 1 site with the web part in it.
I'm not following the scenario where you need the web part auto provisioned to a bunch of sites but not all the sites, I thought the web part was only there as an administrative app to control where the extensions get deployed.
Sorry that wasn't clear. My thought was that we basically had a couple options:
One would be to have a separate .sppkg for the extension and the webpart. So the web part would be placed on one site and just manage the extra extension. There are some pros and cons to this for us.
The other is that we could keep the extension within the web part and simply push the web part .sppkg (itself) out to each site so that the extension is also added.
The concern here is that automatically provisioning a page with the web part on it would happen on all sites. We'd prefer not to provision the page on some sites at all, but also not have to rely on PowerShell scripts that the customers have to run manually. After a little review, it seems like that's probably not possible. Pages defined in the .sppkg element.xml would presumably be created on every site where the .sppkg is deployed.
Due to this we're now considering allowing the page to be provisioned on deploy, but rendering the web part UI differently on the management site vs other sites. The management site can get the "real" UI, while the other sites might show the current configuration for that site and have a link to the management site.
Anyways, I appreciate the insight you've provided. It's been really helpful for our investigation, but I don't want to waste anymore of your time. So I'll close this out!
Thanks!!!
Most helpful comment
You can't do what you're looking to do without two sppkg (solution) files.
That said, because the scenario you want to support is to have the extensions run but not have the web part, you could make the web part not available in the catalog and therefore even though the application is deployed to that other site collection the users would never see the web part because it's not in the toolbox.
In your web part's manifest.json file you would add the following property:
"hiddenFromToolbox": true,The better option to my mind would be packaging the web part and the extensions separately but then deploying the web part to the site collection that will be where the solution is run from via a site collection app catalog. Then deploy the solution with the extensions to the tenant app catalog (obviously not tenant wide deployed) and then you can have the web part add the extensions package to whichever site collections it wants to.
When building a SPA like solution via SPFx I always leverage the site collection app catalog for that scenario as well as changing the
supportedHostsproperty in the manifest.json from "SharePointWebPart" to "SharePointFullPage", but that's just me. Good luck.