Comments (9)
@klebba β That was a lot of documentation reading! I mostly agree with your sentiment (thanks for writing in a way that was easy to review, by the way!). There are just a handful of things that I may disagree on.
from eslint-config-netflix.
Reconciling our comments so far, here are the items still needing to settle:
Keep. Agree with your rationale above.
Keep (for now). Will be removed later along with
semi
regardless.
Remove. This syntax is not prone to inducing bugs. Choice is mostly stylistic. A quick scan of our codebase reveals frequent use of this pattern (IMO that is because it is often situationally appropriate/natural)
Keep. Could flip a coin on whether or not we should treat typos as a syntax problem to warn about.
Keep. However if this rule incurs a notable performance cost we should remove it.
Keep. Could flip a coin on whether or not we should treat typos as a syntax problem to warn about.
from eslint-config-netflix.
Sounds good to me @klebba! I agree with your summaries above π
from eslint-config-netflix.
Assessment of rules still needing consideration:
REMOVE: stylistic preference regarding explicit rather vs implicit return statements
REMOVE: stylistic preference regarding naming convention / word delimiters
REMOVE: stylistic preference regarding organizing code as static vs class methods
REMOVE: attempts to mitigate bugs by encouraging curly braces around blocks
REMOVE: stylistic preference regarding property accessor syntax
INCLUDE: perhaps this is a useful reminder as a warning; also would include
prefer-object-has-own
REMOVE: stylistic preference regarding constructor names
REMOVE: attempts to mitigate bugs by discouraging valid syntax
INCLUDE: warns about formerly common, now deprecated JS feature
REMOVE: prone to warning about a non-issue during the authoring process
REMOVE: prone to warning about a non-issue during the authoring process
INCLUDE: the appropriate enforcement is via Content-Security-Policy rules regardless
INCLUDE: often considered to be an anti-practice
REMOVE: warns about obsolete (and proprietary/ultra obscure) syntax
REMOVE: prone to warning you about a non-issue during the authoring process
INCLUDE: may offer some bug mitigation value
REMOVE: archaic concern; this is valid JavaScript now
REMOVE: rule warns about valid syntax
REMOVE: rule warns about valid constructor use
INCLUDE: warns about formerly common, now deprecated JS feature
INCLUDE: same rationale as no-eval
REMOVE: attempts to mitigate bugs by discouraging valid syntax
REMOVE: attempts to mitigate bugs by discouraging valid string content
REMOVE: the rule description states "As far as naming conventions for identifiers go, dangling underscores may be the most polarizing in JavaScript."
INCLUDE: attempts to mitigate logical errors in application flow
REMOVE: prone to warning you about a non-issue during the authoring process
REMOVE: attempts to mitigate a non-issue
REMOVE: rule warns about valid syntax
REMOVE: rule warns about valid (not discouraged or deprecated) syntax in favor of ES6 shorthand for the same
REMOVE: rule warns about use of string concatenation
REMOVE: no longer relevant in modern JS contexts
from eslint-config-netflix.
Note:
- no-fallthrough
- no-prototype-builtins
These may have been relaxed from error to warning in order to ensure former versions of ESLint would not bomb out in their occurrence (vs continue parsing)
from eslint-config-netflix.
@theengineear I know it's a lot to review but there's no specific urgency here. I'm looking for a cross-check on my disposition of the rules to be dis/included in 3.0 β my hope is to slim this thing down and not leave anyone in the lurch who wants to upgrade
from eslint-config-netflix.
Going to just mark this one-by-one and keep returning to this comment as I go:
π€ β array-callback-return
- I think I want this still. To me, using these methods carry certain semantics. If you donβt want to actually create an object, different methods exist with the appropriate semantics. Iβm mildly (not strongly) opinionated about this.
π β camelcase
π β class-methods-use-this
π β curly
- To me, this is is the kind of thing to pull forward like
semi
. If I want to be terse, Iβd probably use a ternary versus aif
, right? Iβm mildly (not strongly) opinionated about this.
π€ β dot-notation
- Sure, this is stylistic, but I also do think itβs a strange access pattern. Only fleetingly opinionated though. Iβm fine either way here.
π β guard-for-in
π β new-cap
π€ β no-bitwise
- While I agree that it feels somewhat silly to get in the way of a developer legitimately using bitwise operators, it feels actually bad to not warn a developer that accidentally wrote
|
to revisit to see if they meant||
. Iβm tempted to want to keep this one.
π β no-caller
π β no-empty
π β no-empty-function
π β no-eval
π β no-extend-native
π β no-iterator
π β no-lone-blocks
π β no-loop-func
- This rule is incredibly nuanced. I guess Iβm for it, but at some point, I do wonder if we ought to consider the performance cost of rules versus potential value π€
π β no-multi-str
π β no-new
π β no-plusplus
π β no-proto
π β no-script-url
π€ β no-sequences
- This also feels like a rule that would prevent tricky bugs. I donβt think this is terribly common to do and it would be frustrating to make a mistake and not have it be caught. Again, not super opinionated here, but I think this one might be more helpful than harmful to have.
π β no-template-curly-in-string
π β no-underscore-dangle
π β no-unused-expressions
π β no-useless-constructor
π β no-useless-rename
π β prefer-rest-params
π β prefer-spread
π β prefer-template
π β strict
from eslint-config-netflix.
Thanks for the review; I'll incorporate your feedback / respond soon and ping back here
from eslint-config-netflix.
Addressed by #21
from eslint-config-netflix.
Related Issues (8)
- Rename primary branch to main
- Publish latest to @Netflix/eslint-config-netflix HOT 1
- comma-dangle, quotes, semi rules moved to @stylistic/eslint-plugin-js HOT 1
- Consider no-require-imports inclusion
- Migrate to ESLint 9.0
- array-callback-return warnings HOT 1
- Don't manually update package-lock.json when publishing
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from eslint-config-netflix.