Plugin got broken after CLI update

[patrykacc]

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

[github-actions]

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.

[mdonnalley]

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

Are you able to provide steps to reproduce?

[slaght]

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.

[warbio]

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.

[hansds]

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

[mdonnalley]

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!

[hansds]

@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.

[mdonnalley]

@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?

[hansds]

@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...

[mdonnalley]

@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

[uwe-voellger]

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.

[javierCTL]

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.

[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

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

[AmulyaRameshKumar]

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

[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?

[slaght]

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

[mdonnalley]

@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

[slaght]

@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

[Erisiel]

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.

[filiprafalowicz]

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.

[git2gus]

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

[acckamil97]

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

[pogilvieCB]

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

[DougMidgley]

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.

[mgalalm]

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

[jhgihub0]

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

[alan-morey]

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.

[jhgihub0]

Yes I need an update as well.

[amulyaramesh]

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

[peternhale]

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

[adammyhre]

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

@peternhale How can we get this issue prioritized? We are unable to update beyond version 7.162.0 because of this.

@mdonnalley , @shetzel , @mshanemc

[mshanemc]

If you're linking a local plugin, it sounds like "build/compile it first" is a good workaround. Other options would be installing the plugin the normal way (ex sfdx plugins:install texei-sfdx-plugin)

What's the situation where you can't use either of those options?

Linked plugins are meant for the plugin developer to be able to test their changes locally before going through the npm publish process, where they probably re-build/compile stuff regularly).

[alan-morey]

@mshanemc The "build/compile it first" used be come for free before, or so it seemed that way.

In our particular case, we don't publish our sfdx plugin to any kind of npm registry, we have it as a sub directory in our source repository that houses our force-app. We link it once after cloning the source repository and then the plugin would just work, even if we changed branches and those branches contained new commands/topics in the plugin. So it's always in a "development" state and this has worked great for us for many years up to v7.162.0 but after that this is no longer the case.

It's been a while since I read the entire documentation for the plugin development but the documentation page Scaffold a Salesforce CLI Plug-In does not mention build/compile. If it is a requirement to build/compile before running commands then maybe the documentation should be updated to explain that and also show the necessary commands to build/compile?

[mshanemc]

It's definitely a bug and not an intentional change. 😄

There's a lot of comments saying it's blocking people from using newer CLIs, but to prioritize this vs other work it would be helpful to understanding why they're blocked when there's a few pretty good workarounds.

[jhgihub0]

Where are the workarounds for us to see if that will work?

[mshanemc]

Where are the workarounds for us to see if that will work?

1. Plugin got broken after CLI update #1664 (comment)
2. use sfdx plugins:install instead of sfdx plugins:link [the original issue related to the texei plugin which is definitely published]

A happy side effect from workaround #2 is that it'll save you some CI time

[DougMidgley]

@mshanemc this isnt really a workaround for many enterprises. If they need to keep the dev private and dont have a private registry available then it wont work last i checked. This means for those clients we are stuck with 162. Why would we upgrade? well, while its not urgent, many times it has newer support for newer features which we sometimes need to upgrade to (release updates for example)

[mshanemc]

@DougMidgley what prevents you from adding a build/compile step before plugins:link ?