Skip to main content

I am trying to move to using Salesforce DX with the package development model. I’m currently packaging some of our customizations that include Skuid pages. Once I create the scratch org and push my local project to the scratch org I always have to use “sfdx force:skuid:push” to push the pages to the scratch org after I install the Skuid package.


I’m looking for a way to include the skuid pages in the package.xml or somehow script the push of skuid pages into the “sfdx force:source:push” command to where I can include everything in a local project and spin up a scratch org in one command.


When I run “sfdx force:souce:push” and include Skuid as an installed package it installs Skuid correctly, but the push fails because I cannot push the skuid pages that my customizations require before Skuid is installed and I can’t figure out a way to include the skuid pages on the initial push"


To recreate the problem:


Try to create a scratch org with a lightning record page that uses the Skuid Page Component and refers to a Skuid Page. Include the Skuid Installed Package too. The deployment will fail because the Skuid page refered in the Skuid Page Component doesn’t exist.


Workaround: Install Skuid as a package first and then push the skuid pages and then push the rest of your deployment.

  1. I like where you are going Sam. Source Oriented development is where you want to be. SFDX is the bomb. But it adds some interesting complexity to the situation. Here are some thoughts.

    Because Skuid Metadata (pages) are not recognized by the SFDC Metadata API you cannot simply put them in the package.xml and get them deployed. Sorry.




So you have to deploy your pages as a separate step. Using the sfdx force:source:push command is one way to do this. But as you have found it has to occur after your primary package implementation.
One solution I've seen is the creation of a larger shell script that does multiple implementation steps. You clone the repo - run the shell script and it does the package install and the skuid page implementation.

I’m pretty sure that packages can define “post install steps” where Apex is run. You could use our Page Unpack apex methods (as described here


  1. )

The core issue is that Skuid page metadata is really “data” for salesforce. So you can look at how others are doing data installation as part of their sfdx packaging process. The idea of “Data as metdata” is common with CPQ apps and other complicated configuration utilities. Deployment and distributed development using these apps is tough.


I’d love to hear what you come up with. Its a topic that I continue to follow here, and want to work to make better.

Sam,


Also, just to verify, are you already working with the Skuid CLI? That may help, as well as our skuid-sfdx tool (an open-source tool for deploying Skuid pages to your Salesforce instance). If you haven’t tried those yet, I think that would be worth looking into. You could incorporate these commands into your script for deploying to your scratch org.


Emily

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings