sfp - flxbl package manager
#flxblsfopsSlackGitHub
  • Overview
  • Getting Started
    • Pre-Requisites
    • Install sfp
    • Configure Your Project
    • Build & Install an Artifact
    • Congratulations!
    • Docker Images
      • sfp-pro
  • CONCEPTS
    • Overview
    • SF CLI vs. SFP
    • Domains
    • Packages
    • Supported package types
      • Unlocked Packages
      • Org-Dependent Unlocked Packages
      • Source Packages
      • Diff Package
      • Data Packages
    • Artifacts
    • Package vs Artifacts
    • Identifying types of a package
    • Dependency management
    • Transitive Dependency Resolution
    • Destructive Changes
  • configuring a project
    • Project structure
    • Setup Salesforce Org
    • Creating a package
    • Defining a domain
    • Release Config
  • BUILDING ARTIFACTS
    • Overview
    • Determining whether an artifact need to be built
    • Building a domain
    • Building an artifact for package individually
    • Limiting artifacts to be built
    • Controlling aspects of the build command
      • Ignoring packages from being built
      • Building a collection of packages together
      • Selective ignoring of components from being built
      • Use of multiple config file in build command
    • Configuring installation behaviour of a package
      • Always deploy a package
      • Skip Install on Certain Orgs
      • Optimized Installation
      • Pre/Post Deployment Script
      • Reconciling Profiles
      • PermissionSet Assignment
      • Updating Picklist
      • Entitlement Deployment Helper
      • Field History & Feed Tracking
      • Aliasfy Packages
        • Aliasfy Packages - Merge Mode
      • State management for Flows
  • Installing an artifact
    • Overview
    • Controlling Aspects of Installation
    • Applying attributes of an artifact
    • BuiltIn Deployment Helpers
      • PermissionSet Group Awaiter
  • publishing and fetching artifacts
    • Publish Artifact
    • Fetching Artifacts
  • Releasing artifacts
    • Overview
    • Release Definitions
    • Generating a release definition
    • Generating a changelog
  • Validating a change
    • Overview
    • Different types of validation
    • Limiting Validation by Domain
    • Controlling validation attributes of a package
      • Skip Testing
      • Skip Coverage Validation
      • Test Synchronously
  • Analysing a Project
    • Overview
    • Duplicate Check
  • Environment Management
    • Pools
      • Scratch Org Pools
        • Defining a pool
        • Setting up your Salesforce Org for Scratch Org Pools
        • Pool Operations
          • Preparing pools
            • Handling dependencies
          • List Scratch Orgs in a pool
          • Fetch a scratch org
          • Delete Pools
      • Sandbox Pools
        • Sandbox Pool Initialization
        • Fetch a Sandbox from Pool
        • Monitor Sandbox Pools
    • Review Environments
      • Commands
        • Fetch a Review Environment
        • Check Review Environment Status
        • Extend a Review Environment
        • Transition Review Environment Status
        • Unassign a Review Environment
      • Considerations
    • Sandbox
      • Create Sandbox
      • Delete Sandbox
      • List Sandbox
      • Login to Sandbox
      • Update Sandbox
  • Development
    • Development Environment
    • Pull Changes from your org
    • Push Changes to your org
    • Dependency Management
      • Expand Dependencies
      • Shrink Dependencies
      • Explain Dependencies
  • Running sfp as a server
    • Introduction
    • sfp-pro-server: Architecture Overview (Alpha)
      • Task Processing System
      • Authentication & Security Architecture
      • Authentication System: Deep Dive
      • Database Architecture
      • Network Architecture and Integration System
      • Integration Architecture: Building Extensions
    • Installing SFP Server
    • Initializing SFP server
  • Metrics
    • Available Metrics
    • Custom Metrics
    • Configuring Collectors
      • Datadog
      • Splunk
      • New Relic
      • StatsD
  • Helpers
    • Managing Shared Resources
  • Command Guide
    • Core
      • Build
      • Quickbuild
      • Publish
      • Install
      • Release
    • Advanced
      • Validate
      • Artifacts
      • Changelog
      • Impact
      • Pool
      • Metrics
      • Repo
    • Utilities
      • Apex Tests
      • Flow
      • Dependency
      • Profile
  • FAQs
    • Common Errors
      • Org Shapes
      • Troubleshooting Unlocked Packages Build Failure Due to Code Coverage
    • Common Questions
      • Email Templates Deployment: Classic vs Lightning
      • Dealing with Long Build Times in Salesforce
      • Standard ValueSets and unlocked packages
      • Common Issues encountered with aliasfied packages
      • API Version
      • Understanding alwaysDeploy and skipIfAlreadyInstalled in Deployment Pipelines
    • sfp versioning and upgrade Process
  • References
  • Legal
    • Terms of Service for sfp
    • Terms of Service for 'sfp-pro' Software
  • LLMs.txt
