Closed pubmikeb closed 2 years ago
I will champion this rule, as I think it will help people better understand this new method.
FYI this rule was implemented in another project as unicorn/prefer-object-has-own but I suspect @fisker would be happy to see it moved to ESLint core where it can benefit more people.
@bmish oh cool! We do typically introduce new rules to help people transition from old ways of doing things to new ways of doing things, so we might still end up with it as a core rule. Let’s get a few more thoughts on this. (Especially since there isn’t a great way to discover such rules and plug-ins.)
Yep, I'm also in favor of new core rules for that reason (like this one).
Will be happy to see the rule in core rules.
proposal-accessible-object-hasownproperty is at stage-3. we can reconsider it when it reaches stage-4.
proposal-accessible-object-hasownproperty is at stage-3. we can reconsider it when it reaches stage-4.
Since this feature is already implemented in V8 and will be in GA in Chromium-based browsers/Firefox/Safari/Node.js by the end of August, the reaching stage-4 is just a formality and by the release of ESLint 8.0 Object.hasOwn()
will be in GA across all major platforms.
@aladdin-add we wait for stage 4 for new syntax, but new APIs are okay to address in stage 3.
I'm in favor of this rule, and I think it should also report {}.hasOwnProperty.call(object, 'foo')
.
I'm in favor of this rule, and I think it should also report
{}.hasOwnProperty.call(object, 'foo')
.
{}.hasOwnProperty.call(object, 'foo')
Object.prototype.hasOwnProperty.call(object,'foo')
function fun(){
return arguments.length
}
How to write arguments so as not to be prompted no-undef
I’m also supportive. Marking as accepted!
Hello everyone, I am a beginner to open-source. I have some experience in working with Javascript. Can I work on this issue?
@thisiskartikgupta sure, let us know if you need any help.
FYI: Object.hasOwn()
just reached Stage 4
Is the PR as simple as just replacing the code? Or is there any other problem to consider?
The rule first needs to identify the patterns mentioned in the issue. The second step is to replace. It is fairly straightforward.
@thisiskartikgupta are you still working on this?
Understood @nzakas. If @thisiskartikgupta isn't currently working on this, can you please assign this to me?
I'm not working on it. You're good to go @eyeamkd !!
@eyeamkd it’s all yours.
@eyeamkd it’s all yours.
Thank you, @nzakas
doing npm install gives me this, is it okay to do npm i -f and continue? prior apologies if this is a trivial question
@eyeamkd yes, npm install --force
will do the trick until we release v8.0.0 final
Worked @btmills
Just a reminder that there's an existing rule unicorn/prefer-object-has-own that we should be able to copy (and it has been battle-tested for several months).
Alright, so all I gotta do is just take the rule and apply conditions on to it? @bmish
Not sure what you mean by "apply conditions on to it". But I would first try to copy it and get it running inside the ESLint codebase.
Okay!
Hold on! We aren’t just going to copy someone else’s work and paste it into ESLint. We should create our own to avoid licensing issues.
This is a fairly straightforward rule that shouldn’t require anything complex enough that it requires copying something directly.
@eyeamkd if you need a starting point, you can copy this rule:
https://eslint.org/docs/rules/prefer-object-spread
The logic for finding Object.assign is exactly the same as for Object.hasOwn.
Using the same @nzakas, and yeah won't be copy-pasting anyone else's work
Let me try again with better advice :) Write our own rule and then check any existing third-party rules to make sure we don't miss important test cases.
@bmish 👍
Hi! is @eyeamkd still working on this? If not then can I take this up? I am new to open source and this seemed a good issue to work on
Yeah, will place a PR soon @AtulKarn
Oh that's great
If no one is working on this issue, can I start with it? 🙂
If no one is working on this issue, can I start with it? 🙂
Yes, sure! Go for it.
@Gautam-Arora24 go for it!
Thanks!
Hey @nzakas, I have been getting an error while running the repo.
I've asked it on the ESLint Discord channel too, can you help me out here?
https://discord.com/channels/688543509199716507/717416886685401108/900029930526621767
It looks like you don’t have an updated repo. Make sure you sync with upstream, then delete your node_modules directory and reinstall.
We've agreed on reporting these patterns:
Object.prototype.hasOwnProperty.call(object, 'foo')
{}.hasOwnProperty.call(object, 'foo')
Thoughts about reporting this pattern, too?
Object.hasOwnProperty.call(object, 'foo')
Thoughts about reporting this pattern, too?
Object.hasOwnProperty.call(object, 'foo')
Yes, i would add this pattern as well.
Generally, I would propose replacing *.hasOwnProperty.*
with *.hasOwn.*
.
Seems reasonable to me. 👍
Is the issue is not fixed, can I start to fix this issue? can I try?
It is currently being implemented in https://github.com/eslint/eslint/pull/15346.
Please describe what the rule should do: Starting V8 v.9.3,
Object.prototype.hasOwnProperty.call
can be replaced with an alias/syntax sugarObject.hasOwn
, which is much more read-friendly. Further information: https://v8.dev/features/object-has-ownWhat new ECMAScript feature does this rule relate to? Promoting using of an alias/syntax sugar
Object.hasOwn
instead ofObject.prototype.hasOwnProperty.call
.What category of rule is this? (place an "X" next to just one item)
[ ] Warns about a potential error (problem) [X] Suggests an alternate way of doing something (suggestion) [ ] Other (please specify:)
Provide 2-3 code examples that this rule will warn about: The original code:
Should be replaced with:
Why should this rule be included in ESLint (instead of a plugin)? Applying this rule you can make your application's code cleaner.
Are you willing to submit a pull request to implement this rule? No.