cli icon indicating copy to clipboard operation
cli copied to clipboard

Plugin got broken after CLI update

Open patrykacc opened this issue 2 years ago • 24 comments

Summary

Result of executing "sfdx texei" command before executing "sfdx:update" command

sfdx texei
Texeï's plugin for sfdx

USAGE
  $ sfdx texei:COMMAND

TOPICS
  texei:assetSharing                Enables asset sharring
  texei:defaultOpportunityQuantity  Enables default Opportunity Settings
  texei:integration                 Enables salesforce to salesforce integration
  texei:package                     install dependent Packages for a sfdx project
  texei:sharingcalc                 recalculate sharing rules

Result of executing "sfdx texei" command before executing "sfdx:update" command

sfdx texei
Texeï's plugin for sfdx

USAGE
  $ sfdx texei:COMMAND

Comment: as you see above, TOPICS section is missing after I updated my CLI, and that makes also that exuction of dependencies install command for plugin TEXEI fails, which breaks my CD:

sfdx texei:package:dependencies:install
 »   Warning: texei:package:dependencies:install is not a sfdx command.
Did you mean force:package:uninstall? [y/n]: 
 »   Error: Run sfdx help texei for a list of available commands.

System Information

sfdx-cli: Updating CLI from 7.94.3-a4e7c7955b to 7.163.0-ea5a9c6... done

patrykacc avatar Aug 12 '22 09:08 patrykacc

Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support.

github-actions[bot] avatar Aug 12 '22 09:08 github-actions[bot]

@patrykacc I'm unable to reproduce the issue on 7.164.1 and [email protected]

Are you able to provide steps to reproduce?

mdonnalley avatar Aug 15 '22 14:08 mdonnalley

I am seeing a similar issue with wry after updating to 7.163.0 from version 7.156.1, and a teammate is experiencing the same issue. The plugin still links properly though, just cannot be found when run.

slaght avatar Aug 15 '22 18:08 slaght

Having the same problem. The issue seems to be with sfdx plugins:link it is currently affecting our CI/CD pipelines

Update: downgrading from 7.163 to 7.160 makes the plugins work again.

warbio avatar Aug 16 '22 10:08 warbio

Same issue here (with another custom plugin). Downgrading to 7.160 helped as a workaround too.

hansds avatar Aug 17 '22 10:08 hansds

I've tried the following but have not been able to reproduce it:

  • install sfdx v7.156.1
  • sfdx plugins:install texei-sfdx-plugin
  • sfdx update

After updating I'm still able to see all the texei commands:

~/repos/trailheadapps/dreamhouse-lwc (main*) » sfdx texei
Texeï's plugin for sfdx

USAGE
  $ sfdx texei:COMMAND

TOPICS
  texei:contractstatus    [DEPRECATED - Use Metadata API instead] add a value to Contract Status picklist
  texei:cpqsettings       set CPQ Settings from file
  texei:data              export objects' data from org
  texei:debug             Enable Debug Mode for Lightning Components
  texei:org               Commands to manage org
  texei:package           install dependent Packages for a sfdx project
  texei:picklist          [BETA] Add back restricted option on picklists
  texei:profile           clean Profile by removing permissions stored on Permission Set
  texei:sharedactivities  [DEPRECATED - Use the SharedActivities feature instead] Enable Shared Activities
  texei:sharingcalc       recalculate sharing rules
  texei:skinnyprofile     export a skinny profile with just package-specific metadata
  texei:source            replace custom label value
  texei:user              updates the current user of a scratch org

So a couple of follow up questions:

  • Can anyone confirm that uninstalling and reinstalling the plugin resolves the issue?
  • Is anyone able to provide steps that I can follow to reproduce?

Thanks!

mdonnalley avatar Aug 17 '22 15:08 mdonnalley

@mdonnalley In my experience it only happens to locally linked plugins, not installed ones. So:

  • install sfdx v7.163
  • locally git clone texei-sfdx-plugin to dir
  • run sfdx plugins:link {dir}

You should not be getting any commands, although the namespace may be listed if the oclif.topics key is properly completed in package.json.

hansds avatar Aug 18 '22 07:08 hansds

@hansds I'm still unable to replicate it by following those steps.

Are you able to get your plugin working again by uninstalling and reinstalling it?

mdonnalley avatar Aug 18 '22 15:08 mdonnalley

@mdonnalley I'll stress again that we're not installing, but linking. Installed plugins do not show the behaviour. Unlinking and linking does not however fix the issue, only downgrading did I'm afraid...

hansds avatar Aug 19 '22 07:08 hansds

@hansds I understand. I followed your instructions to link the plugin and was still able to access all the texei commands from the linked texei-sfdx-plugin.

