Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CommandSet Extensions not working with gulp serve #3914

Closed
KoenZomers opened this issue May 9, 2019 · 55 comments

Comments

@KoenZomers
Copy link
Contributor

commented May 9, 2019

Category

  • Question
  • Typo
  • 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

This comment has been minimized.

Copy link
Collaborator

commented May 9, 2019

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

@KoenZomers

This comment has been minimized.

Copy link
Contributor Author

commented May 9, 2019

Linking to this post where someone is reporting the same behavior: #3703 (comment)

@statto1974

This comment has been minimized.

Copy link

commented May 9, 2019

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

This comment has been minimized.

Copy link

commented May 9, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented May 9, 2019

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

This comment has been minimized.

Copy link

commented May 9, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented May 9, 2019

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

@KoenZomers

This comment has been minimized.

Copy link
Contributor Author

commented May 9, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented May 9, 2019

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

This comment has been minimized.

Copy link

commented May 9, 2019

@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

This comment has been minimized.

Copy link

commented May 9, 2019

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

@andrewconnell

This comment has been minimized.

Copy link
Collaborator

commented May 9, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented May 9, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented May 9, 2019

@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

This comment has been minimized.

Copy link
Contributor Author

commented May 9, 2019

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

This comment has been minimized.

Copy link

commented May 9, 2019

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

@KoenZomers

This comment has been minimized.

Copy link
Contributor Author

commented May 9, 2019

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

This comment has been minimized.

Copy link

commented May 9, 2019

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

This comment has been minimized.

Copy link
Contributor

commented May 9, 2019

@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

This comment has been minimized.

Copy link
Contributor Author

commented May 10, 2019

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

This comment has been minimized.

Copy link

commented May 10, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented May 10, 2019

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

This comment has been minimized.

Copy link

commented May 13, 2019

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

This comment has been minimized.

Copy link
Contributor

commented May 14, 2019

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

This comment has been minimized.

Copy link

commented May 14, 2019

@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

@KoenZomers

This comment has been minimized.

Copy link
Contributor Author

commented Jun 4, 2019

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

@KoenZomers

This comment has been minimized.

Copy link
Contributor Author

commented Jun 4, 2019

@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

This comment has been minimized.

Copy link
Contributor Author

commented Jun 4, 2019

@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

This comment has been minimized.

Copy link
Contributor Author

commented Jun 4, 2019

@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

This comment has been minimized.

Copy link

commented Jun 21, 2019

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
@ymihir ymihir referenced this issue Jun 25, 2019
1 of 1 task complete
@AaronWoods

This comment has been minimized.

Copy link

commented Jun 26, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jun 26, 2019

@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

This comment has been minimized.

Copy link

commented Jun 26, 2019

@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

This comment has been minimized.

Copy link

commented Jun 28, 2019

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

@PopWarner PopWarner referenced this issue Jul 3, 2019
1 of 4 tasks complete
@ravick4u

This comment has been minimized.

Copy link

commented Jul 3, 2019

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

This comment has been minimized.

Copy link

commented Jul 3, 2019

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 comment has been minimized.

Copy link

commented Jul 30, 2019

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

This comment has been minimized.

Copy link

commented Aug 1, 2019

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

This comment has been minimized.

Copy link
Collaborator

commented Aug 1, 2019

Give this a try... #4374 (comment)

@andrewconnell

This comment has been minimized.

Copy link
Collaborator

commented Aug 1, 2019

This workaround may help: #4374 (comment).

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

This comment has been minimized.

Copy link

commented Aug 2, 2019

@andrewconnell The workaround worked for me. Thanks!

@KoenZomers

This comment has been minimized.

Copy link
Contributor Author

commented Aug 8, 2019

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

@ArndBrugman

This comment has been minimized.

Copy link

commented Aug 20, 2019

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.