一键导入
uxlog-usage
// How to pick the correct uxLog level (action, log, warning, error, success, other), the matching chalk color, sensitive logging, VS Code UI suppression, and uxLogTable. Use when adding or modifying any uxLog call.
// How to pick the correct uxLog level (action, log, warning, error, success, other), the matching chalk color, sensitive logging, VS Code UI suppression, and uxLogTable. Use when adding or modifying any uxLog call.
Style rules for updating CHANGELOG.md entries. Use whenever the user asks to update, add to, or write entries in CHANGELOG.md.
Implement a feature, bug fix, or code change in sfdx-hardis. Use whenever the user asks to add a feature, fix a bug, implement something, or make a code change - with or without a prior /design phase.
Watch the GitHub PR for the current branch, wait for CI to finish, and autonomously fix failing jobs by reading logs, editing sources, and pushing. Stops cleanly when stuck.
Decision framework for fixing jscpd (copy-paste detector) errors. Use when asked to fix jscpd issues, copy-paste errors, clones or COPYPASTE lint failures.
sfdx-hardis project architecture, technology stack, provider pattern, configuration system, and project structure. Use when working with project structure, providers, hooks, or config.
How sfdx-hardis monitoring commands, notification types, frequency, and per-channel routing fit together. Use when adding a new monitoring command, adding a new notification type, changing default routing thresholds, or wiring a new channel.
| name | uxlog-usage |
| description | How to pick the correct uxLog level (action, log, warning, error, success, other), the matching chalk color, sensitive logging, VS Code UI suppression, and uxLogTable. Use when adding or modifying any uxLog call. |
| user-invocable | false |
uxLog writes to three sinks at once:
commandThis.ux.log or console.log).hardisLogFileStream file log.logType === "other", or the line contains the markers [command] or [NotifProvider].The logType argument both labels the line in the UI (drives section grouping, icons, colors) and decides whether the line reaches the UI at all. Pick it deliberately.
import { uxLog, uxLogTable } from "../../../common/utils/index.js";
import c from "chalk";
import { t } from "../../../common/utils/i18n.js";
Always pair the level with its chalk color. Mixing them confuses the terminal output and breaks the convention used across ~2000 existing call sites.
| Level | Chalk color | When to use |
|---|---|---|
action | c.cyan | A new major step. Opens a new section / log group in the VS Code LWC UI. One per logical phase (e.g. "Querying", "Generating report", "Deploying metadata"). |
log | c.grey | Sub-detail beneath the current action. Counts, file paths, timings, intermediate state. |
warning | c.yellow | Recoverable issue the user should review. Operation continues. |
error | c.red | Failure or blocking issue. Operation is aborting or the result is unusable. |
success | c.green | Confirmed successful completion of an operation, often the closing line of an action block. |
other | none / c.grey / c.italic | Console + file only. NOT forwarded to the VS Code UI. Use for raw JSON dumps, verbose debug, or chatter that would clutter the UI session log. |
table | (internal) | Used by uxLogTable only. Do not call uxLog("table", ...) directly. |
// New phase - opens a UI section
uxLog("action", this, c.cyan(t("deployingMetadata", { metadata: name })));
// Detail under that action
uxLog("log", this, c.grey(t("foundFiles", { count: files.length })));
uxLog("log", this, c.grey(`- ${reportFile}`));
// Recoverable issue
uxLog("warning", this, c.yellow(t("missingOptionalConfig", { key: "slackWebhook" })));
// Failure
uxLog("error", this, c.red(t("deploymentFailed", { message: e.message })));
// Successful completion
uxLog("success", this, c.green(t("deploymentSucceeded", { org: targetOrg })));
// Debug payload that should NOT pollute the VS Code UI
uxLog("other", this, JSON.stringify(rawApiResponse, null, 2));
c.green with error, c.red with success, etc. The level and color must match.action for sub-details - that creates spurious sections in the UI. One action per phase, then log for everything underneath.log (which goes to the UI in grey) for noisy diagnostic output - prefer other.uxLog should be wrapped in the matching color so terminal output stays readable.sensitive=true)Pass true as the fourth argument when the line contains credentials, tokens, secrets, or any data that must not land in the file log or the VS Code UI.
uxLog("log", this, c.grey(`Authenticating with token ${token}`), true);
Behaviour:
hardisLogFileStream): writes the literal string OBFUSCATED LOG LINE.OBFUSCATED LOG LINE. Exception: lines containing SFDX_CLIENT_ID_, SFDX_CLIENT_KEY_, or SFDX_CLIENT_CERT_ are sent as-is even when sensitive=true.Use sensitive=true for any line that interpolates an access token, refresh token, client secret, password, or third-party API key.
The VS Code extension only renders lines whose logType !== "other" AND whose text does not include the markers [command] or [NotifProvider].
Practical consequences:
uxLog("other", ...). The terminal and file log still receive it.[command] and [NotifProvider] prefixes are reserved for internal command-execution and notification-provider lines that the UI handles through dedicated events; do not introduce new uses of those markers in unrelated code.[Marker] prefixes (e.g. [DORA], [sfdx-hardis]) are fine and are forwarded to the UI.For tabular output, do not hand-format a table inside uxLog. Use uxLogTable, which renders an aligned text table to the terminal/file log AND emits a structured table payload to the LWC UI.
import { uxLogTable } from "../../../common/utils/index.js";
uxLogTable(this, [
{ name: "Account", recordCount: 42, status: "ok" },
{ name: "Contact", recordCount: 17, status: "ok" },
], ["name", "recordCount", "status"]);
bool2emoji.