search

denoland / deno_std

The Deno Standard Library
https://jsr.io/@std
MIT License
2.83k stars 581 forks source link

proposal(assert): change the entrypoint pattern from "assert/assert-foo" to "assert/foo" #5162

Closed kt3k closed 17 hours ago

kt3k commented 5 days ago

The core team proposes the change to the entrypoint pattern in @std/assert like the below:

-import { assertEquals } from "@std/assert/assert-equals";
+import { assertEquals } from "@std/assert/equals";
0f-0b commented 5 days ago

This change makes imports shorter and less repetitive, but on the other hand it breaks the pattern of every module being named after the symbol it exports, and having two similarly named modules (equal and equals) might cause confusion.

kt3k commented 5 days ago

How about renaming equal to isEqual to avoid the above (possible) confusion?

kt3k commented 2 days ago

A question has been raised in #5176

Should we also do the rename of @std/assert/assertion-error -> @std/assert/error?

kt3k commented 2 days ago

Should we also do the rename of @std/assert/assertion-error -> @std/assert/error?

I personally don't think we should do this rename.

assert/equals and assertEquals have completely the same sound when they are read. So it feels natural to be able to import assertEquals from assert/equals. On the other hand, assert/error and AssertionError are different in sound. So it feels a bit confusing that one can import AssertionError from assert/error.

WDYT?

iuioiua commented 1 day ago

It makes sense that @std/assert/error exports an error class, and it doesn't stick out as much as having a @std/assert/assertion-error, compared to the rest of the package. That's as deep as my reasoning goes, but my opinion isn't too strong.