Can you provide the output from sfdx version --verbose? I'm wondering if the issue might be related to the node version and/or the operating system

mdonnalley avatar Aug 19 '22 13:08 mdonnalley

Same on our side, in all environments, including all CI servers.

  • install sfdx v7.163
  • clone our plugin repository
  • run sfdx plugins:link {dir}
  • sfdx prints only topics, which are mentioned in package.json in oclif/topics. Help for all other commands is not printed, and commands are not found.

I'm also linking, not installing. We had to downgrade to 7.162.0. As an example, I use 16-alpine3.15 node docker image.

uwe-voellger avatar Aug 22 '22 09:08 uwe-voellger

We are also experiencing the same problem with our plugins when running it in CI. The command is no longer recognized although the plugin was successfully linked before running it.

javierCTL avatar Aug 22 '22 14:08 javierCTL

Can you provide the output from sfdx version --verbose? I'm wondering if the issue might be related to the node version and/or the operating system

I had to downgrade the CLI to keep the plugin working but here is my output with --verbose

CLI Version : 
        sfdx-cli/7.160.0

 Architecture:
        win32-x64

 Node Version :
        node-v16.16.0

 Plugin Version:
        @oclif/plugin-autocomplete 0.3.0 (core)
        @oclif/plugin-commands 1.3.0 (core)
        @oclif/plugin-help 3.3.1 (core)
        @oclif/plugin-not-found 1.2.6 (core)
        @oclif/plugin-plugins 1.10.11 (core)
        @oclif/plugin-update 1.5.0 (core)
        @oclif/plugin-warn-if-update-available 1.7.3 (core)
        @oclif/plugin-which 1.0.4 (core)
        @salesforce/sfdx-plugin-lwc-test 1.0.0 (core)
        alias 2.1.0 (core)
        apex 1.1.0 (core)
        auth 2.2.2 (core)
        community 2.0.0 (core)
        config 1.4.14 (core)
        custom-metadata 2.0.0 (core)
        data 2.0.4 (core)
        generator 2.0.2 (core)
        info 2.0.1 (core)
        limits 2.0.1 (core)
        org 2.0.3 (core)
        salesforce-alm 54.6.2 (core)
        schema 2.1.1 (core)
        sfdx-cli 7.160.0 (core)
        sfdx-wry-plugin 0.0.11 (link) C:\Users\[removed]
        signups 1.2.0 (core)
        source 2.0.7 (core)
        telemetry 2.0.0 (core)
        templates 55.0.0 (core)
        trust 2.0.1 (core)
        user 2.1.0 (core)

 OS and Version:
        Windows_NT 10.0.19042

slaght avatar Aug 22 '22 15:08 slaght

Can you provide the output from sfdx version --verbose? I'm wondering if the issue might be related to the node version and/or the operating system

The below reflects @uwe-voellger's environments with the latest CLI. We are currently working by downgrading to 7.162.0.

CLI Version:
        sfdx-cli/7.164.2

 Architecture:
        win32-x64

 Node Version:
        node-v16.15.1

 Plugin Version:
        @oclif/plugin-autocomplete 1.3.0 (core)
        @oclif/plugin-commands 2.2.0 (core)
        @oclif/plugin-help 5.1.12 (core)
        @oclif/plugin-not-found 2.3.1 (core)
        @oclif/plugin-plugins 2.1.0 (core)
        @oclif/plugin-update 3.0.0 (core)
        @oclif/plugin-version 1.1.1 (core)
        @oclif/plugin-warn-if-update-available 2.0.4 (core)
        @oclif/plugin-which 2.1.0 (core)
        alias 2.1.0 (core)
        apex 1.1.0 (core)
        auth 2.2.3 (core)
     community 2.0.0 (core)
        config 1.4.17 (core)
        custom-metadata 2.0.0 (core)
        data 2.1.2 (core)
        generator 2.0.2 (core)
        info 2.0.1 (core)
        limits 2.0.1 (core)
        org 2.2.0 (core)
        schema 2.1.1 (core)
        signups 1.2.0 (core)
        source 2.0.12 (core)
        telemetry 2.0.0 (core)
        templates 55.1.0 (core)
        trust 2.0.3 (core)
        user 2.1.0 (core)
        @salesforce/sfdx-plugin-lwc-test 1.0.0 (core)
        asfdxtools 3.5.0 (link) C:\Projects\asfdxtools
        salesforce-alm 54.8.1 (core)

OS and Version:
        Windows_NT 10.0.22000

AmulyaRameshKumar avatar Aug 22 '22 15:08 AmulyaRameshKumar

I reproduced this issue in both pre-7.163.0 versions and post-7.163.0 versions if I do not compile the plugin after linking it. If, however, I compile the plugin I see the commands appear.

