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

[Refactor] don't destructure builtins #1033

Merged
merged 1 commit into from
Oct 25, 2024

Conversation

MichaelDeBoey
Copy link
Contributor

Introduced in a3c0ffa, but these are the only places we do this.
In all other places we use Object.*

@ljharb
Copy link
Member

ljharb commented Oct 25, 2024

I actually prefer to do it everywhere - iow, I think this is going the wrong direction.

@ljharb ljharb marked this pull request as draft October 25, 2024 21:58
@MichaelDeBoey
Copy link
Contributor Author

@ljharb This is always going to come from Object from now on, so it's unnecessary to destruct Object globally imo

@ljharb
Copy link
Member

ljharb commented Oct 25, 2024

It's not globally, it's at the top level module scope.

@MichaelDeBoey
Copy link
Contributor Author

@ljharb Yeah that's what I meant, sorry for the miswording.

My opinion is just: from this point onwards, these methods will always come from Object, so I don't see any point to destruct these methods.
People just seeing entries(abc) will ask themselves where entries is coming from and why Object.entries isn't used (they'll think it's probably a special implementation for some reason), only to find out it actually is used.
When making it explicit directly, people will need less cognitive load to understand where everything is coming from

@ljharb
Copy link
Member

ljharb commented Oct 25, 2024

That's true, and I suppose I've accepted the risk of environment mutation, so that's not really an argument that applies.

@ljharb ljharb marked this pull request as ready for review October 25, 2024 23:07
@MichaelDeBoey
Copy link
Contributor Author

If people are breaking their environment outside of this plugin, than it's their own fault for breaking it imo.

But that's out of scope of this PR I think.
My point still stands: making it explicit where entries comes from will improve readability, especially for newer developers in the field.
Which will in it's turn only cause less help from the OSS community to help and fix bugs themselves

@ljharb ljharb force-pushed the dont-destruct-Object branch from 057b9ac to 0852aa6 Compare October 25, 2024 23:11
Copy link
Member

@ljharb ljharb left a comment

Choose a reason for hiding this comment

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

Rebased to clean up remaining examples of this pattern.

@ljharb ljharb changed the title refactor: don't destruct Object [Refactor] don't destructure builtins Oct 25, 2024
@ljharb ljharb merged commit 0852aa6 into jsx-eslint:breaking Oct 25, 2024
24 checks passed
@MichaelDeBoey MichaelDeBoey deleted the dont-destruct-Object branch October 25, 2024 23:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants