Sp-dev-docs: CommandSet Extensions not working with gulp serve

[KoenZomers]

Category

• [ ] Question
• [ ] Typo
• [X] Bug
• [ ] Additional article idea

Expected or Desired Behavior

If using gulp serve to develop and test a CommandSet Extension locally against a SharePoint Online environment, the button(s) to show up in your list or document library

Observed Behavior

The buttons will never show up in the list or document library when using gulp serve to serve it from your localhost. It does work if you gulp package-solution it and throw the sppkg into the Add-In Catalog.

The fault exists on Targeted Release tenants. It works fine on Standard Release tenants or for users not being in the Targeted Release Selected People group.

Steps to Reproduce

1. Use the yo @microsoft/sharepoint generator to build a new ListView CommandSet following the guidelines from https://docs.microsoft.com/en-us/sharepoint/dev/spfx/extensions/get-started/building-simple-cmdset-with-dialog-api
2. Copy the URL of some list or document library to the pageUrl node in serve.json file in your solution
3. Run gulp serve
4. The browser will open up the list or document library you used at step 2 but will never show any of the command buttons
5. gulp package-solution the same solution, throw the generated sppkg file in an add-in catalog, add the add-in to a site and go to the same list as used at step 2 and you will see the buttons

SPFx 1.82
NPM 5.6.0
NodeJS 8.9.4

[msft-github-bot]

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[KoenZomers]

Linking to this post where someone is reporting the same behavior: https://github.com/SharePoint/sp-dev-docs/issues/3703#issuecomment-484111388

[statto1974]

Adding some further investigation I've done on this

When debugging through VS Code and adding breakpoints I notice the following behavior

The CommandSet class module is loaded, but none of the override methods are called; onInit, onListViewUpdated, onExecute

No exceptions are shown in the debug console.

[statto1974]

Not sure if this is relevant, but I am seeing this come up in the debug console

Object {exception: null, error: GraphError: Could not find a property named 'itemA…, promise: e, handler: undefined, id: 24, …}
spoapp-mini-5b849bcd.js:1
GraphError: Could not find a property named 'itemActions' on type 'oneDrive.item'.
    at e.n (https://spoprod-a.akamaihd.net/files/odsp-next-prod_2019-04-26-sts_20190508.001/spofiles-mini-d3086537.js:1:284521)
    at new e (https://spoprod-a.akamaihd.net/files/odsp-next-prod_2019-04-26-sts_20190508.001/splistdeferredexpress-is-mini-8f678127.js:1:736154)
    at https://spoprod-a.akamaihd.net/files/odsp-next-prod_2019-04-26-sts_20190508.001/splistdeferredexpress-is-mini-8f678127.js:1:735398
    at r.then (https://spoprod-a.akamaihd.net/files/odsp-next-prod_2019-04-26-sts_20190508.001/spofiles-mini-d3086537.js:1:29452)
    at https://spoprod-a.akamaihd.net/files/odsp-next-prod_2019-04-26-sts_20190508.001/splistdeferredexpress-is-mini-8f678127.js:1:735358
    at Object.I [as _notify] (https://spoprod-a.akamaihd.net/files/odsp-next-prod_2019-04-26-sts_20190508.001/spofiles-mini-d3086537.js:1:28005)
    at Object.enter (https://spoprod-a.akamaihd.net/files/odsp-next-prod_2019-04-26-sts_20190508.001/spofiles-mini-d3086537.js:1:26523)
    at d._run (https://spoprod-a.akamaihd.net/files/odsp-next-prod_2019-04-26-sts_20190508.001/spofiles-mini-d3086537.js:1:33164)
    at d._error (https://spoprod-a.akamaihd.net/files/odsp-next-prod_2019-04-26-sts_20190508.001/spofiles-mini-d3086537.js:1:32666)
    at b._callFailureCallback (https://spoprod-a.akamaihd.net/files/odsp-next-prod_2019-04-26-sts_20190508.001/spoapp-mini-5b849bcd.js:1:166613)

[KoenZomers]

Exactly @statto1974. I noticed exactly the same. It does load the manifest, it does based on that load in the JS file with the code but it never triggers any of the methods in it. Not even the onInit.

[unowiz]

I have the same behaviour in tenants with release track is set to targeted release. version of spfx didn't matter. I have seen the issue for 1.6 and 1.8. (didn't bother checking for 1.7)
Here's what I have found out in a tenant where I have selected users set as targeted release users:

• when logged in as the targeted release user, the commandSet extension doesn't work
• when logged in a anyother user, the commandSet extension works!

Also, obvious but just to clarify, for tenant where all users are set a targeted release users, the commandSet doesn't work!

[KoenZomers]

Thanks @unowiz! That allows for a fairly easy workaround for now. Appreciate you sharing this.

[KoenZomers]

I just switched my tenant from TR all users to TR selected users and logged on with someone not in the selected users group. It still doesn't show the buttons, but perhaps it takes time for the TR change to be applied.

[KoenZomers]

From another tenant that is on standard release for everyone I can confirm it to work well on there, like @unowiz experienced already as well.

[unowiz]

@Kem-El I presume so. It will take time. Please do keep us posted when you have seen an improvement for the other tenant

[statto1974]

Unfortunately I have to leave mine on All Targeted Release :-(

[andrewconnell]

This is a known issue MSFT is working on... mentioned in the v1.8.2 release notes earlier this week:
https://github.com/SharePoint/sp-dev-docs/wiki/SharePoint-Framework-v1.8.2-release-notes#updates-that-are-rolling

[KoenZomers]

@andrewconnell Can you point out specifically where in the release notes this is being mentioned? I seem not to be able to find it. Or is it the general stability remark?

[PopWarner]

@KoenZomers, it's near the bottom in the "Updates that are rolling" secton. First bullet point:

• We continue to fix issues around extensions in modern lists and libraries. We realize that we need to improve the stability in this application.

:)

[KoenZomers]

So yes, that line :) Thx @PopWarner Bit too vague to give it enough hope that exactly this issue is on their radar if you ask me :) We're pursuing this issue through Premier Support now as well.

[statto1974]

Is there any timeline for this? Sort of putting a hold on any further development currently.

[KoenZomers]

Timelines are hardly ever given for these kind of things. Although it not being ideal I realize, would it not be a temporary workable solution for you @statto1974 to create a new trial Office 365 tenant which you keep on Standard Release? At least you can build and test your functionality against then and then deploy it to your normal tenant to confirm all works well?

[statto1974]

If there's no timelines then I don't really have any other options. My CommandSets rely on some Site and Libraries to be setup which I haven't scripted yet, so it's going to take time to setup my environment :-(

[PopWarner]

@statto1974, I don't know if this would work for you, but if it is working once it's deployed, just not using "Gulp Serve", you could bundle and package NOT using the --ship, so that it will still be served using your localhost and then perhaps try deploying it to a Site Collection App Catalog, which provides a degree of separation from the rest of the tenant.

My tenant is All Targeted Release as well and this was the method I used.

I know there are a few extra steps here, so not the most ideal, but just trying to think of alternatives. :)

[KoenZomers]

The switch from Targeted Release to Targeted Release selected user has now been applied to my tenant. I can now indeed just log on with an user which is not in the targeted release group and it will show the buttons. Works fine for me as a workaround!

[statto1974]

@PopWarner thanks, will try and use that method for the time being

Are Extensions out of Preview? This is the second time in the last couple of months that this has broken. I end up wasting days thinking there's something wrong with my solution, to then discover that the dev pipeline is broken again. Very frustrating.

[patmill]

Hey @KoenZomers - Long time no chat. hope everything is going well with you. OK, I just spent a day digging into these various scenarios. For the CommandSet extensions, I've created the basic one running the template in 1.8.2. gulp serve gives me the long URL when I run gulp serve
Opening https://contoso.sharepoint.com/sites/mySite/SitePages/myPage.aspx?debugManifestsFile=https%3A%2F%2Flocalhost%3A4321%2Ftemp%2Fmanifests.js&loadSPFX=true&customActions=%7B%2210828907-a467-4094-89a4-087a53c7d477%22%3A%7B%22location%22%3A%22ClientSideExtension.ListViewCommandSet.CommandBar%22%2C%22properties%22%3A%7B%22sampleTextOne%22%3A%22One+item+is+selected+in+the+list%22%2C%22sampleTextTwo%22%3A%22This+command+is+always+visible.%22%7D%7D%7D using the default OS app

Taking the full query string, I can hit my tenant doclib, hit 'ok' to the debug script warning, and in the root document library, I get my command set running, with the 'Command 2' button showing always, and 'Command 1' only showing when I select a single item. Now, if I navigate from one library to another, the command set drops off - not sure if that is expected or not. I've tried this on both doclibs and pages, com sites and team sites, with both first-release and standard-release users. FYI, my build # (based on the path to the js files) is spoprod-a-akamaihd.net->files->odsp-next-prod_2019-04-26-sts-20190508.002 . What version are you seeing this on? I know the lists/libraries folks have been addressing issues in this area.

[rbarten]

I have the same issue. It doesn't work on most sites, but on some it does work.. Even while debugging and using the same 'debug' querystring in the url.
When it doesn't work 'CustomActionElements' doesn't return the custom ClientSideComponentId. Only IDs with "00000000-0000-0000-0000-000000000000" are returned.

"https://spoprod-a.akamaihd.net/files/odsp-next-prod_2019-04-26-sts_20190508.002" is loaded within our tenant.

[patmill]

Can you help pinpoint the differences? First release user vs. standard user? Teamsite vs. Com site? List vs. Library? Alternately, if you feel comfortable and have a developer / trial tenant, you can send me repro information (my email is my user name @microsoft.com)

[unowiz]

@patmill
seems to be an issue only when we have a CommandSet extension that we are gulp serving and hasn't yet been deployed yet. For targeted release users, the command buttons don't appear.

• when logged in as the targeted release user, the commandSet extension doesn't work
• when logged in a anyother user, the commandSet extension works!

Once I deployed the package to the app catalog and the CommandSet extension does work as we expect.
Here's a what I have seen so far:

1. Generated a ListView CommandSet project.
2. Updated pageUrl in serve.json
3. Did gulp serve. //For targeted release users, Buttons didn't render and The CommandSet class module is loaded, but none of the override methods are called. Standard release users don't have any problem
4. Did gulp bundle and package-solution and deployed the package
5. gulp serve works // irrespective of whether its a standard or targeted release user

deploying the package once helped me.

Hope this helps.
-A

[unowiz]

@patmill @KoenZomers
To test what I mentioned above, I tried the following steps( for targeted release user in a comm site):

• removed the extension from the app catalog, gulp serve didn't work.
• restored the extension and installed the app to my site, gulp serve works!

Not much of an issue to me right now. Worth mentioning deployment as a requirement? in the Debug your ListView Command Set section in the getting started guide.
On the same guide, the last section Deploy the extension to SharePoint Online and host JavaScript from local host does mention "deploy + gulp serve" scenario.

[statto1974]

@unowiz I've tried both scenarios and it doesn't work for either.

I've deployed the package without the --shipping parameter and then did gulp serve and this didn't work either. In developer tools I can see the module is being loaded, but none of the overridden methods are being called.

[statto1974]

Here's a screen grab of the files from Developer Tools

[KoenZomers]

@patmill Long time no chat indeed. All good here, hope same goes for you :) I've tried this on several site collections and on three different tenants. Also had four different colleagues on yet another four different tenants confirm they're running into the same. We've got more customers reporting it to Premier now as well. Bit stumbled as of why you can't reproduce it.

For me no buttons are showing up. Only if I'm not using a targeted release user/tenant or deploy it first to the site scoped app catalog I will see the functionality in the way you describe to see it.

For me framework files are being served off of:
https://spoprod-a.akamaihd.net/files/odsp-next-prod_2019-05-03-sts_20190515.001

This behavior seems consistent for all people reporting it in this thread.

Let me know if you want to do a screen sharing session to dive into this one.

[patmill]

OK, so figured out why I couldn't repro this. The switch from standard to targeted release is taking a long long time to kick in, so while I thought I was running in targeted release, I wasn't. Digging in.

[statto1974]

I've managed to create a separate developer tenant on standard release and my extension commands are showing. Have added screenshot of file from the developer tenant on standard release

[jindalv10]

Any update on this issue?

[ahackettms]

This is fixed. Please try again

[andrewconnell]

@ahackettms Two quick questions:

1. does that include updates to all extensions as we've seen multiple issues reported on all three types of extensions
2. is it rolled out to all targetted release & standard release tenants?

[ahackettms]

@andrewconnell It should includes a few fixes related to extensions but without knowing exactly which issue you are referring to, I can't say which fixes were included. This issue here (load extensions with gulp serve) is fixed, and it's rolled out to targetted release. (standard release tenants should not have this issue, right? )

[andrewconnell]

@ahackettms This issue list has a good number of open issues related to extensions, hence the question. I don't have a specific one in mind... do you have more details on "includes a few fixes related to extensions"?

[KoenZomers]

@ahackettms from my side I can say the issue being discussed here has NOT been fixed yet. I'm using a MT with targeted release selected users enabled. For a user in the targeted release group it does not work, for someone outside of this group on the same tenant, same solution, same URL, it does work. Let me know if you want me to run additional tests.

[KoenZomers]

@ahackettms I also tested this on another tenant which is on Targeted Release for everyone and also here it is not working yet.

[KoenZomers]

@ahackettms Did some further testing on my end. It is actually fixed if you deploy it to a list (ListTemplateId\RegistrationId="100") but it is not working yet if trying to deploy it to a document library (ListTemplateId\RegistrationId="101"). Even the workaround of first deploying it to a tenant wide or site collection app catalog first still serving it from gulp serve on localhost no longer works with ListTemplateId\RegistrationId="101".

[KoenZomers]

@ahackettms The behavior is actually super random at the moment. Could it be that not all prod frontends have been updated? Sometimes on 100 it works through gulp serve, sometimes it doesn't, but the workaround via the app catalog does but not in any scenario or test I can get it to work with 101.

Is there a way to validate that your patch is being used? I.e. by looking at a specific version of a file?

At the moment I can't get it to work anymore for 100 and 101 through gulp serve directly. Only via the app catalog it works for 100, not for 101. Same behavior as when this issue was reported in this thread: the files do get loaded from localhost, but the init will never be called. Has the update been revoked?

[KoenZomers]

@ahackettms Few more hours of debugging this later I figured out that the CustomAction does not get created most of the time. It only seems to work the first time I deploy it for a new SPFx solution through the app catalog. If I remove the add-in from the site contents again, it will delete the CustomAction. If I then add it back, it never recreates the CustomAction thus the list never asks for the SPFx Extension anymore thus its broken forever.

If I then manually add the CustomAction using:

Add-PnPCustomAction -Title "Test1" -Name "Test1" -Location "ClientSideExtension.ListViewCommandSet.CommandBar" -ClientSideComponentId f0cccc11-a21d-4731-b6b5-89f90c81e2ec -ClientSideComponentProperties "" -RegistrationId 100 -RegistrationType List -Scope Web

It does work again on normal lists, but if I try the same for Document libraries:

Add-PnPCustomAction -Title "Test2" -Name "Test2" -Location "ClientSideExtension.ListViewCommandSet.CommandBar" -ClientSideComponentId f0cccc11-a21d-4731-b6b5-89f90c81e2ec -ClientSideComponentProperties "" -RegistrationId 101 -RegistrationType List -Scope Web

It seems like document libraries don't check against the registered CustomActions and thus it never triggers the SPFx Extension to be loaded.

I'm giving up for now. This stuff is really way too unstable at the moment to be used. Hopefully my findings can help you to resolve the issue(s) at hand. Feel free to contact me if you need further input.

[phillipharding]

Tried a ListView Command-set extension today using SPFx 1.8.2 and have the same problems with Commands not showing when using gulp serve

My tenant is on Targeted Release, packaging the solution and deploying to the app catalog, then adding the solution to a site does cause the commands to show as expected.

Also, packaging the solution (to serve files from localhost) and deploying to the app catalog, then adding the solution to a site, causes the commands to show as expected, and also offers a sort of interactive debugging experience;

• package and deploy to the app catalog
• add solution to a site collection
• run gulp serve --nobrowser
• open list view page in the browser
• in VSCode, update your extension code and save
• the extension code will automatically be rebuilt when you save changes without gulp serve --nobrowser needing to be run again
• refresh your list view page and your code changes will take effect

I've found that if you add or change commands to your extension, its best to;

• remove the solution from the site collection (also remove the solution package from the recycle bin (1st and 2nd stages)
• remove the solution from the app catalog
• repreat the previous set of steps

[AaronWoods]

Debugging listview extensions(on document libraries in my case) on target release tenants still doesn't work. The patch mentioned above either still hasn't been deployed to tenants or the patch is not working

[PopWarner]

@AaronWoods, were you able to try out the suggestion from @phillipharding? I've found that to currently be the most successful way to dev/debug from my local machine. I know it's an extra step, but until the rest of it gets sorted out, it's been the most reliable way for me. :)

[phillipharding]

@PopWarner @AaronWoods that technique has worked quite nicely for me, you cant debug using VSCode, but debugging in Chrome Dev tools works just as well.

The thing to keep in mind (and catches me out occasionaly when I forget) is that having deployed a package (built without using --ship) to the appcatalog, if you change anything that would change the package or the bundle files, like adding commands, importing SPFx or other modules into your code, then you have to;

• Remove package from appcatalog
• Build, bundle and package-solution without using --ship
• Add package to appcatalog

[LouFarho]

I have also tried to go through the sample for Command Sets and cannot get my commands to register.
Targeted Release Tenant
SPFx 1.8.2
NPM 6.9.0
NodeJS 10.16.0

[ravick4u]

Below are some of my observations,

• My existing deployed CommandSet Extension has stopped working with Targeted release for selected users and regular users.
• Created new CommandSet Extension and gulp serve is working for non targeted users
• Created new CommandSet Extension and gulp serve is not working for non targeted users

[ravick4u]

Someone mentioned that behavior is not constant and seeing the same inconstancy. Sometime CommandSet appears sometime it does not with non targeted users.

[pettersh]

This is still an issue. I have a list view command set deployed to production that stopped working during July, and now it's practically impossible to debug the solution and analyze what is failing.

My solution is built with 1.7.1. I created a vanilla extension using 1.8.2 yesterday and failed to have it show up in thee different tenants using gulp serve. build, bundle, package-solution and deploy to my targeted release dev tenant worked as expected, but it's way too difficult/cumbersome to debug that way. Please prioritize this issue.

[VictorMuMo]

I have tried it too and still fails.
Targeted tenant release for everyone
SPFx 1.7.1
NPM 6.10.1
NodeJS 8.15.1

[andrewconnell]

Give this a try... https://github.com/SharePoint/sp-dev-docs/issues/4374#issuecomment-516815819

[andrewconnell]

This workaround may help: https://github.com/SharePoint/sp-dev-docs/issues/4374#issuecomment-516815819.

Appears a regression was introduced at some point that caused the wrong URL to be generated by gulp serve which isn't telling SPO to load SPFx onto the page if it isn't already there.

Hey OP @KoenZomers, please try this and report back if it resolves your issue.

[VictorMuMo]

@andrewconnell The workaround worked for me. Thanks!

[KoenZomers]

Replacing in the URL loadSpfx works for me too as a workaround. Brilliant find!

[ArndBrugman]

I had the same issue on version 1.8.2 updated to version 1.9.1 and it now works for me as expected on gulp serve without modifications on SPO. Thx all, great work!

[msft-github-bot]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues