Add jest extensions on main module

[gnapse]

What:

• The main module now has the side effect of applying all the custom matchers as jest extensions.
• The usual extend-expect module is kept and still does the same.
• There's a matchers module now that exports the matchers without having any side effect. It does not add them as jest extensions.

Why:

#123 (comment)

Also related: DefinitelyTyped/DefinitelyTyped#37792

Checklist:

• Documentation
• Tests
• Updated Type Definitions
• Ready to be merged
  

[codecov]

Codecov Report

Merging #175 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master   #175   +/-   ##
=====================================
  Coverage     100%   100%           
=====================================
  Files          19     19           
  Lines         234    234           
  Branches       57     57           
=====================================
  Hits          234    234

Impacted Files	Coverage Δ
src/extend-expect.js	100% <ø> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8e14dc1...efec69a. Read the comment docs.

[jgoz]

@gnapse Is the plan to move the type definitions to DefinitelyTyped and then introduce the dependency here like the other @testing-library packages?

[gnapse]

Yes, I was meaning to go through here with the piece of the puzzle that was missing that was preventing your PR to DT to be accepted. Based on our last comments in #123 we all converged to that (all meaning Kent, you and me).

[kentcdodds]

LGTM!

[gnapse]

@kentcdodds @jgoz was meaning to ask just to make sure: this is not a breaking change, right? The only thing I can see that could be a problem is that custom matchers are no longer exported on index.js and technically people could do that, and now these are only exported in matchers.js. Maybe if I keep the exports on index in addition to the side effect, we can keep this a feature release and not a breaking change.

[kentcdodds]

I don't think this is a breaking change.

[jgoz]

Yes, I was meaning to go through here with the piece of the puzzle that was missing that was preventing your PR to DT to be accepted. Based on our last comments in #123 we all converged to that (all meaning Kent, you and me).

👍

was meaning to ask just to make sure: this is not a breaking change, right? The only thing I can see that could be a problem is that custom matchers are no longer exported on index.js and technically people could do that, and now these are only exported in matchers.js. Maybe if I keep the exports on index in addition to the side effect, we can keep this a feature release and not a breaking change.

If you don't re-export the matchers from index I think it's technically a breaking change, but I highly doubt it will actually affect anyone.

[jgoz]

Looks good!

[jgoz]

@gnapse Are you going to open a new DT PR or do you want me to do it?

[gnapse]

I thought the one you had started was still available to resume proposing it. Seems to still be open.

I think it's technically a breaking change, but I highly doubt it will actually affect anyone.

I know but still, it was even documented that you could selectively import the matchers and extend jest yourself. I don't want to take any chances.

Would there be anything wrong in re-exporting them all on index.js? If not, I'd rather do that than risking breaking someone's workflow.

[jgoz]

I thought the one you had started was still available to resume proposing it. Seems to still be open.

Sure, I can update that one with the latest typings.

I know but still, it was even documented that you could selectively import the matchers and extend jest yourself. I don't want to take any chances.

Would there be anything wrong in re-exporting them all on index.js? If not, I'd rather do that than risking breaking someone's workflow.

Nothing technically wrong with it. But maybe it's worth doing a major bump to indicate that there was a significant change? I defer to you on this one.

Though I think this change will need to be done in multiple steps:

1. Merge this PR
2. Update DT PR to reflect changes in master (and merge DT PR 🤞)
3. Remove local types and add DT dependency

[gnapse]

@kentcdodds will love your input on all this. Both the breaking change issue, and the multiple steps. Would hate to see people's work flows broken for even a short while.

[kentcdodds]

That sounds fine to me 👍 Just make sure there's only one major version bump. I probably wouldn't merge anything until DT is ready to go and you've added the DT dep. No point in making all of these changes here if we're just going to move them right away.

[gnapse]

Then we shouldn't merge this PR first, right? Otherwise it'll create a new release right away 🤔

[jgoz]

I forgot that releases are created on merge. I'll see if I can update the DT branch and refer the reviewers to extend-expect-on-index, rather than master.

Unless it's possible to create a beta/prerelease version instead of an actual version?

[gnapse]

We could/should have a beta branch. We make it the default branch, but keep the semver stuff to trigger on master only. That way we could do more controlled releases that gather more than one PR.

[kentcdodds]

Yeah, it doesn't happen very often, but when I want to group commits into a single release, I'll just make a temporary next branch. It doesn't last long.

[gnapse]

I created a next branch and switched this PR to be based on it. Se we can merge, and you can refer the DT reviewers to it @jgoz.

I'm merging this soon.

[gnapse]

🎉 This PR is included in version 5.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