Side note: There is an error code ERR_INVALID_REPL_HISTORY which appears to be unused but would apply here. Is this correct?

Good catch. It is indeed not used and it is very similar to the ERR_INVALID_ARG_TYPE error, so I went ahead and removed the ERR_INVALID_REPL_HISTORY error.

I am actually not too sure whether this is correct as it is. Considering that repl.history is not an argument or option of any kind but rather constructed from the contents of a file, ERR_INVALID_REPL_HISTORY might be the better option. I traced its introduction to #13299.

/cc @addaleax @Fishrock123

I think what @tniessen says makes sense (but tbh I’ve never actually seen this error happen in the wild)

I changed the error to ERR_INVALID_REPL_HISTORY as suggested.

I think this should be semver-major due to the changed error code.

@jasnell Are you okay with this? Gonna land it then.

Wait, this should not be merged as is. The error is actually completely obsolete and it does not matter what is thrown as the catch block is going to catch the error and return a new and different one that has nothing to do with this error.
It's also not semver major at the moment because the error was never exposed to the user.

I'm thinking about fixing it like this:

try {
  // Pre-v3.0, repl history was stored as JSON.
  // Try and convert it to line separated history.
  const oldReplJSONHistory = fs.readFileSync(oldHistoryPath, 'utf8');

  // Only attempt to use the history if there was any.
  if (oldReplJSONHistory) repl.history = JSON.parse(oldReplJSONHistory);
} catch (err) {
  return ready(
    new errors.Error('ERR_PARSE_HISTORY_DATA', oldHistoryPath));
}

if (!Array.isArray(repl.history)) {
  return ready(new errors.TypeError('ERR_INVALID_REPL_HISTORY',
                                    typeof repl.history));
}
repl.history = repl.history.slice(0, repl.historySize);

This also needs tests as they are missing and lead to the error in the first place.

What do you all think?

Note to myself: check #2449

You are right, I did not even look at that before. Knowing this it makes even less sense why there is ERR_PARSE_HISTORY_DATA and ERR_PARSE_HISTORY_DATA. I am okay with your suggestion, even though I kind of dislike having two different error codes for more or less the same problem. Still, I think your solution might be the closest to what the original authors were trying to achieve.

I fixed the error handling in a way that I expect was originally meant. I am not a big fan of it though and while working on it I thought it might be worth thinking about simple removing the old history file, so I opened an alternative: #13876

As suggested in #13876 the way would be to make a end of life deprecation and then remove this part overall. But until then this fix could go into the code base and I think it could even be backported as well and is a semver-patch.

So PTAL

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

@jasnell @lpinca @cjihrig There have been some major changes since your approvals, could you PTAL and just give me a thumb up if you are okay with landing this as it is?

This has conflicts.

Rebased

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

By the way: IMHO this should not be semver-major (if by any means, then because of the change from converting to converted and in that case I'd rather revert that change). The former handling did not work as expected and this is a patch for that.

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

Please fix CI failures.

Fixed

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

I will land this after giving @nodejs/ctc some time to review and decide semver-ity (even though - technically - two CTC members have already approved).

As far as I can tell this only affects the REPL, as in, the application built into Node, not the public repl module, so semver-patch seems fine.

Landed in e6b69b9. Thank you for your contribution!

CIs on master: LinuxOne, Windows

This doesn’t land cleanly on 8.x; if you can, please follow the guide and raise a backport PR, if you don’t think it’s worth it (or wrong) let me know and we’ll add the dont-land-on label.

@lpinca @jasnell @cjihrig @tniessen Do any of you have the time to backport?

@addaleax I opened a backport to 8.x

Should this be backported to v6.x-staging? If yes please follow the guide and raise a backport PR, if no let me know or add the dont-land-on label.

I do not think that it is worth backporting. So I changed the label accordingly.