4

I'm currently attempting to migrate my existing production org to Salesforce DX. My production org has several managed packages that appear to be causing errors upon deploy to the scratch org.

One such managed package is the Slack managed package which causes this specific error : 'We couldn't retrieve the design time component information for component slack:postToSlack.' What is the process for migrating existing managed packages?

I created a Sandbox from Production and within the Sandbox I created an un-managed package containing all the metadata. I am able to retrieve the unmanaged package successfully through the metadata API.

I referenced this - https://developer.salesforce.com/blogs/developer-relations/2017/07/migrating-existing-projects-salesforce-dx.html

I also referenced - https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_intro_existing_app.htm

Below is a list of Slack specific errors:

force-app\main\default\flexipages\Account_Record_Page.flexipage-meta.xml : We couldn't retrieve the design time component information for component slack:postToSlack.
force-app\main\default\flexipages\Contact_Record_Page.flexipage-meta.xml : We couldn't retrieve the design time component information for component slack:postToSlack.
force-app\main\default\flexipages\Contact_Record_Page_Console.flexipage-meta.xml : We couldn't retrieve the design time component information for component slack:postToSlack.
force-app\main\default\flexipages\Lead_Record_Page_Console.flexipage-meta.xml : We couldn't retrieve the design time component information for component slack:postToSlack.
Improve this question
1

1 Answer 1

Reset to default
5

Managed packages, so far as I know (trying to migrate my company to SFDX myself as well) are not carried over to scratch orgs. I'm not familiar with the error that you're seeing, but if you happen to try to push code, fields, validation, etc... that make use of managed packages, sfdx has complained to me about "not able to deploy components in a different namespace than the current org" or something along those lines.

The workaround that I know of is to install managed packages after creating your scratch org.

It is another step in setting up a scratch org, but we do have the ability to install managed packages from sfdx

sfdx force:package:install --package 04t<and 12-15 more alphanumerics>

To figure out the id that you need to pass, you can use

sfdx force:package:installed:list -u <username or alias for an org with the package already installed>

For my org, the version of Slack that we have installed has a version Id of 04t41000002JvRyAAK (1.46.0.1)

Improve this answer
4
  • Thank you, I will work through that and see if I that resolves any of the many errors I have right now. Managed packages should be in our VC though right? As to have a true single point of truth for our orgs?
    – bemon
    Apr 17, 2018 at 17:28
  • 1
    @bemon No, managed packages (well, third party ones) should not be a part of your version control because you (as an end-user) don't have control over the managed package code. You wouldn't be able to deploy the code, even to a scratch org, because of the error I mentioned about the metadata api and namespaces. Besides, I'd imagine there would be a lot of angry ISVs if SFDX allowed anyone to view their source code.
    – Derek F
    Apr 17, 2018 at 17:57
  • 1
    Another option is to include the InstalledPackage metadata type in your SFDX repo. Deploying this to a scratch org should cause the scratch org to install the referenced managed packages at the specified version.
    – mpd106
    Apr 18, 2018 at 10:56
  • @mpd106 - I will look into that, did not see that before. Thanks!
    – bemon
    Apr 19, 2018 at 20:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.