Skip to content

Overhauled JavaScript stack trace parsing
Compare
Choose a tag to compare
@jongpie jongpie released this 08 Aug 18:08
· 23 commits to main since this release
v4.13.17
7a715d1
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.

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:

      image

    • Console output in Firefox:

      image

    • Console output in Microsoft Edge:

      image

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

image

Installation Info

Core Unlocked Package - no namespace

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

Contributors

jamessimone and ZackFra
Assets 2
Loading
0 Join discussion