repl: add support for multiline history

[puskin]

Previously, when navigating the history in the Node.js REPL, multiline commands were displayed line by line, making it difficult to review and edit complete blocks of input.

This PR improves the REPL history behavior by treating multiline commands as a single entry. Now, when scrolling through history, entire blocks of multiline input are displayed together, improving usability and consistency.

Key changes:

• Adjusted history handling to store and retrieve multiline commands as single entries.
• Updated navigation logic to properly display multiline inputs.
• Improved editing experience, allowing users to modify multiline history entries in place.
• Changed the multiline indicator: from ... to |, to keep the indentation consistent
• Added the multiline indicator also when editing the history, not only when adding new lines
• If the last command caused some kind of error, you can now edit the multiline history, and if you remove the error, the history which caused the error will be replaced with the correct one

Important:

This change relies on the fact that I am now formatting new history entries and saving them in the .node_replhistory file in a specific format. While this does not break backward compatibility, it does mean that switching between older and newer versions (i.e., versions without and with this change) will result in multiline history entries not being preserved if they were created with the latest changes.

Impact:

This change significantly enhances the REPL experience for users who frequently enter complex or multiline expressions, making command recall and editing more intuitive.

Testing:

• Manually tested with various multiline inputs, both on unix and windows systems
• Verified history navigation behaves as expected with both single-line and multiline commands.

Demos

Before:

After:

[codecov]

Codecov Report

Attention: Patch coverage is 96.62921% with 6 lines in your changes missing coverage. Please review.

Project coverage is 90.24%. Comparing base (27f98c3) to head (cab0f16).
Report is 555 commits behind head on main.

Files with missing lines	Patch %	Lines
lib/internal/readline/interface.js	95.38%	4 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #57400      +/-   ##
==========================================
+ Coverage   90.20%   90.24%   +0.03%     
==========================================
  Files         630      630              
  Lines      185307   185613     +306     
  Branches    36269    36400     +131     
==========================================
+ Hits       167162   167507     +345     
+ Misses      11084    10994      -90     
- Partials     7061     7112      +51     

Files with missing lines	Coverage Δ
lib/internal/repl/history.js	88.46% <100.00%> (+2.19%)	⬆️
lib/internal/repl/utils.js	96.79% <100.00%> (+0.52%)	⬆️
lib/repl.js	95.03% <100.00%> (+0.13%)	⬆️
lib/internal/readline/interface.js	96.76% <95.38%> (-0.19%)	⬇️

... and 145 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[aduh95]

/cc @nodejs/repl

[puskin]

@BridgeAR you, being the requestor, maybe want to give this a shot 😄

[BridgeAR]

This is a great start!

I did play around with it and I found the following issues:

1. A history item is now not properly deduplicated anymore if it spans over multiple lines. That is the case with other entries when jumping through the history.
2. When entering a multiline command that fails to evaluate, it is handled as individual lines. Especially those cases would be great to "correct". For comfort reasons, I would even consider deleting the broken one, if that one is edited and saved successfully right as following command.
3. Moving up and down while working on a multiline entry feels somewhat off. It is opinionated, but I believe the former history entry should only be shown in case the cursor is at the top line while editing a multiline input. The reason is, that I likely want to finish the input and not change to the former history entry.

I would also change the ... to |. That way the indentation while entering something is identical. I guess we can still look into doing this potentially while going through the entries in the history but at least it is nicer during initial entry.

[BridgeAR]

This is great work! I am looking forward to landing this change!

I left a few comments, mainly to understand some things better.

[BridgeAR]

LGTM! Thank you for the great work! 🥳

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/66212/ 💛

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/66234/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/66236/

[nodejs-github-bot]

Landed in 4a4aa58

[lpinca]

It seems that test/parallel/test-repl-multiline-navigation is flaky. See https://ci.nodejs.org/job/node-test-commit-aix/56805/nodes=aix72-ppc64/testReport/junit/(root)/parallel/test_repl_multiline_navigation/

---
duration_ms: 324.926
exitcode: 1
severity: fail
stack: |-
  node:assert:95
    throw new AssertionError(obj);
    ^

  AssertionError [ERR_ASSERTION]: Expected values to be strictly equal:

  2 !== 1

      at /home/iojs/build/workspace/node-test-commit-aix/nodes/aix72-ppc64/test/parallel/test-repl-multiline-navigation.js:132:12
      at /home/iojs/build/workspace/node-test-commit-aix/nodes/aix72-ppc64/test/common/index.js:400:17
      at /home/iojs/build/workspace/node-test-commit-aix/nodes/aix72-ppc64/test/common/index.js:435:15
      at REPLServer.<anonymous> (node:internal/repl/history:120:9)
      at Object.onceWrapper (node:events:621:28)
      at REPLServer.emit (node:events:507:28)
      at REPLServer.emit (node:domain:489:12)
      at onwritten (node:internal/repl/history:156:14)
      at FSReqCallback.wrapper [as oncomplete] (node:fs:803:5)
      at FSReqCallback.callbackTrampoline (node:internal/async_hooks:130:17) {
    generatedMessage: true,
    code: 'ERR_ASSERTION',
    actual: 2,
    expected: 1,
    operator: 'strictEqual'
  }

  Node.js v24.0.0-pre
...

Can you take a look?

[puskin]

@lpinca thanks for the report!
It should get fixed here: #57874 😄