1.42

Release notes for Pharos Triton 1.42 — LWC performance tracking, Apex governor-limit tracking, full Jest coverage, and Log__c metadata fixes.

Source commit: adaa303

Released: 2026-05-26

Highlights

• LWC performance tracking is now a first-class feature. A reworked triton.js, tritonBuilder.js, and tritonUtils.js introduce timeBackendCall, timeUserInteraction, trackComponentLifecycle, trackComponentRender, and startPerformanceMark/endPerformanceMark — all per-instance isolated and Locker Service-safe. See Profiling.

• Apex governor-limit tracking on TritonBuilder. New limitInfo(), limitInfoLite(), withFullLimitInfo(), and withoutLimitInfo() methods capture transaction usage and limits from System.Limits, plus a new Action__c field and action(String) builder method.

• Full Jest test coverage for triton, tritonBuilder, and tritonUtils, with a new TESTING.md, jest.config.js, and jest.setup.js at the repo root.

• pharos__Log__c metadata fixes. Missing XML attributes restored on all limit fields, plus permission set updates so the new fields are immediately readable/writable.

LWC performance tracking

The LWC module gains a complete performance-tracking surface that piggy-backs on the existing logger:

API	Purpose	Log type
bindToComponent(name)	Required anchor for all profiling APIs. Generates a per-instance UUID so multiple instances on a page stay isolated.	n/a
timeBackendCall(name, () => apexCall)	Wrap Apex calls; emits start/complete/failure logs with duration. Returns a PerformanceCallBuilder with four error-handling scenarios (default, withoutRethrow, withCustomErrorHandler, both).	TYPE.BACKEND_CALL
timeUserInteraction(name, async fn)	Wrap a higher-level user flow that may contain nested backend calls. Same builder/error-handling model.	TYPE.USER_INTERACTION
trackComponentLifecycle('connected'|'disconnected')	Log mount/unmount events per instance.	TYPE.COMPONENT_LIFECYCLE
trackComponentRender()	Increment a per-instance render counter and log it.	TYPE.COMPONENT_RENDER
startPerformanceMark(name) / endPerformanceMark(name)	Browser-style timing for arbitrary regions, isolated per component instance.	TYPE.PERFORMANCE

The TYPE enum has expanded accordingly:

export const TYPE = {
    BACKEND: 'Backend',
    FRONTEND: 'Frontend',
    BACKEND_CALL: 'BackendCall',
    COMPONENT_LIFECYCLE: 'ComponentLifecycle',
    COMPONENT_RENDER: 'ComponentRender',
    USER_INTERACTION: 'UserInteraction',
    PERFORMANCE: 'Performance'
};

Time measurement uses a Locker Service-safe helper that prefers performance.now() and falls back to Date.now() when the Performance API is restricted. Per-instance state (marks, render counts, lifecycle events) is keyed by componentName-uuid, so two instances of the same component on a page never collide.

Full walkthrough: Profiling.

Apex governor-limit tracking on TritonBuilder

TritonBuilder (Apex) now captures transaction usage from System.Limits directly onto the log record. There are two modes, controlled by builder methods that compose with the rest of the fluent API.

• limitInfoLite() — populates the essential set: SOQL queries/rows, DML statements/rows, CPU time, heap size, callouts (and their corresponding *_Limit__c companion fields).

• limitInfo() — calls limitInfoLite() and, if withFullLimitInfo() has been chained earlier, also captures the extended set: aggregate queries, SOSL queries, future calls, queueable jobs, email invocations, push notifications, batch (async) calls, publish-immediate DML — and their limits.

• withFullLimitInfo() — opt in to the extended set on the next limitInfo() call.

• withoutLimitInfo() — opt out entirely; limitInfo() becomes a no-op for this builder.

In addition, TritonBuilder exposes a new action(String) method that writes to the new Action__c field on pharos__Log__c. The field is used by the LWC performance-tracking layer to record method names, interaction names, and mark names, and is also available to Apex callers that want to tag logs with an action label.

pharos__Log__c field metadata fixes

All limit-related fields on pharos__Log__c had missing XML attributes that prevented some attributes from being recognized correctly. The affected fields:

• Batch_Jobs__c, Batch_Jobs_Limit__c

• CPU_Time__c, CPU_Time_Limit__c

• Callouts__c, Callouts_Limit__c

• DML_Rows__c, DML_Rows_Limit__c

• DML_Statements__c, DML_Statements_Limit__c

• Email_Invocations__c, Email_Invocations_Limit__c

• Future_Calls__c, Future_Calls_Limit__c

• Heap_Size__c, Heap_Size_Limit__c

• Publish_Immediate_DML__c, Publish_Immediate_DML_Limit__c

• Push_Notifications__c, Push_Notifications_Limit__c

• Queueable_Jobs__c, Queueable_Jobs_Limit__c

• SOQL_Aggregates__c, SOQL_Aggregates_Limit__c

• SOQL_Queries__c, SOQL_Queries_Limit__c

• SOQL_Rows__c, SOQL_Rows_Limit__c

• SOSL_Queries__c, SOSL_Queries_Limit__c

The new Action__c field was added under the same object.

Permission set updates

Both Triton_Read and Triton_Write permission sets were updated to include the new Action__c field and ensure consistent access to the fixed limit fields. After deploying 1.42, re-assign the permission sets (or refresh them via your deployment pipeline) so users pick up the new field-level access.

Test suite

A complete Jest test suite has been added under force-app/main/default/lwc/*/__tests__/:

• lwc/triton/__tests__/triton.test.js — full coverage of the core class, including PerformanceCallBuilder.

• lwc/tritonBuilder/__tests__/tritonBuilder.test.js — full coverage of the builder.

• lwc/tritonUtils/__tests__/tritonUtils.test.js — full coverage of utility helpers.

The repo now ships with babel.config.js, jest.config.js, jest.setup.js, and Jest-mock stubs under jest-mocks/ so contributors can run npm test out of the box. See TESTING.md in the Triton repo for the full developer workflow.

Upgrade notes

• No breaking API changes. All new LWC profiling methods and Apex builder methods are additive. Existing Apex and LWC callers continue to work unchanged.

• Permission sets must be re-assigned (or re-deployed) after upgrade so the new Action__c field and the fixed limit fields are visible to users.

• LWC profiling APIs require bindToComponent() first. If you call timeBackendCall, trackComponentLifecycle, etc. on an unbound instance, Triton emits a console warning and skips the call — nothing throws. Existing components that already bind for logging purposes get profiling support for free.

• Limit info is opt-in. Calling limitInfo() from Apex requires explicit invocation; existing builders won't suddenly start writing limit data unless you call it. Use withFullLimitInfo() to opt into the extended set.