Skip to main content

#Second Generation Packages토론 중인 항목 0개

I've successfully released a Second Generation Unlocked Package that relies on two separate First Generation Managed Packages.

 

The Second Generation Unlocked Package and First Generation Managed Packages are in separate Developer Hubs. 

 

This dependancy has currently been defined using the 04t IDs for the 1GP Managed Package Versions. 

 

This means that when the 1GP Managed Packages are updated I'll also have to manually update the 2GP to rely on the new version. 

 

Is there are a better way to handle this? 

 

cc @Pronit Agrawal

 

#Unlocked Packages #Second Generation Packages #Package Dependency 

답변 3개
  1. 2025년 1월 21일 오후 2:16

    There is no automated way to do this but also remember that dependencies are a "minimum version" NOT an exact version. This means you only need to update your dependencies if you are changing your package to directly reference new features/metadata in the 1GP packages that a new to the 1GP package. You can leave you dependencies for a long time but still install the latest 1GP package versions and Salesforce will happily allow installing your 2GP as well.

0/9000

I've built a 2GP Package that I am trying to release as a Unlocked Package.

 

I've overcome various validation errors due to missing features or settings in my Scratch Org Definition file. 

 

However my package includes a Sharing Set which depends on the Contact being 'Private' and by default its 'Controlled by Parent', is there a way to define this feature/setting in my Scratch Org Definition File? 

 

@* Experience Cloud * @*Experience Cloud Developers* @Unlocked Packages  @Salesforce DX @* Salesforce Platform *

 

#Salesforce CLI #SFDX CLI #Salesforce Platform #Unlocked Packages #Unmanaged Package #Second Generation Packages #Scratch Org Definition #Experience Cloud #Experience Builder

답변 2개
  1. 2024년 12월 4일 오후 2:18

    @Tom Bassett this might help you - https://salesforce.stackexchange.com/questions/218183/sfdx-sharing-settings-scratch-orgs

     

    Is your package ultimately intended for public consumption, or are you just using it internally with your own org(s)?  Deploying sharing-related settings on standard objects can be tricky because the destination org may have valid reasons for how sharing is configured on their standard objects and can't change to support your package.

0/9000

Hi all!

 

I want to share with you the article about Second-Generation packages in Salesforce from my SF Dev colleague.  He collected all the features and the main differences between 1GP and 2GP there. It's just a personal experience, so maybe you will find it useful. 

Hi all! I want to share with you the article about Second-Generation packages in Salesforce from my SF Dev colleague. He collected all the features and the main differences between 1GP and 2GP there.

 

#Salesforce Developer #Package Installation #Second Generation Packages 

댓글 2개
0/9000

Hello Guys,

 

I am new to Second Generation Packages and trying to get some guidance from experts who have already worked on it before. 

 

I have a quick question on the best practices for managing the Parter Business Org when developing Second Generation Packages. As Parter Business Org act as the Dev Hub for the second generation packaging and the dev hub owns the packages (which can not be changed once the package is generated), what is the best practice on handling CI/CD process. Before we deploy the final package to production which will be on Parter Business Org Dev Hub org, we need to build and test the packages many times as beta features in a CI org. We many times need to have many CI processes which will have the same package names. These are just beta packages and we don't want to deploy these to the Parter Business Org yet.

 

So what is the best practices being followed for this? Do you guys use the same Parter Business Org for all these purposes (I hope this is not the case) or you guys request new org with dev hub for incorporating CI/CD purposes.

 

I would like to get some suggestion on what is the best practices being followed in this.

 

Thanks,

Bikram.

0/9000

Team Dx - I have encountered the following issue while creating a second generation packaging, Details below

Source used: Dreamhouse app from github -  https://github.com/dreamhouseapp/dreamhouse-sfdx

And when i tried to create a package version with the same source, i encountered an error of Metadata unavailability, sfdx force:package:version:create which resulted "These entities are not supported: [PathAssistant]". I was able to successfully create the package version and uninstall it after i removed path configurations from my source.

