Ignore expires and maxAge in res.clearCookie()

[jonchurch]

Opened a new PR for this, supersedes #4852

closes #4851

The PR overrides any expires value set, and explicitly deletes maxAge from the options object.

The reason this is needed is that res.cookie() will set a relative expires value if it sees a maxAge value in the options.

clearCookie is meant to delete a cookie, but that deletion can be thwarted if you pass a maxAge value, by setting an expires into the future relative to the maxAge

[jonchurch]

eslint is choking on the spread syntax

[jonchurch]

It's a lack of ecmaVersion in the .eslintrc.yml

For spread, we'd need ecmaVersion: 2015

For v5 though, with support targetting >= Node 18, we'd want ecmaVersion: 2022

[wesleytodd]

I was thinking after we land 5 we should work out moving to neostandard (or standard as it seems the fork could get resolved). I wonder if maybe it is just landing this without the lint offending things and just move forward?

[jonchurch]

That's where Im at rn too, will update this to not break lint

[jonchurch]

updated the PR to use Object.assign so we don't have to update the linting rn

[wesleytodd]

I am unsure why 22 is blocking this and don't have time to dig in, but since there is both engines and new CI for 5.0 I wonder if we can just ignore this for now and merge?

[jonchurch]

@wesleytodd it's misocnfiguration weirdness with ci

5.0 branch protection requires the node 22 job from master's CI to pass
But master's CI doesn't trigger for PRs to 5.0 (that workflow triggers on 5.x, 4.x, master) after my updates we landed a few weeks ago.

5.0 has it's own version of CI which is outdated and doesn't care about branches. 5.0 branche's CI are the status jobs running here. That version of CI doesn't include 22 in it's matrix, but the job that is pending but required is the master CI

[ctcpip]

it's not really a lint failure per se -- it's a parsing error, which means we can't even add an eslint-disable-line directive

the question about whether and what linter and rules to use is a different matter than language support, and we should not arbitrarily subject our selves to a syntactical penitentiary. we are going to run into this all the time. and here, it's in a critical path and where we take a perf hit by using object assign

[wesleytodd]

Sounds to me with both of these comments that these are entirely unrelated issues to this PR so we could move forward with just merging and dealing with fixing CI in the 5.0 branch in one of the PRs specifically already working on that?

[ctcpip]

@wesleytodd there's a bit of a circular dependency with the merge PR/branch needing the 5.0 changes due to both merge conflicts and test failure reconciliation, but @jonchurch and I just spent some time getting things cleaned up. at this point the merge branch/PR is looking good and all we are waiting for is the next release of v4, then to do one last sync and then merge to 5.0. (we could also merge to 5.0 sooner than that, but the typical process had been to merge only after a release). either way wfm