honour Date object passed as legacy 2nd arg to isAfter / isBefore

[HrachShah]

What this PR fixes

isAfter and isBefore silently ignore a Date object that callers pass as
the legacy second argument. The disambiguation between "this is the legacy date
arg" and "this is the new options object" was a typeof options === 'object'
check, which is true for any Date as well, so the new-options branch always
won. isAfter('2010-01-02', new Date('2010-01-01')) returned false even
though 2010-01-02 is plainly after 2010-01-01, because the code then did
options.comparisonDate (which is undefined on a Date), fell back to
Date().toString() for "now", and compared against the current moment.

Repro

import isAfter from 'validator/lib/isAfter';

const pivot = new Date('2010-01-01T00:00:00Z');
isAfter('2010-01-02', pivot); // false on master, should be true
isAfter('2009-12-31', pivot); // true on master, should be false

Fix

Hoist the disambiguation into a small resolveComparisonDate helper that
recognises a Date instance directly, and short-circuit toDate() when the
comparison date is already a Date. The typeof === 'object' branch is also
guarded against null for the same reason the rest of the codebase already
guards null options.

function resolveComparisonDate(options) {
  if (options instanceof Date) {
    return options;
  }
  if (typeof options === 'object' && options !== null) {
    return options.comparisonDate;
  }
  return options;
}

const comparisonDate = resolveComparisonDate(options) || Date().toString();
const comparison = comparisonDate instanceof Date
  ? comparisonDate
  : toDate(comparisonDate);

Tests

The shared test helper in test/testFunctions.js serialises args via
JSON.stringify for error messages, which would strip the Date identity. The
new cases are written as direct assertions against the validator instead.

• test/validators/isAfter.test.js — new '(legacy syntax with Date object)'
  describe block:
  • isAfter('2010-01-02', new Date('2010-01-01')) is true
  • isAfter('2009-12-31', new Date('2010-01-01')) is false
  • isAfter('2010-01-02', new Date('not a date')) is false
• test/validators/isBefore.test.js — same three cases for isBefore.

Both new test blocks fail on master (Stashed the source changes and ran the suite: 2 failing) and pass on the fix (320 passing).

$ npx mocha --reporter dot --require @babel/register --recursive test
  320 passing (247ms)

ESLint passes on the modified files.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (e36b279) to head (20d3d2e).
⚠️ Report is 5 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff            @@
##            master     #2783   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files          114       114           
  Lines         2586      2602   +16     
  Branches       656       661    +5     
=========================================
+ Hits          2586      2602   +16     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

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

[WikiRik]

I do think that having Date objects silently be ignored is the wrong behaviour, but I don't think this is the proper solution. IIRC the previous behaviour only allowed strings, so there's no backwards compatible path for Date objects that we need to keep in mind. Or am I mistaken on that?

[tux-tn]

I agree with @WikiRik. Supporting Date objects here feels inconsistent with the library’s general spirit of validating string inputs and keeping the API focused on string-based validation. This would be an API expansion rather than a backwards-compatibility fix.