Overhauled JavaScript stack trace parsing

The changes in this release should not change anything about how you use Nebula Logger for JavaScript (JS) logging in lightning web components (LWCs) and Aura components - but the overall approach used internally by Nebula Logger for parsing JavaScript stack traces has been completely redesigned.

Previously, Apex code was used to parse JS stack traces (using the Apex classes LoggerStackTrace and ComponentLogger). But now, JS parsing occurs directly in JS, which provides several benefits:

• Bugfixes for several parsing issues: there have (apparently) been several problems in Nebula Logger for a year or two with parsing data from JS stack traces, due to factors like different browsers, how the logger LWC is leveraged, and in which of the available targets is used for your own LWCs/Aura components (which then call the logger LWC). This release should fix most of these issues.
• Code reuse & easier maintenance for Nebula Logger: the open source library JavaScript library stacktrace.js is now used to handle the majority of JS stack trace parsing, instead of trying to write code from scratch to handle parsing.
• Improved console logging statements in the browser's console: with a parsed version of the JS stack trace now available directly in JS, the logger LWC can now provide better context to JS developers trying to see the output of console statements when troubleshooting & debugging LWCs and Aura components.

Many thanks to @ZackFra for identifying the critical problems in the previous code & some approaches to use to resolve them (see PR #692). These contributions have led to identifying even more issues with the old approach that were previously unreported, and helped solidify the decision to migrate from Apex to JS for parsing JS stack traces.

And thanks to @jamessimone as well for all of his helping with questions & thoughts during the dev work, input on improving console logging statements, and code reviewing PR #692.

For a more details about the issues found & what's changed, see:

• Issue #691 - originally reported by @ZackFra, and includes the results of some of the issues found due to different browsers + different Salesforce contexts
• PR #692 - initial changes from @ZackFra to fix some issues, using the old Apex-based approach
• PR #727 - the changes merged for this release, which incorporates some concepts & changes from @ZackFra, but pivots from Apex to JS for parsing
• Issue #728 - this is one known issue that is not solved by this release. This will hopefully be addressed in a future release.

Core Unlocked Package Changes

• Fixed #691 by updating the logger LWC to leverage the open source library JavaScript library stacktrace.js to parse stack traces
  • Eliminated all of the Apex code in LoggerStackTrace and ComponentLogger that previously handled JS stack traces. There are still a few lingering items (enums, method overloads, etc.) that are now deprecated & will be removed in a future release
  • Added new js file loggerStackTrace.js to the logger LWC - the file contains a modified version of the parsing code from stacktrace.js, as well as a few additional pieces of logic to improve parsing of Salesforce-specific stack traces
• Improved the output of console logging statements. Each JS logging statement now includes a pretty-printed JSON string that has the most relevant info about the log entry's origin, including the timestamp of the log entry, the component name, function name, and the component metadata type

  • Console output in Chrome:

    

  • Console output in Firefox:

    

  • Console output in Microsoft Edge:

    

Recipes Metadata Changes

It took a lot of effort to even be able to test some of these issues, as Nebula Logger's repo previously didn't have sample metadata setup for most of the targets available for lightning components. This release includes several changes to make it easier to test logging in different targets in a scratch org, using multiple browsers. These changes are not included in Nebula Logger directly, but they help during development & testing. The changes include:

• Improving existing recipes metadata so that the 3 demo components (listed below) can now be easily tested in multiple contexts, using the Logger Recipes app
  • <c:loggerAuraEmbedDemo> Aura component
  • <c-loggerLWCEmbedDemo> LWC
  • <c-loggerLWCImportDemo> LWC
• Improving the Experience Cloud metadata stored in config (used by the pipeline & during development)
  • New(er) Lightning Web Runtime (LWR): Rebuilt the current Experience Cloud site to embed the recipes demo components in some pages to make them easy to test
  • Old Aura Framework: Created a second Experience Cloud site, using the older Aura framework template. This site makes it easy to test the same recipes demo components, using the older runtime, to ensure JS stack trace parsing works correctly

Now, the recipes app is setup to quickly test the 3 demo components in multiple targets

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.13.16...v4.13.17

• SF CLI: sf package install --wait 20 --security-type AdminsOnly --package 04t5Y0000015oPCQAY
• SFDX CLI: sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y0000015oPCQAY
• Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015oPCQAY
• Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015oPCQAY

Bugfixes for Scenario Rules

Core Unlocked Package Changes

• Fixed #538 by changing LogEntryEventHandler to always save LogEntryEvent__e records when LoggerSettings__c.DefaultPlatformEventStorageLoggingLevel__c is null. Thanks to @arbokrad for reporting this issue (and patience, as it's taken about a year to get this fixed 🙃 )
  • When previously using the user's logging level from LoggerSettings__c.LoggingLevel__c as a fallback value, it could result in entries being lost if a matching LoggerScenarioRule__mdt exists with a lower logging level
• Fixed some unreported issues in Logger with setScenario(String) and endScenario(String) not properly updating the field values returned by getUserSettings()
  • Now, both setScenario(String) and endScenario(String) wipe out & reload the in-memory instance of LoggerSettings__c (before applying any matching LoggerScenarioRule__mdt records) to ensure that there are not any remnants lingering when multiple LoggerScenarioRule__mdt records have been applied to the user's settings in a single transaction

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.13.15...v4.13.16

• SF CLI: sf package install --wait 20 --security-type AdminsOnly --package 04t5Y0000015oFjQAI
• SFDX CLI: sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y0000015oFjQAI
• Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015oFjQAI
• Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015oFjQAI

Deprecated & replaced BrowserUrl__c fields with new BrowserAddress__c fields

Thanks to @Ben-Nathan-CTM for reporting this bug!

Core Unlocked Package Changes

This release fixes #696 by making a couple of changes to how the browser's address is captured when logging in lightning components

• Updated the Apex class ComponentLogger to auto-truncate JS browser fields (including LogEntryEvent__c.BrowserUrl__c)
  • The public property ComponentLogger.ComponentLogEntry.browserUrl is now deprecated & will be deleted in a future release. It's only intended to be used internally by Nebula Logger, so this hopefully doesn't impact anyone - but mentioning it here, just in case 😉
• Replaced the text (255) fields BrowserUrl__c on LogEntryEvent__e and LogEntry__c with new long textarea (2000) fields BrowserAddress__c
  • The existing BrowserUrl__c fields are too short to store some long URLs (such as URLs with a lot of parameters), and the existing fields can't be converted from text(255) to long text area fields, so new fields are needed
  • The existing BrowserUrl__c fields will still be populated for foreseeable future (with a truncated value), but they are now considered deprecated - any references in reports, list views, queries, etc. should be updated to use the new BrowserAddress__c fields
• Documentation: added missing data classification metadata to several existing browser fields on LogEntryEvent__e and LogEntry__c
  • This doesn't impact any functionality, it's just for documentation purposes

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.13.14...v4.13.15

• SF CLI: sf package install --wait 20 --security-type AdminsOnly --package 04t5Y0000015oF5QAI
• SFDX CLI: sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y0000015oF5QAI
• Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015oF5QAI
• Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015oF5QAI

Custom Field Mappings Support

Thanks to @pankaj0509 and @codejester90 for suggesting this enhancement & providing some great feedback!

Core Unlocked Package Changes

This release resolves #655 by adding support for defining, setting, and mapping custom fields within Nebula Logger's data model. This is helpful in orgs that want to extend Nebula Logger's included data model by creating their own org/project-specific fields.

Adding custom fields to the platform event LogEntryEvent__e

To get started, the first step is to add a field to the platform LogEntryEvent__e`

• Create your own custom fields on LogEntryEvent__e. Any data type supported by platform events can be used.

  • In this example, a custom text field called SomeCustomField__c has been added:

    

• Populate your own custom fields in Apex by calling one of the two new instance methods on LogEntryEventBuilder:

  1. setField(Schema.SObjectField field, Object fieldValue)
  2. setField(Map<Schema.SObjectField, Object> fieldToValue)

For now, this functionality is available in Apex. Long-term, equivalent functionality will hopefully be added for Flow & Lightning Components. Here is an example of using the 2 new methods in Apex:

Logger.info('hello, world')
    // Set a single field
    .setField(LogEntryEvent__e.SomeCustomTextField__c, 'some text value')
    // Set multiple fields
    .setField(new Map<Schema.SObjectField, Object>{
        LogEntryEvent__e.AnotherCustomTextField__c => 'another text value',
        LogEntryEvent__e.SomeCustomDatetimeField__c => System.now()
    });

Adding custom fields to the custom objects Log__c, LogEntry__c, and LoggerScenario__c

If you want to store the data in one of Nebula Logger's custom objects, you can follow the above steps, and also...

• Create an equivalent custom field on one of Nebula Logger's custom objects - right now, only Log__c, LogEntry__c, and LoggerScenario__c are supported.

• In this example, a custom text field also called SomeCustomField__c has been added to Log__c object - this will be used to store the value of the field LogEntryEvent__e.SomeCustomField__c:

  

• Create a record in the new CMDT LoggerFieldMapping__mdt to map the LogEntryEvent__e custom field to the custom object's custom field, shown below. Nebula Logger will automatically populate the custom object's target field with the value of the source LogEntryEvent__e field.

  • In this example, a custom text field called SomeCustomField__c has been added to both LogEntryEvent__e and Log__c.

    

New extra-tests Metadata

To help with testing Nebula Logger, a few new metadata items have been added to the extra-tests directory. This directory is not included in any of Nebula Logger's packages - its metadata is used to help both with automated tests in the pipeline, as well as manual functional tests.

• Added some new custom fields for the objects LogEntryEvent__e, Log__c, LogEntry__c, and LoggerScenario__c to the extra-tests directory to provide sample fields that are only used for testing the custom field mapping functionality
• Added some new CMDT records for the new object LoggerFieldMapping__mdt. These records map the (new) included custom fields (mentioned above)

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.13.13...v4.13.14

• SF CLI: sf package install --wait 20 --security-type AdminsOnly --package 04t5Y0000015oE2QAI
• SFDX CLI: sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y0000015oE2QAI
• Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015oE2QAI
• Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015oE2QAI

Improved Fully-Qualified References

Since the unlocked package does not have a namespace, orgs can encounter installation errors for Nebula Logger if the target org has any custom Apex code (classes, enums, interfaces, etc.) with the same name as standard class in the Schema or System namespace (referred to as name shadowing).

This is the same concept & approach as the changes made in several previous releases (listed below) - but my hope is that this PR finally finishes this effort, and all references are now fully qualified.

• v4.9.0
• v4.9.4
• v4.9.6
• v4.12.5

This shouldn't cause any functional changes to Nebula Logger - this is to tidy up existing references to avoid name collisions so that more orgs can use the unlocked package.

Core Unlocked Package Changes

Apex Code Changes

• Switched to using fully-qualified references for these standard classes in the Schema and System namespaces :

  • Schema namespace standard classes
    • ApexClass → Schema.ApexClass
    • ApexEmailNotification → Schema.ApexEmailNotification
    • ApexTrigger → Schema.ApexTrigger
    • AsyncApexJob → Schema.AsyncApexJob
    • BatchApexErrorEvent → Schema.BatchApexErrorEvent
    • CustomPermission → Schema.CustomPermission
    • DisplayType → Schema.DisplayType
    • FlowDefinitionView → Schema.FlowDefinitionView
    • FlowExecutionErrorEvent → Schema.FlowExecutionErrorEvent
    • FlowVersionView → Schema.FlowVersionView
    • PermissionSet → Schema.PermissionSet
    • PermissionSetAssignment → Schema.PermissionSetAssignment
    • SoapType → Schema.SoapType
    • UserRecordAccess → Schema.UserRecordAccess
    • UserRole → Schema.UserRole
  • System namespace standard classes
    • BatchableContext → System.BatchableContext
    • Comparable → System.Comparable
    • Database → System.Database
    • EventBus → System.EventBus
    • FinalizerContext → System.FinalizerContext
    • InstallHandler → System.InstallHandler
    • JSON → System.JSON
    • Matcher → System.Matcher
    • Pattern → System.Pattern
    • PicklistEntry → System.PicklistEntry
    • Queueable → System.Queueable
    • QueueableContext → System.QueueableContext
    • Quiddity → System.Quiddity
    • Request → System.Request
    • RestContext → System.RestContext
    • RestRequest → System.RestRequest
    • RestResponse → System.RestResponse
    • Schedulable → System.Schedulable
    • SchedulableContext → System.SchedulableContext
    • Search → System.Search
    • TriggerOperation → System.TriggerOperation
    • UUID → System.UUID

• Scope creep: fixed some flaky tests in LogBatchPurgeController_Tests

extra-tests Metadata Changes

• Moved the existing name-shadowing classes in the extra-tests directory to be in separate subdirectories (one for each namespace, Schema and System)
• Added several new name-shadowing classes for all of the Schema & System references (mentioned above) that are now using fully-qualified references
  • These classes are deployed in Nebula Logger's pipeline to enforce that the codebase uses fully-qualified references

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.13.12...v4.13.13

• SF CLI: sf package install --wait 20 --security-type AdminsOnly --package 04t5Y0000015oDsQAI
• SFDX CLI: sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y0000015oDsQAI
• Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015oDsQAI
• Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015oDsQAI

Added refresh button + spinner on relatedLogEntries LWC

Thanks to @andrii-solokh for implementing this enhancement! (PR #703)

Core Unlocked Package Changes

• Added new refresh button on the LWC relatedLogEntries. This makes it easy to refresh just the list of LogEntry__c records, without having to refresh the entire page

  • When refreshing the data, a lightning-spinner is now overlayed on the LWC

  

New extra-tests Metadata

• Added sample flexipage Nebula_Logger_Account_Record_Page that's used as the org default for the Account object when deploying Nebula Logger's extra-tests folder - this makes it easy to test the LWC relatedLogEntries in a scratch org

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.13.11...v4.13.12

• SF CLI: sf package install --wait 20 --security-type AdminsOnly --package 04t5Y0000015oCkQAI
• SFDX CLI: sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y0000015oCkQAI
• Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015oCkQAI
• Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015oCkQAI

Added tracking of logging user's federation identifier

Core Unlocked Package Changes

This release adds new fields & automation to track the logging user's federation identifier - this field is used in SAML SSO (Single Sign-On) settings, and is often a person's unique identifier in multiple systems. By capturing it in Nebula Logger, it makes it easier for Salesforce logs to be tied to logs for the same user in other systems.

• Added new long textarea (512) fields LoggedByFederationIdentifier__c on LogEntryEvent__e and Log__c to track the value of Schema.User.FederationIdentifier for the logging user

• Added new field Log__c.HasLoggedByFederationIdentifier__c to make it easier to filter/identify records where the user's federation ID has been populated

• Added field-level security (FLS) for the new Log__c fields to the permission sets LoggerAdmin, LoggerLogViewer, and LoggerEndUser

• Added new field Log__c.LoggedByFederationIdentifier__c to the flexipage LogRecordPage - it conditionally shows, based on the value of the other new field, Log__c.HasLoggedByFederationIdentifier__c

  

Big Object Archive Plugin Changes

• Renamed the Big Object index LogEntryArchiveIndex.indexe-meta.xml to LogEntryArchiveIndex.index-meta.xml (indexe --> index) to fix an issue with newer versions of the sf cli
  • This doesn't impact any functionality in the plugin, so there is not a new release for the plugin - just a small change to the metadata in the repo

Pipeline Changes

• Deleted several old scripts in package.json and in the directory ./scripts/build
• Upgraded package dependencies & regenerated package-lock.json
• Tweaked config in .prettierrc
• Updated GitHub Actions in build.yml to use v4 (compatible with Node 20)

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.13.10...v4.13.11

• SF CLI: sf package install --wait 20 --security-type AdminsOnly --package 04t5Y0000027L98QAE
• SFDX CLI: sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y0000027L98QAE
• Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000027L98QAE
• Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000027L98QAE

AuthSession Bugfix for LWC Logging

Thanks to @Suryansh-2301 for reporting this bug!

Core Unlocked Package Changes

• Fixed #678 by removing the filter ParentId = null when querying AuthSession data in LoggerEngineDataSelector
• Added a small enhancement to store the ParentId of the AuthSession record in the new fields LogEntryEvent__e.ParentSessionId__c and Log__c.ParentSessionId__c

  • Updated permission sets LoggerAdmin, LoggerLogViewer, and LoggerEndUser to provide read access to the new field Log__c.ParentSessionId__c

  • Updated FlexiPage LogRecordPage to conditionally display the new field Log__c.ParentSessionId__c when it's populated

    

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.13.9...v4.13.10

• SF CLI: sf package install --wait 20 --security-type AdminsOnly --package 04t5Y0000027L04QAE
• SFDX CLI: sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y0000027L04QAE
• Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000027L04QAE
• Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000027L04QAE

Updated Logging Level Emojis

Thanks to @twentyTwo for suggesting & implementing these changes, and thanks to @PawelWozniak for the feedback!

Core Unlocked Package Changes

• Closed #665 in PR #672 by updating the formula field LogEntry__c.LoggingLevelWithImage__c to use different emojis for every logging level to make it easier to visually distinguish between them. Previously, the same emoji was used for DEBUG, FINE, FINER, and FINEST. The new list of emojis used are:
  • ERROR => ⛔
  • WARN => ⚠️
  • DEBUG => 🐞
  • INFO => ℹ️
  • FINE => 👍
  • FINER => 👌
  • FINEST => 🌟

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.13.8...v4.13.9

• SF CLI: sf package install --wait 20 --security-type AdminsOnly --package 04t5Y000001MkHqQAK
• SFDX CLI: sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y000001MkHqQAK
• Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001MkHqQAK
• Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001MkHqQAK

Fixed logEntryMetadataViewer LWC's 'View Full Source' button not showing for non-admins

Core Unlocked Package Changes

• Worked with @jamessimone to troubleshoot & fix some additional issues in the logEntryMetadataViewer LWC that prevented the 'View Full Source' button from showing up for non-admins. This involved 3 related changes

  1. Added ApexClass access in the permission sets LoggerAdmin, LoggerLogViewer, LoggerEndUser for the Apex class LogEntryMetdataViewerController to fix some permission errors that could occur in some orgs/situations.
  2. Fixed some excessively large whitespace in the LWC caused by a present-but-not-visible spinner.
  3. Updated the logEntryMetadataViewer LWC to imperatively call Apex controller methods - using the @wire annotation caused weird, silent failures when calling the Apex methods, but calling it imperatively seems to work wonderfully (and is more consistent with how the other LWCs in Nebula Logger are written).

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.13.7...v4.13.8

• SF CLI: sf package install --wait 20 --security-type AdminsOnly --package 04t5Y000001MkHbQAK
• SFDX CLI: sfdx force:package:install --wait 20 --securitytype AdminsOnly --package 04t5Y000001MkHbQAK
• Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001MkHbQAK
• Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y000001MkHbQAK