v4.13.17 - Overhauled JavaScript stack trace parsing

[jongpie]

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 logger does not list component type when used in aura component #691 - originally reported by @ZackFra, and includes the results of some of the issues found due to different browsers + different Salesforce contexts
• PR bugfix/aura-logging #692 - initial changes from @ZackFra to fix some issues, using the old Apex-based approach
• PR Overhauled JavaScript stack trace parsing #727 - the changes merged for this release, which incorporates some concepts & changes from @ZackFra, but pivots from Apex to JS for parsing
• Issue JavaScript stack traces can still be inaccurate due to createLogger() being async  #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 logger does not list component type when used in aura component #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

---

This discussion was created from the release Overhauled JavaScript stack trace parsing.