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

assert: add strict functionality export #17002

Closed
wants to merge 2 commits into from

Conversation

BridgeAR
Copy link
Member

@BridgeAR BridgeAR commented Nov 13, 2017

To further improve assert this adds a strict export. When used, all functions will use the strict equality instead of a loose one.

At the same time this is a doc only deprecation of the legacy loose mode. It is not intended to remove the old functionality as it is wildly used a lot and removing it does not seem to be a option.
I also improved the assert documentation in general a bit. It now outlines the used rules a bit better and clearly separates loose and strict equality.

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines
Affected core subsystem(s)

doc,assert

@BridgeAR BridgeAR added assert Issues and PRs related to the assert subsystem. doc Issues and PRs related to the documentations. semver-minor PRs that contain new features and should be released in the next minor version. labels Nov 13, 2017
@nodejs-github-bot nodejs-github-bot added the assert Issues and PRs related to the assert subsystem. label Nov 13, 2017
Copy link
Member

@Trott Trott left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bold move. I like it in theory, but I'd caution that we are probably never going to be able to get rid of legacy mode, so we will need to support both strict and legacy mode forever... I'm not objecting, but I am being cautious...;.

@@ -6,6 +6,44 @@

The `assert` module provides a simple set of assertion tests that can be used to
test invariants.
A `strict` and a `legacy` mode exist, while it is recommended to only use
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Micro-nit: Add a blank line before this one?


## Strict mode

When using the strict mode any assert function will use the equality used in the
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Micro-nit: comma after mode?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Micro-nit: backticks around strict mode and assert?

## Strict mode

When using the strict mode any assert function will use the equality used in the
strict function mode. So [`assert.deepEqual`][] will for example work the same
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Micro-nit: comma before and after for example?


> Stability: 0 - Deprecated: Use strict mode instead.

When accessing `assert` directly instead of using the `strict` property the
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: comma after property?


When accessing `assert` directly instead of using the `strict` property the
"non-strict" equality will be used for the "non-strict" function names e.g.
[`assert.deepEqual`][].
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Put everything after e.g. and up to the closing . in parentheses.

Nit: Here and several places above, function names should be followed by () I believe. So assert.deepEqual() rather than assert.deepEqual. That said, if there's already a lot of no-parentheses examples in the doc, never mind. :-D


It is recommended to use the [ strict mode`][] instead as the loose equality
checks are often not sufficient.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: They're called non-strict, legacy, and loose throughout the document. I'd suggest picking just one of those and sticking with it.

Nit: are often not sufficient might be better expressed as can often have surprising results.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I rephrased it and hope it is clearer now :-)

@BridgeAR
Copy link
Member Author

@Trott I addressed all comments. I know it might seem a strong move but we do not have to remove the legacy mode ever and that is also why I only wanted a doc only deprecation.
Having the strict mode will likely improve the situation for many people though.

Copy link
Contributor

@refack refack left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Quick LGTM

[`assert.throws()`]: #assert_assert_throws_block_error_message
[`strict mode`]: #assert_assert_strict_mode
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be just #assert_strict_mode? As it is not an assert API part, just a simple heading.

const assert = require('assert');
```

It is recommended to use the [ strict mode`][] instead as the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[ strict mode`][]: space instead of a backtick.

@joyeecheung
Copy link
Member

Ping @BridgeAR this needs a rebase.

@BridgeAR
Copy link
Member Author

Rebased

@BridgeAR
Copy link
Member Author

@BridgeAR BridgeAR added author ready PRs that have at least one approval, no pending requests for changes, and a CI started. assert Issues and PRs related to the assert subsystem. and removed assert Issues and PRs related to the assert subsystem. labels Nov 22, 2017
@jasnell
Copy link
Member

jasnell commented Nov 22, 2017

Needs another rebase :-)

1) Separate all loose and strict functions.
2) Stronger outline the used comparison rules in (not)deepStrictEqual
3) Fix SameValue comparison info
Requireing the strict version will allow to use `assert.equal`,
`assert.deepEqual` and there negated counterparts to be used with
strict comparison instead of using e.g. `assert.strictEqual`.

The API is identical to the regular assert export and only differs
in the way that all functions use strict compairson.
@BridgeAR
Copy link
Member Author

Rebased plus some tiny documentation improvements while doing so (it is actually the SameValue comparison used by Object.is() and not the Object.is() comparison).

@addaleax
Copy link
Member

Landed in 06ab6f2, a319e90

@addaleax addaleax closed this Nov 28, 2017
@addaleax addaleax removed the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Nov 28, 2017
addaleax pushed a commit that referenced this pull request Nov 28, 2017
1) Separate all loose and strict functions.
2) Stronger outline the used comparison rules in (not)deepStrictEqual
3) Fix SameValue comparison info

PR-URL: #17002
Reviewed-By: Refael Ackermann <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Vse Mozhet Byt <[email protected]>
Reviewed-By: Anna Henningsen <[email protected]>
addaleax pushed a commit that referenced this pull request Nov 28, 2017
Requireing the strict version will allow to use `assert.equal`,
`assert.deepEqual` and there negated counterparts to be used with
strict comparison instead of using e.g. `assert.strictEqual`.