Powered by GitBook
On this page

Was this helpful?

Edit on GitHub
Export as PDF
  1. CONCEPTS

Transitive Dependency Resolution

This feature is by default activated whenever build/quickbuild even in implicit scenarios such as validate, prepare etc, which might result in building packages.

Let's consider the following sfdx-project.json to explain how this feature works.

{
    "packageDirectories": [
       {
            "path": "./src/frameworks/sfdc-logging",
            "package": "sfdc-logging",
            "versionName": "Version 1.0.2",
            "versionNumber": "1.0.2.NEXT"
        },
        {
            "path": "./src/frameworks/feature-mgmt",
            "package": "feature-mgmt",
            "versionName": "Version 1.0.6",
            "versionNumber": "1.0.6.NEXT",
            "dependencies": [
                {
                    "package": "sfdc-logging",
                    "versionNumber": "1.0.2.LATEST"
                }
            ]
        },
        {
            "path": "./src/core-crm",
            "package": "core-crm",
            "versionName": "Version 1.0.4",
            "versionNumber": "1.0.4.NEXT",
            "dependencies": [
                {
                    "package": "feature-mgmt",
                    "versionNumber": "1.0.6.LATEST"
                }
            ]
        }
    ],
    "namespace": "",
    "sfdcLoginUrl": "https://login.salesforce.com",
    "sourceApiVersion": "60.0",
    "packageAliases": {
        "feature-mgmt": "0Ho5f000000GmkrCAC",
        "sfdc-logging": "0Ho5f000000GmerCAC",
        "core-crm": "0Ho5f000000Amz7CAC"
    },
    "plugins": {}
}

The above project manifest (sfdx-project.json) describes three packages, sfdc-logging, feature-mgmt., core-crm . Each package are defined with dependencies as described below

Package
Incorrectly Defined Dependencies

sfdc-logging

None

feature-mgmt

sfdc-logging

core-crm

feature-mgmt

As you might have noticed, this is an incorrect representation, as per the definitions of unlocked package, the package 'core-crm' should be explicitly defining all its dependencies. This means it should be as described below.

Package
Correctly Defined Dependencies

sfdc-logging

None

feature-mgmt

sfdc-logging

core-crm

sfdc-logging, feature-mgmt

To successfully create a version of core-crm , both sfdc-logging and feature-mgmt. should be defined as an explicit dependency in the sfdx-project.json

As the number of packages grow in your project, it is often seen developers might accidentally miss declaring dependencies or the sfdx-project.json has become so large due to large amount of repetition of dependencies between packages. This condition would result in build stage often failing with missing dependencies.

sfp features a transitive dependency resolution which can autofill the dependencies of the package by inferring the dependencies from sfdx-project.json, so the above package descriptor of core-crm will be resolved correctly to

 {
            "path": "./src/core-crm",
            "package": "core-crm",
            "versionName": "Version 1.0.6",
            "versionNumber": "1.0.6.NEXT",
            "dependencies": [
                  {
                    "package": "sfdc-logging",
                    "versionNumber": "1.0.2.LATEST"
                },
                {
                    "package": "feature-mgmt",
                    "versionNumber": "1.0.6.LATEST"
                }
            ]
        },
        

Please note, in the current iteration, it will autofill dependency information from the current sfdx-project.json and doesn't consider variations among previous versions.

For dependencies outside of the sfdx-project.json, one could define an externalDependencyMap as shown below

 "plugins": {
        "sfp": {
            "disableTransitiveDependencyResolver": true,
            "ignoreFiles": {
                "prepare": ".forceignore",
                "validate": ".forceignore",
                "quickbuild": "forceignores/.quickbuildignore",
                "build": "forceignores/.buildignore"
            },
            "externalDependencyMap": {
                "trigger-framework": [
                    {
                        "package": "0H1000XRTCam",
                        "versionNumber": "1.0.3.LATEST"
                    }
                ],
          }
      }
}

If you need to disable this feature and have stringent dependency management rules, utilize the following in your sfdx-project.json

An external dependency is a package that is not defined within the current repositories sfdx-project.json. Managed packages and unlocked packages built from other repositories fall into 'external dependency' bucket. IDs of External packages have to be defined explicitly in the packageAliases section.

"plugins": {
        "sfp": {
            "disableTransitiveDependencyResolver": true,
        }
    }

PreviousDependency managementNextDestructive Changes

Last updated 5 months ago

Was this helpful?