Mark toHaveBeenCalledBefore and After's second parameter as optional

[Blond11516]

What

Marks toHaveBeenCalledBefore and toHaveBeenCalledAfter's second parameter as optional in the type declarations.

Why

Current type declarations generate an error if the parameter isn't passed. This is inaccurate, as the default value will be used in this case.

Notes

Fixes #651

Housekeeping

• Unit tests
• Documentation is up to date
• No additional lint warnings
• Typescript definitions are added/updated where relevant

[changeset-bot]

⚠️ No Changeset found

Latest commit: ee69452

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[chornos13]

I think you forgot to mark the second argument of toHaveBeenCalledAfter function as an optional

[Blond11516]

@chornos13 I didn't personally need toHaveBeenCalledAfter when I opened the PR but I think it makes sense to do both at the same time. I've updated the PR.

[codecov]

Codecov Report

All modified lines are covered by tests ✅

Comparison is base (61df485) 100.00% compared to head (ee69452) 100.00%.
Report is 9 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##              main      #650   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           73        73           
  Lines          674       674           
  Branches       290       290           
=========================================
  Hits           674       674           

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

[keeganwitt]

Thanks for the PR!

[SimenB]

Should we add an action that checks if either there's an added changeset or we add a label? Seems the message from the bots is overlooked by contributors most of the time 😅

[keeganwitt]

Should we add an action that checks if either there's an added changeset or we add a label? Seems the message from the bots is overlooked by contributors most of the time 😅

I'm not too picky about how we do it. I'm fine with that approach.

I know some projects force a changeset for every PR. On the one hand, seems like maybe overkill, but on the other hand, I haven't seen a PR that would be awkward to have this rule.

[SimenB]

Not all PRs need a changeset - e.g. docs only. But seeing as the comment is ignored, we might need something that yells louder before merging

[keeganwitt]

Not all PRs need a changeset - e.g. docs only. But seeing as the comment is ignored, we might need something that yells louder before merging

Oh, I thought docs used the changeset for publishing the updated docs to the website.

[SimenB]

Nah, changesets is solely for publishing to npm.

Website changes are apparently a manual step (#648 (comment)) - ideally that would just be autopublished on pushes to main. That's how https://jestjs.io/ works