The API is identical to the regular assert export and only differs
in the way that all functions use strict compairson.

PR-URL: #17002
Reviewed-By: Refael Ackermann <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Vse Mozhet Byt <[email protected]>
Reviewed-By: Anna Henningsen <[email protected]>
@MylesBorins
Copy link
Contributor

MylesBorins commented Dec 11, 2017

Should this be backported to v9.x-staging? If yes please follow the guide and raise a backport PR, if not let me know or add the dont-land-on label.

BridgeAR added a commit to BridgeAR/node that referenced this pull request Mar 8, 2018
1) Separate all loose and strict functions.
2) Stronger outline the used comparison rules in (not)deepStrictEqual
3) Fix SameValue comparison info

PR-URL: nodejs#17002
Reviewed-By: Refael Ackermann <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Vse Mozhet Byt <[email protected]>
Reviewed-By: Anna Henningsen <[email protected]>
BridgeAR added a commit to BridgeAR/node that referenced this pull request Mar 8, 2018
Requireing the strict version will allow to use `assert.equal`,
`assert.deepEqual` and there negated counterparts to be used with
strict comparison instead of using e.g. `assert.strictEqual`.

The API is identical to the regular assert export and only differs
in the way that all functions use strict compairson.

PR-URL: nodejs#17002
Reviewed-By: Refael Ackermann <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Vse Mozhet Byt <[email protected]>
Reviewed-By: Anna Henningsen <[email protected]>
@BridgeAR BridgeAR mentioned this pull request Mar 8, 2018
4 tasks
@BridgeAR
Copy link
Member Author

BridgeAR commented Mar 8, 2018

Backport opened in #19230

MylesBorins pushed a commit that referenced this pull request Mar 15, 2018
1) Separate all loose and strict functions.
2) Stronger outline the used comparison rules in (not)deepStrictEqual
3) Fix SameValue comparison info

Backport-PR-URL: #19230
PR-URL: #17002
Reviewed-By: Refael Ackermann <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Vse Mozhet Byt <[email protected]>
Reviewed-By: Anna Henningsen <[email protected]>
MylesBorins pushed a commit that referenced this pull request Mar 15, 2018
Requireing the strict version will allow to use `assert.equal`,
`assert.deepEqual` and there negated counterparts to be used with
strict comparison instead of using e.g. `assert.strictEqual`.

The API is identical to the regular assert export and only differs
in the way that all functions use strict compairson.

Backport-PR-URL: #19230
PR-URL: #17002
Reviewed-By: Refael Ackermann <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Vse Mozhet Byt <[email protected]>
Reviewed-By: Anna Henningsen <[email protected]>
@targos targos mentioned this pull request Mar 18, 2018
MylesBorins pushed a commit that referenced this pull request Mar 20, 2018
Requireing the strict version will allow to use `assert.equal`,
`assert.deepEqual` and there negated counterparts to be used with
strict comparison instead of using e.g. `assert.strictEqual`.

The API is identical to the regular assert export and only differs
in the way that all functions use strict compairson.

Backport-PR-URL: #19230
PR-URL: #17002
Reviewed-By: Refael Ackermann <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Vse Mozhet Byt <[email protected]>
Reviewed-By: Anna Henningsen <[email protected]>
@MylesBorins
Copy link
Contributor

Requested backport to 8.x in #19230

@tniessen tniessen added the deprecations Issues and PRs related to deprecations. label Sep 7, 2018
BridgeAR added a commit to BridgeAR/node that referenced this pull request Oct 2, 2018
Requireing the strict version will allow to use `assert.equal`,
`assert.deepEqual` and there negated counterparts to be used with
strict comparison instead of using e.g. `assert.strictEqual`.

The API is identical to the regular assert export and only differs
in the way that all functions use strict compairson.

PR-URL: nodejs#17002
Reviewed-By: Refael Ackermann <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Vse Mozhet Byt <[email protected]>
Reviewed-By: Anna Henningsen <[email protected]>
MylesBorins pushed a commit that referenced this pull request Oct 31, 2018
Requireing the strict version will allow to use `assert.equal`,
`assert.deepEqual` and there negated counterparts to be used with
strict comparison instead of using e.g. `assert.strictEqual`.

The API is identical to the regular assert export and only differs
in the way that all functions use strict compairson.

Backport-PR-URL: #23223
PR-URL: #17002
Reviewed-By: Refael Ackermann <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Vse Mozhet Byt <[email protected]>
Reviewed-By: Anna Henningsen <[email protected]>
@BethGriggs BethGriggs mentioned this pull request Nov 12, 2018
@BridgeAR BridgeAR deleted the assert-strict branch April 1, 2019 23:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
assert Issues and PRs related to the assert subsystem. deprecations Issues and PRs related to deprecations. doc Issues and PRs related to the documentations. semver-minor PRs that contain new features and should be released in the next minor version.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants