Rule proposal: require node:assert/strict

[electrovir]

Description

The built-in Node.js node:assert module is considered "legacy" and node:assert/strict is the non-legacy module. See the docs here: https://nodejs.org/api/assert.html#legacy-assertion-mode.

In particular, those docs note that the legacy node:assert module may produce unexpected, rather absurd, results.

Fail

import assert from 'node:assert'

import assert from 'assert'

Pass

import assert from 'node:assert/strict'

import assert from 'assert/strict'

Proposed rule name

prefer-node-assert-strict, prefer-strict-node-assert, prefer-strict-node-assert-module, prefer-strict-node-import

Additional Info

No response

[sindresorhus]

This would probably be better suited for https://github.com/eslint-community/eslint-plugin-n

[electrovir]

Looks like the original eslint-plugin-node repo even has a ticket about it: mysticatea/eslint-plugin-node#218

[electrovir]

While I don't see a strictly followed conceptual split between this plugin and eslint-plugin-n, I can guess where that split would be, and I agree this rule makes sense in there. If you prefer this proposal to be in eslint-plugin-n I can open an issue there.

[sindresorhus]

If you prefer this proposal to be in eslint-plugin-n I can open an issue there.

👍

[electrovir]

For reference, I found some relevant tickets already in eslint-plugin-n:

• Rule ideas eslint-community/eslint-plugin-n#293
• prefer-import/assert-strict: new rule to prefer import 'node:assert/strict' eslint-community/eslint-plugin-n#59

[MWhite-22]

Sorry to bring up an old PR again but I am doing research on eslint plugins and this is one of the only threads I can find talking about unicorn and plugin-n at the same place.

Im doing my best to compare/contrast the two plugins (and a few rules exist across both, like node protocol) but seeing as sindresorhus even calls outs putting this rule into plugin-n, what is the expected split between the two, and is using both a recommendation?

[fisker]

is using both a recommendation

Yes, the two plugins both useful.

a few rules exist across both, like node protocol

I suggest you can just pick anyone you like, since they are doing the same thing.
But I added support for process.getBuiltinModule() recently in #2611, as far as I know plugin-n doesn't support it yet, update: PR already exists eslint-community/eslint-plugin-n#430 .

We already notice the overlap, we may deprecate ours in future, #1778 (comment)