repl: add support for multiline history

[puskin94]

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 249 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

[puskin94]

@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.

[ljharb]

seems good

[nodejs-github-bot]

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

[nodejs-github-bot]

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

[BridgeAR]

It is a bit difficult to tell if this change should be considered as minor or major. Any further opinion?

[ljharb]

Since using an old version of node corrupts the history to split lines, i'd say it's major. If we can come up with a way to avoid that, then it'd be minor, and aggresively backportable, which would be ideal.

[puskin94]

@ljharb

corrupts the history to split lines: it is true, but you are not breaking anything that was existing before this PR, it is not breaking existing functionality, it is breaking new functionality.
This might be a valid point or not, but I would be curious to know how many people are constantly switching node versions on a daily basis, because this would be the only case where this issue would arise.
On the topic of "restoring" existing history:
I (I had other people thinking with me 😄 ) spent quite some time thinking about how / if we could understand and differentiate which "history version" we are reading from the history file, but it is a lot more complicated than what it seems like. These are the options:

Introducing a new history file format

something new, a .node_repl_history_v2, so to speak, which would be started to be written as soon as this PR lands.

🟢 Pros: there is no complicated logic to determine which history you want to load. If you have new node, read the new history file with the new format, otherwise the old history file with the old node.
🔴 Cons: we need to maintain 2 different history files, with 2 different formats, with 2 specific logics in the codebase to port/understand the history when loading and saving.

Introducing an additional "metadata" history file

something new, a .node_repl_history_metadata, so to speak, which would be started to be written as soon as this PR lands, which would only keep track where lines are to be treated as single lines or multilines.

🟢 Pros: there is no complicated logic to determine which history you want to load. If you have new node, read the new history "metadata" file and parse the history file accordingly, otherwise don't parse the "metadata" file and just read the history file.
🔴 Cons: we need to maintain 2 different files. Adding logic to handle the metadata which need to be updated when you load and save the file, it can become tricky really fast, and switching between old and new node would break as well.

Parsing the history file and trying to restore multiline structures from the old history file

when the old node lands and people start using it, it could try to parse the history file and understand, line by line, if a group of lines would be a single multiline structure.

🟢 Pros: you only handle a single history file.
🔴 Cons: it sounds easy on paper, it is not 😄 this is actually my first implementation, which I executed using acorn to parse the history file, and it worked great!
The only problem is that, reading line by line, the parsing in the lib was emitting syntax exceptions until it found the next line which was "completing the multiline structure", and then considered that a single multiline history. The issue tho is: what if there is a syntax exception in the history file because the user put it there? How does acorn know that the command is broken and it does not need to go to the next line to try to complete the multline command?
It might be possible, but it would be O(n^2) complex, which is not great. (thanks @BridgeAR for this insight)

[ljharb]

I was wondering if there's a way to avoid that parse by using unicode newlines instead of normal ones, such that older node handles it normally but newer node recognizes it as multiline input?

[github-actions]

The notable-change PRs with changes that should be highlighted in changelogs. label has been added by @BridgeAR.

Please suggest a text for the release notes if you'd like to include a more detailed summary, then proceed to update the PR description with the text or a link to the notable change suggested text comment. Otherwise, the commit will be placed in the Other Notable Changes section.

[BridgeAR]

After looking into this again, I do not believe that it's possible to get the unicode line breaks to work in older Node.js versions. So the only way I believe is viable without renaming the file is to accept that switching to an older version removes the multilines for those history entries.
What we can do is to try to backport this to as many versions as possible.

[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