My question : When will path configuration be available in 2GP ? And what are the other such entities which are not supported by 2GP?(I couldn't find anything in the documentation)

Any help / suggestions would be greatly appreciated.

FYR @Angela McCole 

댓글 3개
  1. 2019년 8월 7일 오후 7:48
    @Krupananda Reddy Maneri We were able to successfully add a path assistant to a 2nd gen unlocked package in our org. Path assistant also shows as supported in the metadata coverage report (https://developer.salesforce.com/docs/metadata-coverage/46). I'd suggest double-checking how your project json file is set up. If you're still stuck you could try posting your config files here or maybe premier support could help you troubleshoot.
0/9000
Dan Smith (Finning Int) 님이 Salesforce DX에 글을 올렸습니다

Question about best practice for SFDX package versioning with automated builds and deployments:

 

At present we use git workflow which consists of a master, uat and develop branch. Each branch triggers a build following a successful pull request. When the build runs for the develop branch, it validates the dx project by creating a new scratch org and pushing metadata etc. Following this, it creates a new package version of the metadata and then kicks off a deployment. The deployment installs the new package version into a developer sandbox, along with its dependent packages (using a custom script).

 

I am now facing a challenge with configuring the build and deployment for the uat branch. The deployment this time will install the package and dependent packages into a shared environment which is used for the UAT of all apps we have. The problem and confusion I have run into is around how I version the package following the successful build of the uat branch. Commits that are pushed into the uat branch are always behind develop , as you may expect. So I really don't want to be creating a new package version for the uat build which is likely to be behind develop.

 

I have thought of two alternative approaches here

 

  1. When building from the uat  branch, increment the major or minor version of the package (the develop branch would then need modifying to increment the version there too).
  2. Rather than creating a new package version for each build of develop, only create a new package version for the uat  build. (I'm less in favour of this as we would then need to deploy the metadata rather than installing a new package version into the dev sandbox)

Does anyone have any ideas as to how I best go about this?

댓글 6개
  1. 2018년 8월 31일 오후 9:10
    I'm thinking the best approach for us is to aim to push bug fixes to the develop branch, but in situations where bug fixes need to be deployed into UAT with urgency I'll create a short-lived patch branch. @Sanchivan Sivadasan what are your thoughts?
0/9000

I am trying to promote an unlocked package. I get an error that I do not have the right permissions. The DevHub user has the following permission:

  • System Permissions > Create and Update Second-Generation Packages

Are there any other permissions needed not stated in the Salesforce DX documentation?

Strange thing is I did release packages the past.

댓글 5개
0/9000

Hi Everyone, I am new to #Second Generation Packages . It has lot of advantages I feel. But does I am wondering is it possible to auto install all the dependencies when installing a package like with npm project etc. Because that will be awesome . I am not able to find anything which supports this theory but would be great if I get some pointers.    

댓글 1개
  1. 2018년 7월 17일 오후 2:37
    @Vivek Deepak - For Winter '19 (safe harbor), we are working to expose info about dependent packages so that the installation of dependent packages can be scripted.
0/9000

Hi,

 

I am unsure if I have the dependencies working for my package. After creating two packages I expected a package with any dependencies would automatically install those dependencies.

 

Instead I got this error message:

$ sfdx force:package:install -i 04t0N000000LFFdQAO -u EmptyOrg1

...

$ sfdx force:package:install:get -i 0Hf0E0000008STCSA2 -u test-few5zg80loix@nelson_company.net

ERROR:  Encountered errors installing the package!,Installation errors:

1) Variable does not exist: CoreController, Details: FeatureOneController: Variable does not exist: CoreController

 

I have the following folder structure 

├── README.md

├── config

│   └── project-scratch-def.json

├── core

│   └── main

│       └── default

│           ├── aura

│           └── classes

│               ├── CoreController.cls

│               └── CoreController.cls-meta.xml

├── feature-one

│   └── main

│       └── default

│           ├── aura

│           └── classes

│               ├── FeatureOneController.cls

│               └── FeatureOneController.cls-meta.xml

└── sfdx-project.json

 

The sfdx-project.json file looks like this:

{

"packageDirectories": [

{

"path": "core",

"default": true,

"id" : "0Ho0N0000004C9XSAU",

"versionNumber" : "0.0.0.NEXT",

"versionDescription" : "Core 0.0.0.1",

"versionName": "Core1V0.0.0.1"

},

{

"path": "feature-one",

"id" : "0Ho0N0000004C9cSAE",

"versionNumber" : "0.0.0.NEXT",

"versionDescription" : "Feature One 0.0.0.2 this package has the dependency on core",

"versionName": "Feat1V0.0.0.2",

"dependencies": [

{

"packageId": "0Ho0N0000004C9XSAU",

"versionNumber": "0.0.0.LATEST"

}

]

}

],

"namespace": "HelloDemo01",

"sfdcLoginUrl": "https://login.salesforce.com",

"sourceApiVersion": "41.0"

}

 

That original json file will build the packages I want but I need to install my core package if I want feature-one to install. Dependencies aren't installed automatically, is that not expected?

 

I also tried changing my dependencies to list the subscriber id like this (https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp_config_dependencies.htm)

 

"dependencies": ["04t0N000000L8AQQA0"]

 

I get this error when I try and rebuild the package:

 

$ sfdx force:package2:version:create -i 0Ho0N0000004C9cSAE

ERROR:  Dependency must specify either a subscriberPackageVersionId or both packageId and versionNumber: "04t0N000000L8AQQA0".

 

Thanks

Nelson

댓글 5개
0/9000