Closed timoxley closed 4 years ago
I looked into this a while ago. The problem is that tape already have aliases for equal AVA methods, but with different behavior. Mainly, we have t.same
which means deep strict equal, tape's t.same
means deep non-strict equal. We have t.true
which means val === true
, while the tape version is just an alias for t.ok
which is !!val
.
@sindresorhus ahh understood, this makes sense. Can close.
I'll keep it open as I want to do a transition guide, maybe even an automated script (that would be cool!).
Those could be written as codemods btw https://github.com/facebook/jscodeshift
@nvartolomei Yup, that would be rad. I've been thinking about this for a while.
Opened a separate issue → https://github.com/sindresorhus/ava/issues/644.
Also see discussion in #445.
I just switched from tap/tape to ava, which benifit me reducing the test time from dozens of minutes to around 3 minutes. ava is great.
when I made the transition, the main pain to me is the following 2 changes:
t.equal
to t.is
t.ok
to t.truthy
the reason I found this issue is because I have the same idea with @timoxley . but after I saw the explains from @sindresorhus , I agree there will not easy to switch between ava and tap/tape. (not like switch between tap and tape, which is only need to change one line)
so my sugestion is: at least we alias those two methods(equal & is, ok & truthy), because they have the same behaviour, and will let developer switch more easier, without cause any confusing.
@zixia We're actually very close to having an automatic migration script: https://github.com/avajs/ava-codemods/pull/28 😃
@sindresorhus ah, cool. it will help much. thanks!
If we can get t.equal
to alias t.is
then spok
just works.
Would make migrating from tape easier if AVA & tape shared the same API.
Below is the full list of
tape
apis that don't exist in AVA. Most of these would only require a simple alias e.g.Test.prototype.deepEqual = Test.prototype.same
Though it's possible there's benefit in divorcing the tape API entirely & just keeping the current, simpler API. For example, not sure if it was ever a good idea to support both
deepEquals
anddeepEqual
other than to encourage bikeshedding within a team about which one to use.Related to https://github.com/sindresorhus/ava/issues/96