Skip to content

Changing assert to become a class #58253

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

Draft
wants to merge 16 commits into
base: main
Choose a base branch
from

Conversation

miguelmarcondesf
Copy link
Contributor

Changing assert to become a class

This PR refactors assert from a method to a dedicated class. This change is motivated by the need for greater flexibility and configurability in assertion behavior.

By turning assert into a class, we will be able to pass options that customize its behavior, such as doing specific checks, how the stack trace will look like, etc.

Checklist

  • Refactor assert into a class structure.
  • Ensure backward compatibility with existing assert usages.
  • Add new unit tests to cover the class-based behavior.
  • Review performance implications.

cc @BridgeAR

@nodejs-github-bot
Copy link
Collaborator

Review requested:

  • @nodejs/test_runner

@nodejs-github-bot nodejs-github-bot added assert Issues and PRs related to the assert subsystem. needs-ci PRs that need a full CI run. labels May 9, 2025
@mcollina mcollina requested review from cjihrig, MoLow and BridgeAR May 10, 2025 21:56
@mcollina
Copy link
Member

I'm mildly concerned on the long term maintainability of this, as it essentially rewrites the module - backporting might lead to more churn than needed. You might get less churn by using the "old school" pattern:

function Assert () {
}

Assert.prototype.notEqual = function () {}

With this pattern, indentation would not change and this PR might be easier to review.

This change is motivated by the need for greater flexibility and configurability in assertion behavior.

Can you clarify the need for this?

Apart from that, this would need a CITGM check to verify it doesn't break end users in any way.

@pmarchini
Copy link
Member

Hey @miguelmarcondesf, thanks for the contribution 🚀

My 2 cents on this: while I understand the reasons behind this refactor, if I’m not mistaken, I don’t see any options actually being used in the class.
We're only supporting an empty object for potential future use cases.
I don’t see a clear benefit in terms of cognitive complexity or readability in the refactor itself.

So I’m wondering what the intended usage is for the new options we plan to introduce.

The reason I’m asking is to provide a better context and justify any potential cons of rewriting the module (e.g., portability to other versions), while also providing an overview of what’s expected to be added.

@miguelmarcondesf
Copy link
Contributor Author

Can you clarify the need for this?

@mcollina Thank you for sharing your concerns!
This idea came from a conversation with @BridgeAR when I was looking for something to contribute

@miguelmarcondesf
Copy link
Contributor Author

Hey @pmarchini, thanks for your thoughts!

My 2 cents on this: while I understand the reasons behind this refactor, if I’m not mistaken, I don’t see any options being used in the class.

I decided to open it in draft so I could receive more guidance on this, the PR already had a lot of modifications, and I wanted more perspectives so we could start this discussion.

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. needs-ci PRs that need a full CI run.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants