chore(assert): release [email protected]

[iuioiua]

Towards #4717

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.15%. Comparing base (c2b5460) to head (1a4cd9d).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4934   +/-   ##
=======================================
  Coverage   92.15%   92.15%           
=======================================
  Files         487      487           
  Lines       38765    38765           
  Branches     5390     5390           
=======================================
  Hits        35722    35722           
  Misses       2987     2987           
  Partials       56       56           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[kt3k]

Went through all APIs. All looked reasonable to me. LGTM.

[iuioiua]

I am being nitpicky, but I have some thoughts while reviewing this package:

1. Blocking - Error messages end in periods ("."), when the msg argument is undefined. Why? This seems strange. Is this done in the Deno runtime or Web API?
2. Non-blocking - msg arguments might be better named msgSuffix. WDYT?
3. Non-blocking - Arguments could be better named. E.g., for assertArrayIncludes(), arguments could be named array and subArray, instead of actual and expected, respectively. WDYT?
4. Non-blocking - I wonder whether extending AssertionError in some cases and providing more properties that add context to the error thrown is worthwhile. E.g., for assertNotEquals():

   export class AssertNotEqualsError<T> extends AssertionError {
     actual: T;
     expected: T;
   
     constructor(actual: T, expected: T, msg?: string) {
       super(
         msg
           ? `Expected actual: ${actual} not to be: ${expected}: ${msg}`
           : `Expected actual: ${actual} not to be: ${expected}`,
       );
       this.name = this.constructor.name;
       this.actual = actual;
       this.expected = expected;
     }
   }

   This can be done in a backward-compatible manner while making the error thrown more ergonomic. WDYT?

[kt3k]

Error messages end in periods ("."), when the msg argument is undefined. Why? This seems strange. Is this done in the Deno runtime or Web API?

Error messages ending with "." seem just common as well as the error message without "." (Try seach for "new Error" in std). This doesn't seem the issue for std/assert to me. (This should be discussed in broader scope)

msg arguments might be better named msgSuffix. WDYT?

msg looks enough descriptive to me. msgSuffix looks rather confusing to me.

Arguments could be better named. E.g., for assertArrayIncludes(), arguments could be named array and subArray, instead of actual and expected, respectively. WDYT?

actual and expected are conventional in this usage. These look just fine to me.

I wonder whether extending AssertionError in some cases and providing more properties that add context to the error thrown is worthwhile. E.g., for assertNotEquals():

Sounds a good idea, but doesn't look like a blocker for 1.0.0-rc.1. Sounds like a good enhancement candidate after the stabilization

[iuioiua]

Error messages ending with "." seem just common as well as the error message without "." (Try seach for "new Error" in std). This doesn't seem the issue for std/assert to me. (This should be discussed in broader scope)

There are 100+ new Errors in the Standard Library. 14 of them contain a period. So, periods in error messages are part of a minority. Either way, on second thought, let's not worry about this. It's inconsistent but inconsequential.

msg looks enough descriptive to me. msgSuffix looks rather confusing to me.

It's appended to the error message. Either way, not blocking.

actual and expected are conventional in this usage. These look just fine to me.

Yes, it's conventional, but it doesn't completely make sense. Either way, not blocking.

Sounds a good idea, but doesn't look like a blocker for 1.0.0-rc.1. Sounds like a good enhancement candidate after the stabilization

I'll open a new issue when I can.

[iuioiua]

One last thing - should we consider #4934 a blocker?

[kt3k]

One last thing - should we consider #4934 a blocker?

#4934 is this issue

[kt3k]

If you mean #3771, then no. It can be landed as a fix after the stabilization.

[iuioiua]

My bad - typo. Ok.