Match core `assert` API

[jamestalmage]

I would prefer to do t.deepStrictEqual(...) instead of t.same(...), etc.

Keeping the API's the same means one less detail I need to keep in my head.

(no reason t.same and other sugar can't stick around, I would just like to have the entire assert API implemented).

[sindresorhus]

Not a big fan of aliases tbh. It's a good idea in theory, but they complicate the simplicity. Not in code, but in documentation and overhead for users, as they have to pick the aliases they prefer. AVA is inherently opinionated. This also makes it easier for contributors. AVA is always the same no matter which project you contribute too.

When we implement the possibility to use any assertion lib #49, you could just use the core assertion lib, right?

// @vdemedes @kevva @arthurvr @SamVerschueren

[jamestalmage]

This also makes it easier for contributors

Only if they are familiar with AVA's api. The number of people familiar with assert > those familiar with AVA. Nearly all the AVA assertions have an assert equivalent, so from a certain perspective you have renamed / aliased that.

Why did the team choose to use different names than the core assert library? Just your preference? Is it based on some other library?

[sindresorhus]

Another argument against. The Node.js core team have repeatedly said the assert module is locked and won't change. That it is mainly for internal use and users should prefer userland assertion libs. In the future we might want to change things which might not be fully compatible with assert and it would be confusing to have the same method names then.

nodejs/node#2315 (comment)

[jamestalmage]

fair enough.