But, I see this behavior in both newer and older versions so I'm not convinced that that's the issue others are running into.

Can someone who's experiencing this try compiling the plugin to see if that resolves it?

mdonnalley avatar Aug 22 '22 17:08 mdonnalley

I reproduced this issue in both pre-7.163.0 versions and post-7.163.0 versions if I do not compile the plugin after linking it. If, however, I compile the plugin I see the commands appear.

But, I see this behavior in both newer and older versions so I'm not convinced that that's the issue others are running into.

Can someone who's experiencing this try compiling the plugin to see if that resolves it?

@mdonnalley can you provide steps to compile? That hasn't been part of our workflow and I can't find much documentation on that process but I'd be willing to try

slaght avatar Aug 22 '22 18:08 slaght

@slaght it should be a script defined in your plugin's package.json. For example,

  • https://github.com/billryoung/sfdx-wry-plugin/blob/master/package.json#L60
  • https://github.com/texei/texei-sfdx-plugin/blob/master/package.json#L83
  • https://github.com/salesforcecli/plugin-alias/blob/main/package.json#L91

mdonnalley avatar Aug 22 '22 18:08 mdonnalley

@mdonnalley tried linking the plugin both before and after installing it and did not resolve the issue. This is also on the new 7.164.2 release

slaght avatar Aug 22 '22 20:08 slaght

We faced the same problem with the same release versions. However based on the suggestion to "compile" we managed to solve the problem. We have a prepack command but that did not change anything. Instead running build

"build": "tsc -p .",

(Run with "npm run build") brought back the commands for a linked plugin.

Erisiel avatar Aug 30 '22 08:08 Erisiel

I am also seeing the same issue since last few releases of sfdx and it was definitely not present before. Another way of reproducing this issue is to generate plugin with sfdx and link it:

  1. sfdx plugins:generate ./plugin-test --defaults
  2. cd plugin-test/
  3. sfdx plugins:link .
  4. sfdx hello:org (this will throw an error that hello:org is not a sfdx command)

If I run npm run build in plugin-test directory I can get it to work. However, in the past it used to work properly without this additional step. You can see in the docs (https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_plugins.meta/sfdx_cli_plugins/cli_plugins_generate_scaffold.htm) that it was never required to compile the plugin as I believe sfdx should do it when plugin is linked.

filiprafalowicz avatar Sep 06 '22 12:09 filiprafalowicz

This issue has been linked to a new work item: W-11731121

git2gus[bot] avatar Sep 09 '22 15:09 git2gus[bot]

We are dealing with the same issue. I reproduced steps which filiprafalowicz wrote with 7.168.0, 7.163.0, 7.162.0, 7.160.0. It works perfectly fine with lower or equal version than 7.162.0.

What I noticed more, that if I try to run plugin by path, it returns something. For example, "bin/run hello" with 7.168.0 version CLI, it returns

VERSION
  168/0.0.1 win32-x64 node-v16.17.0

USAGE
  $ sfdx [COMMAND]

What worth mention "bin/run hello:org -u MyOrg" returns error.

When I execute the same command with 7.162.0 version, the output is correct

Commands to say hello.

USAGE
  $ sfdx hello:COMMAND

COMMANDS
  hello:org  print a greeting and your org IDs

I hope it will be useful somehow

acckamil97 avatar Sep 19 '22 15:09 acckamil97

This is effecting us as well. Grateful to the community posting here. Feels good to know that we're not alone.

pogilvieCB avatar Sep 23 '22 00:09 pogilvieCB

Same thing for us. Any timelines on having this fixed/workaround being provided which doesnt stop us from upgrading. There is a couple of things which are not working in new SF release due to not being able to upgrade the plugin.

DougMidgley avatar Oct 12 '22 08:10 DougMidgley

Been experiencing this, too. Last version works is 7.162.0.

mgalalm avatar Oct 26 '22 14:10 mgalalm

I also need resolution on this. Latest version I can use is 7.162.0.

jhgihub0 avatar Oct 27 '22 20:10 jhgihub0

Is there any update on status of work item W-11731121?

My team and I have had to pin our version to 7.162.0, we would really like to keep up to date so we can get access to new features and bugfixes but we are blocked from doing so until this issue is resolved.

alan-morey avatar Nov 14 '22 19:11 alan-morey

Yes I need an update as well.

jhgihub0 avatar Nov 15 '22 19:11 jhgihub0

Is there any update on this issue? We are still using 7.162.0 version as the others have mentioned above

amulyaramesh avatar Nov 30 '22 14:11 amulyaramesh

This issue is still on our backlog, but has yet to be prioritized.

peternhale avatar Nov 30 '22 15:11 peternhale