Package Dependencies Overview

For ISVs & consultants building Salesforce packages (1GP or 2GP), Nebula Logger can be integrated into your package to provide logging capabilities. But there is not one approach that works for everyone in all situations, so there are 4 ways currently supported for leveraging Nebula Logger in your own package:

1. No Dependency, By Bundling Nebula Logger's Metadata

All of Nebula Logger's metadata is open source & available in GitHub. You can include all of its metadata in your own package, and have full control

• ✅ ISVs/consultants have full control - they can customize their copy of Nebula Logger's metadata as much as they want
• ❌ This puts more work on ISVs/consultants - a copy of Nebula Logger needs to be added/maintained within their package
• ❌ If a customer does have Nebula Logger installed, then logging data is fragmented in the org: customer logs are stored in their installed version of Nebula Logger, and the ISV package's logs are stored in its own copy of Nebula Logger's objects.

2. Required Package Dependency, By Requiring Nebula Logger's Package to be Installed

Add a required dependency to your package for one of Nebula Logger's packages (typically the managed package, since it has a namespace)

• ✅ Great for customers that already use Nebula Logger in their org
• ❌ Customers that don't have Nebula Logger installed cannot install the ISV package

3. Optional Package Dependency, Using Extension Packages + Configuration

Add an optional dependency to your package, using extension packages + adding some additional metadata + dynamic Apex code in your own package.

• ✅ Great for ISVs/consultants that want to be able to easily swap out what logging tool is used
• ✅ Customers that don't have Nebula Logger installed can still install the core ISV package
• ❌ It adds complexity to the package to support this, as well as the need to create 1 or more extension package
• ℹ️ This approach is used in Apex Rollup
  • The unlocked package has no dependencies / it can be installed independently of any other packages
    • Out of the box, it has its own logger class, but has been designed to use dependency injection using an ILogger interface, so custom loggers can be created or installed in each customer's org
  • When customers have both Apex Rollup & Nebula Logger installed, they can install Apex Rollup's optional Nebula Logger plugin package
    • This package has dependencies on both Apex Rollup's unlocked package & Nebula Logger's unlocked package, and the same concept should work if you'd rather depend on the managed package version of Nebula Logger (instead of the unlocked)

4. Optional Package Dependency, Using Apex's Callable interface

Add a loosely-coupled optional dependency, by using Nebula Logger via Apex's Callable interface

• ✅ Great for ISVs/consultants that want to be able to easily swap out what logging tool is used
• ✅ ISVs/consultants packages don't have to have any direct dependency on Nebula Logger - but when Nebula Logger is available in a customer org, it can be leveraged
• ✅ ISVs/consultants don't need to create extension packages
• ✅ Customers that don't have Nebula Logger installed can still install the ISV package
• ❌ Only supports logging in Apex / does not handle dynamic logging in Flow & Lightning Components
• ❌ Relies on String and generic Object values, which are error-prone, and don't provide compilation errors