feat(console): show line numbers next to console output#1008
feat(console): show line numbers next to console output#1008iahmedgamal wants to merge 6 commits into
Conversation
- supports JS, TS and React - remaining languages shows nothing for now - add VLQ decoder and source line map builder (utils/source-map.ts) - addN badge into Luna Console log items via insert event
✅ Deploy Preview for livecodes ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughThis PR adds source-map generation to React and TypeScript compilers, extends compile and console contracts, maps runtime locations to markup or script lines, and displays mapped line numbers in console entries with unit and end-to-end coverage. ChangesConsole Source Map Line Numbers
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant Compiler
participant ResultFrame
participant ConsolePanel
participant DOM
Compiler->>ConsolePanel: setSourceMap(sourceMap)
ResultFrame->>ResultFrame: derive console call-site line and source
ResultFrame->>ConsolePanel: postMessage(lineNumber, source, console args)
ConsolePanel->>ConsolePanel: map generated line to original line
ConsolePanel->>DOM: render console-line-number badge
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
src/livecodes/utils/source-map.ts (1)
3-3: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winAdd
/*@pure*/annotations to exported pure utility functions.Both
decodeVlqandbuildSourceLineMapare exported pure functions insrc/livecodes/utils/but lack the required/*@PURE*/annotation for tree-shaking.As per coding guidelines: "Mark exported pure utility functions with
/*@PURE*/annotation for tree-shaking" (src/livecodes/utils/**/*.{ts,tsx}).♻️ Proposed fix
-export const decodeVlq = (str: string, pos: number): [value: number, nextPos: number] => { +export const decodeVlq = /* `@__PURE__` */ (str: string, pos: number): [value: number, nextPos: number] => {-export const buildSourceLineMap = (sourceMapStr: string): Map<number, number> => { +export const buildSourceLineMap = /* `@__PURE__` */ (sourceMapStr: string): Map<number, number> => {Also applies to: 30-30
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/livecodes/utils/source-map.ts` at line 3, The exported pure utility functions in source-map.ts need `/* `@__PURE__` */` annotations for tree-shaking. Add the annotation to both `decodeVlq` and `buildSourceLineMap` at their export declarations so bundlers can recognize them as pure. Keep the change limited to these exported utility function definitions in `src/livecodes/utils/source-map.ts`.Source: Coding guidelines
src/livecodes/styles/app.scss (1)
1247-1259: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueBadge may not sit at the far right without an auto start margin.
flex-shrink: 0/align-self: centerimply the log item is a flex row, but nothing pushes the badge to the right edge, so it will render immediately after the log content rather than the "far right" shown in the PR screenshots. If the intent is right-alignment, add an auto inline-start margin.🎨 Optional: push badge to the far right
.console-line-number { flex-shrink: 0; align-self: center; + margin-inline-start: auto; padding-right: 8px; padding-left: 4px;🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/livecodes/styles/app.scss` around lines 1247 - 1259, The .luna-console-log-item badge styling in console-line-number is missing the flex spacing needed to pin it to the far right. Update the existing .console-line-number rule to use an auto inline-start margin so the badge is pushed away from the log content and aligns to the row’s end while preserving the current flex behavior.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/livecodes/languages/typescript/lang-typescript.ts`:
- Line 51: The TypeScript language setup is dropping the `errors` returned by
`ts.convertCompilerOptionsFromJson`, which can hide invalid or conflicting
compiler settings and leave `sourceMapText` unset. Update `getLanguageInfo` in
`lang-typescript.ts` to capture the full result from
`convertCompilerOptionsFromJson`, then surface any conversion errors into
`info.errors` alongside existing diagnostics so callers can see the problem
instead of silently losing line-number mapping.
In `@src/livecodes/result/utils.ts`:
- Around line 120-125: The getCallSiteLine helper currently depends on
stack.split('\n')[3], which is V8-specific and can break on other engines.
Update getCallSiteLine to parse the Error.stack more defensively by normalizing
stack frames or using frame markers before extracting the caller line, and keep
the fallback behavior returning undefined when no valid call site can be found.
---
Nitpick comments:
In `@src/livecodes/styles/app.scss`:
- Around line 1247-1259: The .luna-console-log-item badge styling in
console-line-number is missing the flex spacing needed to pin it to the far
right. Update the existing .console-line-number rule to use an auto inline-start
margin so the badge is pushed away from the log content and aligns to the row’s
end while preserving the current flex behavior.
In `@src/livecodes/utils/source-map.ts`:
- Line 3: The exported pure utility functions in source-map.ts need `/*
`@__PURE__` */` annotations for tree-shaking. Add the annotation to both
`decodeVlq` and `buildSourceLineMap` at their export declarations so bundlers
can recognize them as pure. Keep the change limited to these exported utility
function definitions in `src/livecodes/utils/source-map.ts`.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 5b13f2b7-970c-4497-a6df-9ef1c2270431
📒 Files selected for processing (9)
src/livecodes/core.tssrc/livecodes/languages/react/lang-react.tssrc/livecodes/languages/typescript/lang-typescript.tssrc/livecodes/models.tssrc/livecodes/result/utils.tssrc/livecodes/styles/app.scsssrc/livecodes/toolspane/console.tssrc/livecodes/utils/__tests__/source-map.spec.tssrc/livecodes/utils/source-map.ts
![pullfrog[bot]](https://avatars.githubusercontent.com/in/1768019?s=60&v=4){kind=small}
There was a problem hiding this comment.
ℹ️ No critical issues — minor robustness suggestions inline.
Reviewed changes — add source-mapped console line numbers for JS/TS/React, with a custom VLQ decoder/source-line map builder and queue-based badge injection into Luna Console log items.
- Pass
sourceMapfrom the compiled script result to the console viasetSourceMap. - Capture the call-site line in the sandboxed result iframe and forward it with each console message.
- Build a generated-line → original-line map from source map
mappings, keeping only the first segment per generated line. - Render
:Nline-number badges in Luna Console log items through itsinsertevent. - Add unit tests for the custom VLQ decoder and source-line map builder.
ℹ️ Nitpicks
- Four changed files currently fail
prettier --check:src/livecodes/core.ts,src/livecodes/languages/react/lang-react.ts,src/livecodes/result/utils.ts, andsrc/livecodes/utils/__tests__/source-map.spec.ts. Runningnpm run fix:prettierwill clean them up.
Kimi K2 (free via Pullfrog for OSS) ｜ 𝕏
|
Oh wow! I confirm it works with js, ts & react I will review the changes carefully and come back to you, isA. Meanwhile, here are some comments:
You may also want to check comments by coderabbit and pullfrog AI reviews. Thank you :) |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
There was a problem hiding this comment.
ℹ️ No critical issues in the incremental changes — the
fix: eslintcommit addresses the prior feedback it targeted. One minor annotation nit inline.
Reviewed changes — the fix: eslint commit resolves lint/format issues and follows up on prior review comments.
- Fixed TypeScript compiler option error handling in
src/livecodes/languages/typescript/lang-typescript.ts—convertCompilerOptionsFromJsonerrors are now captured and logged as warnings. - Added
/* @__PURE__ */annotation tobuildSourceLineMapinsrc/livecodes/utils/source-map.ts. - Resolved prettier/eslint formatting in
src/livecodes/core.ts,src/livecodes/languages/react/lang-react.ts,src/livecodes/utils/__tests__/source-map.spec.ts, and related files.
A prior robustness suggestion about defensive stack-frame parsing in src/livecodes/result/utils.ts (open thread) remains unchanged by these commits.
Kimi K2 (free via Pullfrog for OSS) ｜ 𝕏
example: (script:7 , or markup:5), consecutive identical logs from the same source are grouped by Luna's native dedeuplication but with badge (script:1:5) - add e2e console-line-logs spec with 5 tests
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (3)
src/livecodes/toolspane/console.ts (1)
88-112: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueOptional: address static-analysis nits.
SonarCloud flags
String.prototype.match(Line 88) in favor ofRegExp.exec, andparseInt(Lines 91, 92, 112) in favor ofNumber.parseInt.♻️ Suggested tweaks
- const match = current.match(/^(\w+):(\d+)(?::(\d+))?$/); + const match = /^(\w+):(\d+)(?::(\d+))?$/.exec(current); if (!match) return current; const src = match[1]; - const firstLine = parseInt(match[2], 10); - const lastLine = match[3] ? parseInt(match[3], 10) : firstLine; + const firstLine = Number.parseInt(match[2], 10); + const lastLine = match[3] ? Number.parseInt(match[3], 10) : firstLine;- const newLine = parseInt(sourceLine.split(':')[1], 10); + const newLine = Number.parseInt(sourceLine.split(':')[1], 10);🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/livecodes/toolspane/console.ts` around lines 88 - 112, Address the static-analysis nits in the line-number handling helper and setupInsertListener: replace String.prototype.match with the equivalent regular expression exec call, and replace every parseInt invocation with Number.parseInt while preserving the existing radix and behavior.Source: Linters/SAST tools
src/livecodes/result/markup-script-lines.ts (1)
1-9: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winExtract shared helpers to avoid duplication.
toPositiveLineNumberandtoUserLineare identically defined in bothmarkup-script-lines.tsandconsole-line-source.ts. Extract them to a shared module (e.g.,result/line-utils.ts) and import from both files to prevent divergence.♻️ Proposed shared module
// src/livecodes/result/line-utils.ts export const toPositiveLineNumber = (line: number | undefined): number | undefined => { if (typeof line !== 'number' || !Number.isFinite(line) || line <= 0) return undefined; return Math.trunc(line); }; export const toUserLine = (docLine: number, offset: number): number | undefined => { if (!offset) return undefined; return toPositiveLineNumber(docLine - offset); };Then in both
markup-script-lines.tsandconsole-line-source.ts:-const toPositiveLineNumber = (line: number | undefined): number | undefined => { - if (typeof line !== 'number' || !Number.isFinite(line) || line <= 0) return undefined; - return Math.trunc(line); -}; - -const toUserLine = (docLine: number, offset: number): number | undefined => { - if (!offset) return undefined; - return toPositiveLineNumber(docLine - offset); -}; +import { toPositiveLineNumber, toUserLine } from './line-utils';🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/livecodes/result/markup-script-lines.ts` around lines 1 - 9, Extract the duplicated toPositiveLineNumber and toUserLine helpers from markup-script-lines.ts and console-line-source.ts into a shared result/line-utils.ts module, exporting both functions. Remove the local definitions and import the shared helpers in both consuming files, preserving their existing behavior.e2e/specs/console-line-logs.spec.ts (1)
138-154: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winTest 5 could wait for the expected count directly.
waitForConsoleEntries(app, 1)waits for only 1 entry, then relies onwaitForTimeout(300)for the second entry to appear. Since bothconsole.log("same text")calls fire synchronously (inline markup script + editor script), waiting for 2 entries directly would be more robust and eliminate the fragile timeout.♻️ Proposed fix
- await waitForConsoleEntries(app, 1); - await app.waitForTimeout(300); + await waitForConsoleEntries(app, 2); + await app.waitForTimeout(300);🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@e2e/specs/console-line-logs.spec.ts` around lines 138 - 154, Update the test “does not merge same text from markup and script” to call waitForConsoleEntries(app, 2) and remove the subsequent fixed waitForTimeout(300), so it waits directly for both synchronous console entries before collecting them.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/livecodes/result/console-line-source.ts`:
- Around line 99-126: Update proxyConsole’s window.error handler to pass the
ErrorEvent through getConsoleErrorSite instead of posting error.lineno directly.
Use the returned lineNumber, source, rawLine, and offset metadata when
constructing the posted runtime error payload so window errors receive the same
markup/script mapping as console calls.
In `@src/livecodes/toolspane/console.ts`:
- Around line 168-198: Prevent lineNumberQueue from advancing for console
methods that do not create a rendered log item, including console.time,
console.countReset, and passing console.assert calls. Update the
message-processing logic around lineNumberQueue and the insert handler so badge
metadata is queued or assigned only when Luna actually inserts a console entry,
preserving alignment for subsequent source badges.
---
Nitpick comments:
In `@e2e/specs/console-line-logs.spec.ts`:
- Around line 138-154: Update the test “does not merge same text from markup and
script” to call waitForConsoleEntries(app, 2) and remove the subsequent fixed
waitForTimeout(300), so it waits directly for both synchronous console entries
before collecting them.
In `@src/livecodes/result/markup-script-lines.ts`:
- Around line 1-9: Extract the duplicated toPositiveLineNumber and toUserLine
helpers from markup-script-lines.ts and console-line-source.ts into a shared
result/line-utils.ts module, exporting both functions. Remove the local
definitions and import the shared helpers in both consuming files, preserving
their existing behavior.
In `@src/livecodes/toolspane/console.ts`:
- Around line 88-112: Address the static-analysis nits in the line-number
handling helper and setupInsertListener: replace String.prototype.match with the
equivalent regular expression exec call, and replace every parseInt invocation
with Number.parseInt while preserving the existing radix and behavior.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 90eec2b2-d314-4db5-be15-fe4409be1c7f
📒 Files selected for processing (8)
e2e/specs/console-line-logs.spec.tssrc/livecodes/result/console-line-source.tssrc/livecodes/result/markup-script-lines.tssrc/livecodes/result/result-page.tssrc/livecodes/result/result-types.tssrc/livecodes/result/utils.tssrc/livecodes/toolspane/console.tssrc/livecodes/utils/__tests__/source-map.spec.ts
🚧 Files skipped from review as they are similar to previous changes (1)
- src/livecodes/utils/tests/source-map.spec.ts
| export const getConsoleErrorSite = (error: ErrorEvent): ConsoleErrorSite => { | ||
| const rawLine = toPositiveLineNumber(error.lineno || undefined); | ||
| const externalScript = isExternalScriptFrame(error.filename ?? ''); | ||
| const { markup, script } = getOffsets(); | ||
| const source = (() => { | ||
| if (!rawLine) return 'script' as ConsoleSource; | ||
| if (externalScript) return 'script' as ConsoleSource; | ||
| if (!markup && !script) return 'script' as ConsoleSource; | ||
| if (script > 0) return rawLine >= script ? 'script' : 'markup'; | ||
| if (markup > 0) return 'markup' as ConsoleSource; | ||
| return 'script' as ConsoleSource; | ||
| })(); | ||
| const lineNumber = | ||
| !rawLine || externalScript | ||
| ? rawLine | ||
| : source === 'script' | ||
| ? toUserLine(rawLine, script) ?? rawLine | ||
| : getMarkupInlineScriptLine(rawLine, markup) ?? rawLine; | ||
|
|
||
| return { | ||
| lineNumber, | ||
| source, | ||
| rawLine, | ||
| markupOffset: markup, | ||
| scriptOffset: script, | ||
| externalScript, | ||
| }; | ||
| }; |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check if getConsoleErrorSite is imported/used anywhere in the codebase
rg -nP 'getConsoleErrorSite' --type=ts -g '!**/node_modules/**' -g '!**/dist/**'Repository: live-codes/livecodes
Length of output: 158
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '\n## Files\n'
git ls-files 'src/livecodes/result/console-line-source.ts' 'src/livecodes/**/utils.ts' | sed 's#^`#-` #'
printf '\n## console-line-source.ts outline\n'
ast-grep outline src/livecodes/result/console-line-source.ts --view expanded || true
printf '\n## utils.ts candidates\n'
fd -a 'utils.ts' src/livecodes || true
printf '\n## getConsoleErrorSite / getConsoleCallSite references\n'
rg -n 'getConsoleErrorSite|getConsoleCallSite|addEventListener\(\x27error\x27|\blineNumber:\s*error\.lineno' src/livecodes -S || trueRepository: live-codes/livecodes
Length of output: 2684
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '## src/livecodes/result/utils.ts (around error handler)\n'
sed -n '120,170p' src/livecodes/result/utils.ts
printf '\n## src/livecodes/result/console-line-source.ts (around helper)\n'
sed -n '1,170p' src/livecodes/result/console-line-source.tsRepository: live-codes/livecodes
Length of output: 5600
Map window.error lines through getConsoleErrorSite
proxyConsole still posts error.lineno directly, so runtime errors bypass the markup/script offset mapping used for console calls. Routing the error handler through getConsoleErrorSite would keep reported line numbers consistent.
🧰 Tools
🪛 GitHub Check: SonarCloud Code Analysis
[warning] 114-116: Extract this nested ternary operation into an independent statement.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/livecodes/result/console-line-source.ts` around lines 99 - 126, Update
proxyConsole’s window.error handler to pass the ErrorEvent through
getConsoleErrorSite instead of posting error.lineno directly. Use the returned
lineNumber, source, rawLine, and offset metadata when constructing the posted
runtime error payload so window errors receive the same markup/script mapping as
console calls.
| if (message.method !== 'groupEnd') { | ||
| const lineDisplayMethods = ['log', 'error', 'warn', 'info', 'output']; | ||
| if ( | ||
| lineNumbersEnabled && | ||
| message.lineNumber !== undefined && | ||
| lineDisplayMethods.includes(message.method) | ||
| ) { | ||
| const source = getSource(message.source); | ||
| const rawLineNumber = toPositiveLineNumber(message.lineNumber); | ||
| if (!rawLineNumber) { | ||
| lineNumberQueue.push(null); | ||
| (consoleEmulator as any)[message.method](...args); | ||
| updateMark(); | ||
| return; | ||
| } | ||
| const lineNumber = | ||
| source === 'script' | ||
| ? toPositiveLineNumber(sourceLineMap?.get(rawLineNumber)) ?? rawLineNumber | ||
| : rawLineNumber; | ||
| lineNumberQueue.push(`${source}:${lineNumber}`); | ||
| // Break Luna's deduplication only when the source (markup/script) changes. | ||
| // Same source lets Luna group identical messages; the insert handler extends | ||
| // the badge range on each dedup re-emit. | ||
| if (lastProcessedSource !== source) { | ||
| (consoleEmulator as any).lastLog = null; | ||
| lastProcessedSource = source; | ||
| } | ||
| } else { | ||
| lineNumberQueue.push(null); | ||
| } | ||
| } |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Inspect which console methods Luna emits 'insert' for (esp. time/timeEnd/count/countReset/assert/table/group).
fd -t f -e ts -e js . node_modules/luna-console 2>/dev/null | head
rg -nP "emit\(\s*['\"]insert['\"]|\binsert\b|addCount|\btime\b|\bcountReset\b|\bassert\b" --iglob '*luna*console*' -C3 2>/dev/null | head -80Repository: live-codes/livecodes
Length of output: 158
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Map the relevant file and search for queue/event handling.
git ls-files 'src/livecodes/toolspane/console.ts' 'src/livecodes/**' | sed -n '1,200p'
printf '\n--- outline ---\n'
ast-grep outline src/livecodes/toolspane/console.ts --view expanded || true
printf '\n--- insert / queue / console method refs ---\n'
rg -n "lineNumberQueue|setupInsertListener|groupEnd|insert|timeEnd|timeLog|time|countReset|count|assert|table|output" src/livecodes/toolspane/console.ts src/livecodes -g '!**/*.map' -g '!**/dist/**' -g '!**/build/**'Repository: live-codes/livecodes
Length of output: 50377
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Read the relevant console implementation in small slices.
printf '%s\n' '--- src/livecodes/toolspane/console.ts (1-260) ---'
sed -n '1,260p' src/livecodes/toolspane/console.ts
printf '\n%s\n' '--- console emulator creation references ---'
rg -n "new .*Console|create.*Console|consoleEmulator|on\\('insert'|insert\\(" src/livecodes -g '!**/*.map'Repository: live-codes/livecodes
Length of output: 12842
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Find the Luna Console package version and any lockfile pin.
rg -n '"luna-console"|luna-console' package.json package-lock.json pnpm-lock.yaml yarn.lock bun.lockb .npmrc . -g '!**/node_modules/**' -g '!**/dist/**' -g '!**/build/**' | head -120
printf '\n--- package.json snippets ---\n'
sed -n '1,220p' package.json
printf '\n--- any docs or source mentions of LunaConsole methods/events ---\n'
rg -n "luna-console|LunaConsole|on\\('insert'|emit\\('insert'|addCount|timeLog|timeEnd|countReset|assert" src test docs . -g '!**/node_modules/**' -g '!**/dist/**' -g '!**/build/**' | head -200Repository: live-codes/livecodes
Length of output: 2659
🌐 Web query:
luna-console 1.3.6 insert event timeLog timeEnd countReset assert source code
💡 Result:
Luna Console (luna-console) is a library that provides a console interface for logging, designed to mirror the behavior of the standard window.console object found in browser developer tools [1]. In version 1.3.6, the library supports standard console methods, including timeLog, timeEnd, countReset, and assert, which operate as defined in the WHATWG Console Standard [2][1]. These methods are not unique to luna-console but are part of its implementation of the standard Web Console API [2][1]: - assert(condition,...data): Writes a message to the console if the provided condition is falsy [2][3]. - countReset(label): Resets the internal counter associated with the specified label [2][3]. - timeLog(label,...data): Prints the elapsed time and any additional data associated with a timer started by console.time [2][3]. - timeEnd(label): Stops the specified timer and prints the total elapsed time [2][3]. The source code for luna-console is maintained as part of the liriliri repository ecosystem (specifically linked to projects like eruda) [4][5]. The library maps these standard methods to its internal rendering and management logic (such as Log.js and index.js) to display logs within its custom UI component [4]. Users typically interact with these via the exported instance, which behaves like the global console [1].
Citations:
- 1: https://www.npmjs.com/package/luna-console
- 2: https://console.spec.whatwg.org/
- 3: https://bun.sh/reference/globals/console/ConsoleConstructor/constructor
- 4: https://registry.npmjs.org/luna-console
- 5: liriliri/eruda@0c8c4fd
🌐 Web query:
site:github.com luna-console emit insert timeLog countReset assert Log.js
💡 Result:
Luna Console is a component of the Luna UI library, designed to provide a browser-based logging interface similar to the Google Chrome DevTools console [1][2]. The library implements standard console methods that mirror the functionality of the native window.console object [1][3]. The specific methods you inquired about—emit, insert, timeLog, countReset, and assert—function as follows within the context of console logging: 1. assert: Writes an error message to the console if the provided expression evaluates to false [3][4]. 2. countReset: Resets the internal counter associated with a specified label [3][4]. 3. timeLog: Outputs the elapsed time since a timer (identified by a label) was started [3][4]. Regarding emit and insert, these are generally not standard console API methods [3][4]. In the Luna library, insert is specifically documented as a method for the Luna Tab component (used for managing tab positioning) [5], rather than the Console component. If you encounter emit or insert used in the context of a console logger, they are likely either custom implementation methods for internal event handling or part of a specific wrapper library extending the base console functionality [6][7]. For technical implementation, you can initialize the Luna Console by targeting a DOM container [1]: const container = document.getElementById('container'); const console = new LunaConsole(container); console.log('luna');
Citations:
- 1: https://github.com/liriliri/luna/blob/master/src/console/README.md
- 2: https://github.com/liriliri/luna/blob/master/README.md
- 3: https://github.com/nodejs/node/blob/main/doc/api/console.md
- 4: https://github.com/GoogleChrome/developer.chrome.com/blob/main/site/en/docs/devtools/console/api/index.md
- 5: https://github.com/liriliri/luna/blob/master/src/tab/README.md
- 6: https://github.com/isunjn/consoo
- 7: https://github.com/wawawoom/konsole
🌐 Web query:
liriliri luna console source timeLog timeEnd countReset assert insert event implementation
💡 Result:
The luna-console library, part of the liriliri/luna UI library, is a JavaScript console implementation designed to mirror the functionality of the standard browser console (window.console) [1][2][3]. Implementation Details: - Functionality: It supports the standard console API, including methods such as log, error, info, warn, dir, time, timeLog, timeEnd, clear, count, countReset, assert, table, group, groupCollapsed, and groupEnd [2][4]. - Architecture: luna-console functions similarly to browser DevTools [1][4]. It acts as a UI component that renders log entries in a browser environment [5][3]. It is built with modularity in mind, and the underlying utility functions and component structures are often managed by the licia utility library, which is a common dependency for liriliri projects like Eruda [6]. - Integration: Users interact with it by instantiating the component, which then provides an interface to capture and display logs [2][4]. It is highly configurable, offering options for log filtering (string, RegExp, or function), level management (verbose, info, warning, error), and rendering behavior (async rendering, lazy evaluation for objects) [2][4]. Because luna-console is designed to simulate the standard Web Console API, its methods (timeLog, timeEnd, countReset, assert, etc.) map directly to their corresponding WHATWG standard behaviors, ensuring consistency for developers [2][7]. The library is specifically used as a dependency for the Eruda mobile browser console, which provides developers with a full suite of debugging tools on mobile devices [6].
Citations:
- 1: https://github.com/liriliri/luna/blob/master/src/console/README.md
- 2: https://www.npmjs.com/package/luna-console
- 3: https://p.rst.im/q/github.com/liriliri/luna
- 4: https://registry.npmjs.org/luna-console
- 5: https://github.com/liriliri/luna
- 6: https://github.com/liriliri/eruda
- 7: https://github.com/whatwg/console/blob/main/index.bs
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect the sandbox-side console message producer.
rg -n "type:\s*'console'|postMessage\(\{.*console|console\." src/livecodes -g '!**/*.map' -g '!**/dist/**' -g '!**/build/**' | head -250Repository: live-codes/livecodes
Length of output: 19708
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '--- src/livecodes/result/utils.ts (110-190) ---'
sed -n '110,190p' src/livecodes/result/utils.ts
printf '\n%s\n' '--- src/livecodes/types/bundle-types.ts (380-440) ---'
sed -n '380,440p' src/livecodes/types/bundle-types.tsRepository: live-codes/livecodes
Length of output: 3671
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '--- e2e/specs/console-line-logs.spec.ts ---'
sed -n '1,220p' e2e/specs/console-line-logs.spec.ts
printf '\n%s\n' '--- console-related e2e mentions ---'
rg -n "console\\.(table|time|timeLog|timeEnd|count|countReset|assert|log|warn|error|info|group)" e2e src/livecodes -g '!**/*.map' -g '!**/dist/**' -g '!**/build/**' | head -200Repository: live-codes/livecodes
Length of output: 21780
Badge queue can drift on silent console methods
src/livecodes/toolspane/console.ts:168-198 still enqueues a slot for console.time, console.countReset, and passing console.assert calls, but those don’t render a log item. That leaves an extra null in lineNumberQueue and shifts later source badges onto the wrong entry. Queue only when Luna inserts a log item, or move the badge assignment into the insert handler.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/livecodes/toolspane/console.ts` around lines 168 - 198, Prevent
lineNumberQueue from advancing for console methods that do not create a rendered
log item, including console.time, console.countReset, and passing console.assert
calls. Update the message-processing logic around lineNumberQueue and the insert
handler so badge metadata is queued or assigned only when Luna actually inserts
a console entry, preserving alignment for subsequent source badges.
…nsole code to use it
There was a problem hiding this comment.
Important
isExternalScriptFrame fails to classify external scripts whose URLs contain query strings or hashes, which can produce wrong source labels and line numbers for logs from those scripts.
Reviewed changes — the latest commit replaces the hardcoded stack-frame index with a defensive source-aware classifier, distinguishes markup vs. script sources, supports grouped line-number badges for deduplicated logs, and adds e2e coverage.
- Replaced brittle stack-frame parsing in
src/livecodes/result/utils.tsand the newsrc/livecodes/result/console-line-source.tswith frame filtering, external-script preference, and safe fallbacks. - Added markup vs. script source detection so inline
<script>logs and editor-script logs display the correct source label. - Added grouped line ranges for Luna Console's native deduplication (e.g.
script:1:5). - Added e2e tests in
e2e/specs/console-line-logs.spec.tscovering script logs, inline markup logs, regrouping after interrupts, and mixed-source separation.
Kimi K2 (free via Pullfrog for OSS) ｜ 𝕏
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/livecodes/utils/line-number.ts`:
- Around line 1-4: Add the `/* `@__PURE__` */` annotation to the exported
`toPositiveLineNumber` utility declaration so bundlers can tree-shake this
side-effect-free function, preserving its existing behavior.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: aa62eea9-5558-4028-b38a-623056da2fb7
📒 Files selected for processing (5)
src/livecodes/result/console-line-source.tssrc/livecodes/result/markup-script-lines.tssrc/livecodes/toolspane/console.tssrc/livecodes/utils/__tests__/line-number.spec.tssrc/livecodes/utils/line-number.ts
✅ Files skipped from review due to trivial changes (1)
- src/livecodes/utils/tests/line-number.spec.ts
🚧 Files skipped from review as they are similar to previous changes (3)
- src/livecodes/result/console-line-source.ts
- src/livecodes/result/markup-script-lines.ts
- src/livecodes/toolspane/console.ts
There was a problem hiding this comment.
ℹ️ No new Pullfrog issues in this incremental commit. The prior
toPositiveLineNumberduplication concern is now resolved.
Reviewed changes — the latest commit extracts toPositiveLineNumber into a shared utility and adds unit tests for it.
- Extracted shared
toPositiveLineNumberutility intosrc/livecodes/utils/line-number.ts. - Removed duplicated definitions from
src/livecodes/result/console-line-source.ts,src/livecodes/result/markup-script-lines.ts, andsrc/livecodes/toolspane/console.ts, replacing them with imports. - Added unit tests in
src/livecodes/utils/__tests__/line-number.spec.tscovering valid inputs and edge cases.
Kimi K2 (free via Pullfrog for OSS) ｜ 𝕏
I kept the Luna native grouping way, but added the new line badge to keep the grouping and 
|
|
|
Thank you @iahmedgamal I had a good look. Here are some comments (bear with me 😅):
So, I prefer to disable grouping messages in console unless they are from the same source and line (e.g. repeated invocations of same function or logs in a loop, etc). And then we can avoid using ranges.
I found some bugs:
console.log('hi');
console.time('timer');
console.log('hello');
Here are some feature requests 😄 :
<!doctype html>
<html lang="en">
<script>
const message = "Hello from TypeScript!";
const logIt = (msg) => {
console.log(msg);
};
logIt(message);
//# sourceMappingURL=data:application/json;charset=utf-8,%7B%22version%22%3A3%2C%22sources%22%3A%5B%22app.ts%22%5D%2C%22mappings%22%3A%22%3BAAAA%3BAACA%3BAACA%3BAACA%3BAACA%22%2C%22sourcesContent%22%3A%5B%22const%20message%3A%20string%20%3D%20'Hello%20from%20TypeScript!'%3B%5Cnconst%20logIt%20%3D%20(msg%3A%20string)%3A%20void%20%3D%3E%20%7B%5Cn%20%20%20%20console.log(msg)%3B%5Cn%7D%3B%5CnlogIt(message)%3B%22%5D%7D
</script>
</body>
</html>I could not get that to work in LiveCodes. I'm not sure if this is related to restriction on sandboxed iframe, or because we use document.write to add content to the page or something else. Any way, this is not a high priority, but a really nice-to-have feature. Some organizational comments:
I do not want to overload you if you think this scope is larger than what you want to contribute with. Thank you. I really appreciate your work. |
3 participants
What type of PR is this? (check all applicable)
Description
Console line number is added at the far right of the console section
Related Tickets & Documents
#635
Mobile & Desktop Screenshots/Recordings
Please observe this React template works as well && it's responsive
Added tests?
Added to documentations?
[optional] Are there any post-deployment tasks we need to perform?
[optional] What gif best describes this PR or how it makes you feel?
Summary by CodeRabbit