Ref #13730
Ref #13733 (one error is actually not touched here and is fixed in this PR instead).

Marking as semver-major due to changes in error messages.

@mscdex this should not be semver major as the main intention of the internal errors was to change error messages when ever.

@BridgeAR Right, that's the end goal, but I think until the new error mechanism is widely adopted (e.g. users start checking the special error properties instead of .message) we're still marking error message changes as semver-major. /cc @jasnell to be sure.

Like the improvement. Agree we should still be making these changes semver-major until we get overall agreement that we can starting treating error messages changes differently.

Also needs a rebase.

Like the improvement. Agree we should still be making these changes semver-major until we get overall agreement that we can starting treating error messages changes differently.

There are mixed messages being conveyed #13730 (comment)... IMHO the CTC should discuss and decide.
ping @jasnell

Rebased

IMHO in the tests when you assert the message it should be a RegEx anchored with start-of-line and end in "Received": /^The "last argument" argument must be of type function\. Received/ because whatever comes after "Received" is dependent of the actual input, while the rest is static for each case.

Another idea: export a function from errors: invalidArg(opts) that you use as error.invalidArgs({expected: "gaga", bar}); then you can infer the type of the second arg's name and value:

function invalidArg(opts) {
  assert.strictEqual(Object.keys(opts).length, 2);
  assert.strictEqual('expected' in opts, true);
  const exp = opts.expected;
  delete opts.expected;
  const actKey = Object.keys(opts)[0];
  const actVal = opts[actKey];
  throw new TypeError('ERR_INVALID_ARG_TYPE', actKey, exp, actVal
// if we add a stackLimit arg
// ,invalidArg);
}

@refack

you can infer the type of the second arg's name and value

I feel like this is a bit to much magic and the call itself won't be much shorter. So I'd say let's stick to how it is currently.

I also added the Received part in the RegExp if the line length allowed it. I hope that's fine, I personally don't see much benefit in adding the Received as it might theoretically change and it is already checked that all arguments are properly passed to the internal error.

you can infer the type of the second arg's name and value

I feel like this is a bit to much magic and the call itself won't be much shorter. So I'd say let's stick to how it is currently.

👍

I also added the Received part in the RegExp if the line length allowed it. I hope that's fine, I personally don't see much benefit in adding the Received as it might theoretically change and it is already checked that all arguments are properly passed to the internal error.

Just so it doesn't change "accidentally". Changes in test files get more review attention, so IMHO it's best to assert as much as possible, then later change carefully.

Sanity: https://ci.nodejs.org/job/node-test-commit-linuxone/6883/

Rebased

It is in most cases possible to use the exact value. In the end I don't think that it's that important to test for the message strictly as it can change more often but I'm fine with changing it.