Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Match core assert API #114

Closed
jamestalmage opened this issue Oct 31, 2015 · 4 comments
Closed

Match core assert API #114

jamestalmage opened this issue Oct 31, 2015 · 4 comments

Comments

@jamestalmage
Copy link
Contributor

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
Copy link
Member

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

@sindresorhus sindresorhus changed the title match assert api Match core assert API Oct 31, 2015
@jamestalmage
Copy link
Contributor Author

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
Copy link
Member

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
Copy link
Contributor Author

fair enough.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants