A ruthless--though not arbitrary--degree of control for your kingdom!
One ring to rule them all!
npm i -D eslint-config-ash-nazg
install-peerdeps -d eslint-config-ash-nazg
See main.js (and node.js for ash-nazg/node
rules) for the rules we explicitly include (and see
sauron.js for the even stricter ash-nazg/sauron
rules or
great-eye (or great-eye-node) for
still stricter rules though which are probably best not used).
(See explicitly-unused.js for the core and extended rules we don't include (rationale for non-inclusion below).)
- Main rules (also search for "error" within
eslint-recommended.js
of@eslint/js
) for theeslint:recommended
rules we inherit (though see below for our two modifications to these). - "standard" rules we inherit (though see below for our handful of modifications).
- eslint-comments/recommended
- eslint-plugin-no-use-extend-native for one added rule.
- eslint-plugin-no-unsanitized for two added rules.
- Recommended Unicorn rules (a few items disabled and enabled as per below)
- eslint-plugin-array-func for further rules
I've focused below on deviations because the original sites tend to already articulate the usefulness of the rules I have incorporated for these plugins/configs. This is for tracking design choices and not disparaging the utility of non-included rules.
The ash-nazg/node
config expands upon the regular ash-nazg
rules to
add rules specific to Node environments. Specifically,
plugin:node/recommended-module
has been adopted for now along with
some stylistic choices. However, if you are using more CJS exports,
you can override this by adding plugin:node/recommended-script
to your
extends
array (after ash-nazg
) or, for Sauron-Node, by using
sauron-node-script
.
The ash-nazg/node
configs also detect minimum Node from engines
and set
env
to use the highest supported ES globals, e.g., ES2021
(and also sets
node: true
) as well as sets ecmaVersion
.
The ash-nazg/sauron
config expands upon the regular ash-nazg
rules to
indicate what are generally best practices but are less likely to be due to
an error and may possibly also require a high (and possibly tyrannical)
degree of refactoring for existing projects. See below for the rationales
for inclusion.
The ash-nazg/great-eye
and ash-nazg/great-eye-node
configs expands on
ash-nazg/sauron
(and ash-nazg/sauron-node
) to include
rules which enforce good practices, but which are so cumbersome and may
flag too much legitimate code that I personally won't regularly use them.
Still, I like to track them here, including in the event that their
config changes to make them less all-encompassing.
The ash-nazg/sauron-node
config incorporates both ash-nazg/node
and
ash-nazg/sauron
. It adds specific rules of its own which may be unduly
strict for ash-nazg/node
.
A few experimental configs have been added as well, though this might be removed or significantly modified in a future version:
+script-node.js
: Applies script source type with Node; used bysauron-node-script
+script.js
: Applies script source type for non-Node; used bysauron-script
sauron-node-overrides.js
:sauron-node
withrc
andmocha
sauron-node-script-overrides.js
):sauron-node-script
withrc
andmocha
sauron-overrides.js
:sauron
withrc
andmocha
sauron-script.js
:sauron
with+script.js
filesauron-script-overrides.js
:sauron-script
withrc
andmocha
+babel.js
: Wraps a module to support equivalent babel/eslint-parser rulesmocha.js
: Sets up Mocha (andchai
global) on test directories (via overrides)mocha-plus.js
: Strict but reasonable rules for checking Mocha/Chai (not naming "sauron" as not bundling with Sauron)cypress.js
: Strict but reasonable rules for checking Cypressoverrides.js
: Config for overrides to give browser directories, and config and RC config files suitable default config
eslint-config-ash-nazg
is a collection of some excellent preexisting
rules other projects have created, curated with the intent of attaining
productive strictness.
"standard" (config)
and eslint:recommended
have brought a welcome degree of
pseudo-standardization for code styling and error checking.
However, they do not impose as high of a degree of control as one may find desirable to enforce common, sane styling practices, catch bad practices and hard-to-read patterns, or in some cases even catch errors.
Moreover, standard
enforces a few styling rules which are contrary to
regular JavaScript practice (e.g., its enforced absence of semi-colons).
ash-nazg
aims to offer defaults which adhere to norms, build upon
productive restrictions, and in a few cases, offer greater latitude
where some constraints are unduly confining.
To see which rules from an extended config ended up enabled (we are
typically inheriting "recommended" configs), see
/inherited-rules/implicitly-included
.
To see which rules from the extended config we disabled, see our relevant
config(s) (e.g., main.js
).
To see which rules from the plugin that each extended config derives from
(i.e., the non-recommended rules of a plug-in), see explicitly-unused.js
for ones we have consciously not used and see our relevant config(s)
(e.g., main.js
) for the ones we did add (alongside any recommended).
The unused
folder is used to capture any (non-recommended) rules which
are not explicitly either enabled or within explicitly-unused.js
(as
might be found during an update of our config dependencies), but it is
currently, and should hopefully remain, empty, as we wish to be
consciously aware of all rules from inherited projects and whether we
wished to include them. As far as new rules added to recommended
, we
can see these within diffs of inherited-rules/implicitly-included
files (built during development by npm run compare
).
Besides incorporating more from ESLint core, we also add rules from a few other (peer) dependencies.
eslint-plugin-compat
- Though its list of browsers to support is not added by our code, it is a basic enough of a need to remind one of its need to be present (and to avoid needing to add the rule for it).eslint-plugin-import
- Besides being peer dependencies ofstandard
, this has some additional useful rules we apply.eslint-plugin-jsdoc
- provides a number of helpful rules for catching bad or incomplete JSDoc during development. Note that we do not imposejsdoc/require-jsdoc
except as a warning inash-nazg/sauron
mode, so all of theeslint-plugin-jsdoc
rules should only apply when JSDoc is used. We also avoid some ofeslint-plugin-jsdoc
stricter checking requirements for descriptions.@eslint/markdown
- Another basic use case is ensuring code snippets are linted, which is why this is expected. You may find ESLint's discussion ofoverrides
helpful for tweaking rules for Markdown (and you may also wish to useoverrides
, for theeslint-plugin-jsdoc
rulecheck-examples
if you wish to lint your JSDoc examples according to different standards). In ESLint 7 it is no longer necessary to pass the file extension within the--ext
flag, e.g.,--ext js,md
to get this to take effect when used inoverrides[].files
(though it does seem to be required to includemd
if you do use--ext
).eslint-plugin-html
- One basic use case is ensuring HTML is linted, which is why this is expected. You may wish to useoverrides
for HTML-specific rules or enable the plugin's own rules. In ESLint 7 it is no longer necessary to pass the file extension within the--ext
flag, e.g.,--ext js,html
to get this to take effect when used inoverrides[].files
(though it does seem to be required to includemd
if you do use--ext
). (The HTML plugin lacks the Markdown plugin's ability to treat separate blocks differentially, but an issue was filed requesting support.)eslint-plugin-promise
- Besides being peer dependencies ofstandard
, this has some additional useful rules we apply.
In comparison to eslint:recommended
, ash-nazg only adds restrictions with
the exceptions of:
- Loosening the ESLint < 6 requirement of
no-console
into a mere warning and only in the stricterash-nazg/sauron
configuration. This is for the reason that console logging is too useful for debugging (and sometimes for reporting progress) to have to disable it at every turn and to distract one from actual errors. - Change
no-empty
so thatallowEmptyCatch
istrue
. There are enough cases where one legitimately needs to suppress errors.
semi
- Even if not strictly required, semi-colons are conventional in JavaScript and help denote the end of statements (as opposed to the end of a line which may continue).indent
- While it may take some getting used to, 2 spaces does allow more in one's field of vision. However, changed to useouterIIFEBody
for avoiding indents with the IIFE body, as this often minimizes indent level for much or all of the whole file.object-property-newline
- Properties on the same line can be very convenient, including stacking for space to avoid max length (though without stacking the height too high).one-var
- While I normally favor enforcing conventions, this one seems to me to be of little consequence. It also prevents grouping like items together. I might favor an option to require separate lines for variable declarations, but for uninitialized ones, adding to the same line is convenient, especially for single-letter variables. I would like a rule to have declarations as close as possible to being just above any used scopes (forlet
andconst
).object-curly-spacing
- Not sure whystandard
switched from the default here.quotes
-avoidEscape
is too reasonable to avoid ugliness;allowTemplateLiterals
is useful to begin a pattern that may expend to allow other quotes or dynamic variables.object-curly-newline
- Doesn't allowlet f = {foo () { dosomething(); }};
lines-between-class-members
- Don't feel any need for it@stylistic/spaced-comment
- Addingmarkers
for sake of TS-style/// <reference>
comments.
While these are not part of standard
or eslint-recommended
, I've noted
here why we have deviated from the defaults set by ESLint for those applying
the rule.
array-bracket-newline
- Switched to "consistent" over "always" as sometimes nice to be a little condensed, especially when representing HTML as JSON within Jamilih (or JsonML) templates.function-paren-newline
- The default multiline can get too long whereas "consistent" can be clean and short.multiline-ternary
- Inline ternary can be very readable when not spanning linesno-empty
- Empty catches occur frequently enough to justifyallowEmptyCatch
no-mixed-requires
- Grouping is more organized, while calls are compellingly convenientno-warning-comments
- As pergreat-eye
discussion of this rule, to-dos can be useful, but we nevertheless include the rule withterms
set tofixme
andxxx
so we reject these other forms oftodo
. To also rejecttodo
, seegreat-eye
.no-restricted-globals
- Use example defaults forevent
(andfdescribe
) as convenientno-restricted-properties
- Use example default of restricting__defineGetter__
in favor ofObject.defineProperty
as convenientno-restricted-syntax
- Set to eliminate any use ofinstanceof
(as it is not cross-frame safe, except if usingSymbol.hasInstance
)no-shadow
- It is better practice not to confuse by using globals! I didn't feel the examples for allowing necessitated their use. I added"parent"
,"top"
,"open"
,"close"
,"stop"
,"blur"
,"status"
,"name"
,"closed"
, and"start"
toallow
as frequent local variables technically shadowing globals (start
for QUnit env).object-shorthand
- EnablingavoidExplicitReturnArrows
as methods withoutthis
that this rule grabs (which have their own meaning with arrow functions) are more succinctly expressed in shorthand, and shorthand also conduces better to events wherethis
refers to the element (unless one needs the outer scopethis
). The optionavoidExplicitReturnArrows
does not avoid if the functions havethis
(though this isn't currently documented); this is probably good, though use ofthis
may signal an error if within a methodprefer-destructuring
- Did not set array to true due to its problems with direct access of large numbers (requiring many commas) and non-iterable ‘array-like’ objects.quote-props
- Changed to "as-needed" as properties more verbose and uglier with quotingradix
- We're only dealing with ES5+ environments, so the radix is redundant for base 10.import/order
- Enforcing "builtin", "external", "internal" and then ["parent", "sibling", "index"] in any order as these may be project-specific.import/no-unresolved
-fs/promises
should be allowed by default as a Node module.@uce/reactive
is just a virtual package (as used byuce-template
.
The following rules are not included within eslint:recommended
or standard
,
nor have we chosen to include them in any of the ash-nazg
rules.
Note: italicized items refer to features I might enable if the described
option could become available (or upon further review). I might also tweak
some standard
rules further which I have not had time to examine (but
it would probably be toward the stricter rather than looser as I have been
happy with it thus far).
array-element-newline
- While the "consistent" option would be nice, it doesn't work well to keep up with a max width and the desire to avoid excessive height[\n a, b, \n c, d\n]
arrow-body-style
- Withas-needed
andrequireReturnForObjectLiteral
, this seems reasonable, but too often in debugging, one needs to add brackets to do any logging.func-names
- Too prohibitive, though if applied to methods only, it may be useful (though with object shorthand, less necessary)func-style
- Declarations are simpler so appealing also. If enabling, would also wantallowArrowFunctions
.id-blacklist
- Can be helpful but a little tyrannicalid-length
- Can be helpful (especially a minimum) but a little tyrannicalid-match
- Too project-specificinit-declarations
- Nice with "always" andignoreForLoopInit
, but cumbersome and seemingly wasteful at timesline-comment-position
- Too inflexible to enforce either waylines-around-comment
- Irksome to memax-classes-per-file
- A bit tyrannicalmax-depth
- Sounds good but tyrannicalmax-lines-per-function
- A bit tyrannicalmax-lines
- A bit tyrannicalmax-params
- Can be troublesome when one is forced to abide by some APImultiline-comment-style
- Would be nice if allowed multiline "starred-block" OR "bare-block" given some one may wish as JSDoc-style and others notnewline-after-var
- Not very flexible (deprecated)newline-before-return
- Not very flexible (deprecated)newline-per-chained-call
- Not flexible in practiceno-continue
- Can be convenientno-inline-comments
- Can be faster and more succintno-invalid-this
- Sounds good but not useful for element event handlers/jQueryno-multi-assign
- Sounds good, but can be burdensomeno-negated-condition
- Is generally simpler, but it can be annoying if one wishes to get a much smaller condition body visible at the top.no-nested-ternary
- Nested ternaries can be helpful to avoid clutter of duplicated assignment codeno-param-reassign
- Can be helpful, but not convenient, including when making defaults against more thanundefined
(e.g.,null
)no-restricted-imports
- Project-specificno-restricted-modules
- Project-specificno-ternary
- Not usefulno-undefined
-undefined
is ok for ES6 modules and strict code, so usingno-global-assign
andno-shadow-restricted-names
insteadno-underscore-dangle
- Too restrictiveno-useless-concat
- Too restrictive when one has certain formatting one wishes to draw outone-var-declaration-per-line
- Sounds good, but too cumbersome for small integer or boolean inits, and the indented next lines are not as immediately clear that they belong to the declaration.padding-line-between-statements
- Might revisitprefer-arrow-callback
- Not compellingprefer-template
- Sounds good, but too cumbersome in practicerequire-atomic-updates
- Many false positivessort-imports
- Would be useful with "warn" if could sort by multiple/single type and sort members while avoiding alphabetical sorting across imports which seems too rigidsort-keys
- Too cumbersomesort-vars
- Too cumbersome
import/no-restricted-paths
- Project-specificimport/no-internal-modules
- Useful but have to specify, so project-specificimport/no-import-module-exports
- Seems redundant for normal CJSimport/no-cycle
- Don't see a problem with cyclic imports in ESMimport/no-nodejs-modules
- Useful for some projects, but not all including even client-side (though does offerallow
option)import/no-relative-packages
- Not needed for general environmentsimport/exports-last
- Has some reason for being, but nicer to see with declaration that the object is being exported. To find all, just search for "export"import/no-namespace
- While can be more efficient to import only what one needs, having a namespace can also avoid confusion.import/prefer-default-export
- Could even be a bad practice as ugly to import with non-defaults added laterimport/no-default-export
- Has some basis, but defaults are admittedly convenient. Let's not be so opinionated.import/no-named-export
- Could even be a bad practice as ugly to import with non-defaults added laterimport/no-relative-parent-imports
- Appealing in some ways, but too rigid for a broad standardimport/dynamic-import-chunkname
- Might revisit for warnings, but probably too specific for a broad standardimport/max-dependencies
- Too constrainingimport/no-unassigned-import
- Could be useful withallow
option, but that would be project-specific, and unassigned imports are needed for polyfillsimport/group-exports
- Too rigid as withexports-last
.
no-process-exit
(added by Node recommended) - has a version in Unicorn
which allows in CLI apps.
node/no-missing-import
- Redundant with import/no-unresolved
node/file-extension-in-import
- Redundant with import/extensions
and has no
ignorePackages
option currently.
node/prefer-promises/dns
and node/prefer-promises/fs
are good, but
a bit early with Node 12.
node/no-restricted-import
- project-specific
node/no-restricted-require
- project-specific
promise/no-native
is disabled as promises are essential--even, it
appears, to Dark Lords.
promise/param-names
can be too tyrannical in some cases.
promise/no-nesting
- can be useful to nest sometimes
promise/no-promise-in-callback
- May be difficult to apply (Note: Is disabled in main.js
but enabled in sauron.js
)
promise/no-callback-in-promise
- May be difficult to apply (Note: Is disabled in main.js
but enabled in sauron.js
)
promise/avoid-new
- Can be useful or even necessary for APIs missing Promise version (Note: Is disabled in main.js
but enabled in sauron.js
; could use promisify
)
promise/no-return-in-finally
- (Note: Is disabled in main.js
but enabled in sauron.js
)
promise/valid-params
- (Note: Is disabled in main.js
but enabled in sauron.js
)
jsdoc/no-blank-blocks
- Too useful to progressively build docs with blank onesjsdoc/check-line-alignment
- More desirable default not yet implementedjsdoc/informative-docs
- Too troublesome to deal with descriptions as it isjsdoc/no-blank-block-descriptions
- Bad for debuggingjsdoc/no-types
- Types have utility in jsdoc unless using TypeScriptjsdoc/newline-after-description
(recommended) - I can see its draw, but seems too pedantic to me for documentation.jsdoc/no-defaults
- Haven't transitioned to TypeScriptjsdoc/no-undefined-types
(recommended) - I'd like something like this, but since it isn't aware of all of one's@typedef
s, etc., it is too restrictive for me at this time.jsdoc/require-description-complete-sentence
seems like a good idea, as English mistakes can be jarring as with bad styling, but this didn't seem to work too well. I usejsdoc/match-description
with a special value to capture a subset of this.jsdoc/require-hyphen-before-param-description
- I can see its draw, but seems too pedantic to me for documentation.jsdoc/sort-tags
- A bit oppressive (and probably a bit unstable still as a new rule); might revisitjsdoc/no-missing-syntax
- Nothing currently wish to enforcejsdoc/no-restricted-syntax
- Nothing currently wish to enforce
(The following are recommended rules unless otherwise noted.)
catch-error-name
- It can actually be useful to use different error names to indicate what type of error may be expected.consistent-destructuring
- In practice can be cumbersomeconsistent-function-scoping
- Though this can be useful, and it shouldn't be difficult to manually hoist functions upward, besides taking some time to refactor, this often removes functions from a logical grouping, and may even increase bugs, as one may be tempted to move out a function whose dependency is no longer wrapped with it.empty-brace-spaces
- Easier to build on and cleaner if allowing newlinesexplicit-length-check
- Seems wasteful.filename-case
- Looks potentially useful withcamelCase
.import-index
- While understandable, seems may cause more trouble in making it harder to find references toindex
.import-style
- Usingeslint-plugin-import
insteadno-array-reduce
- Though I can see some appeal to this (andreduce
also suffers from not being able to short-circuit), I like it for object property accumulation, conditional array accumulation that can later be flattened, etc. It also seems superfluous to add an extrajoin
with string concatenation.no-array-for-each
- Writing code forforEach
allows later refactoring, e.g., to move out of the block.no-await-expression-member
- A bit confining for convenience for only a little gainno-instanceof-array
- Covered by our blocking of allinstanceof
no-keyword-prefix
- See no need.no-lonely-if
- Nested ifs can be useful to catch and ignore.no-negated-condition
- Good but cumbersomeno-nested-ternary
- As with eslint'sno-nested-ternary
no-null
- A good idea, but besides use ofnull
in JSON, and semantic arguments in favor (having an explicit, intentional empty value), it makes for cleaner, quicker to understand code.no-typeof-undefined
- Ok but cumbersome, especially if global situation is complicatedno-unreadable-array-destructuring
- Better to use this than multiple linesno-unused-properties
- While no doubt useful, it won't catch all cases, sounds computationally expensive, and may better be done with TypeScriptno-useless-switch-case
- Still useful for flagging a viable value or faciliating later expansionno-useless-undefined
- I don't like the consequence of changingarray-callback-return
toallowImplicit
, and it can make clear that use ofundefined
is deliberate.prefer-array-flat
- Present inarray-func
prefer-array-flat-map
- Present inarray-func
prefer-at
- Not widely availableprefer-exponentiation
- Now present in eslint coreprefer-export-from
- Understandable but cumbersome when importing anyways and have to use another styleprefer-json-parse-buffer
- Not recommended now and may be less performantprefer-module
- Handling by different configs insteadprefer-node-protocol
- Might revisit later if practice becomes adoptedprefer-object-from-entries
- Too many false positives (e.g., non-simple objects)prefer-optional-catch-binding
- Understandable rule, but extra work if refactoring to add later, and the catch binding can also force documentation of the error's purposeprefer-prototype-methods
- Sometimes a bit cumbersomeprefer-string-slice
- Added to Sauron but can be cumbersome to change for old projectsprefer-string-replace-all
- Good but not available yet in Node (even 14)prefer-top-level-await
- Good requires Babel currentlyregex-shorthand
- Was renamed tobetter-regex
.string-content
- Don't want the trouble of requiring formatted apostrophes (not recommended anyways).switch-case-braces
- Reasonable but burdensome as may not need bracestemplate-indent
- Although attractive, requires tooling to be reliable.throw-new-error
- Potentially confining.
better-regex
- Character classes can be arranged for readability.
unicorn/custom-error-definition
- Does not seem confining.unicorn/no-unsafe-regex
- Seems like something to watch for, though I may revisit if this reports too many common expressions.unicorn/require-post-message-target-origin
- Useful for common cases
eslint-comments/no-unused-disable
- Might be indicative of an error and inefficient in any case
eslint-comments/disable-enable-pair
- If at top, behavior is clear, and
no need to reenable within doc
eslint-comments/no-restricted-disable
- See no needeslint-comments/no-use
- See no need
array-func/prefer-array-from
- While it may benefit performance, it is more sleek to use the spread operator. Would like to know how much it impacts performance before enabling.
(All sonarjs rules are currently "recommended" rules as well except as noted.)
elseif-without-else
- Good rationale but burdensome (not recommended)no-nested-switch
- Arbitrary and not helpful for cleaner codeno-nested-template-literals
- Somewhat reasonable, but also arbitrarymax-switch-cases
- Sounds too arbitrary.no-collapsible-if
- Sometimes more logically clear or made in preparation for future expansionno-duplicate-string
- Often used in test files and repeated in fairly minor instances or instances repeated but spread out within a large fileno-identical-functions
- Often used in test files and repeated by fairly minor functions or functions repeated but spread out within a large fileno-small-switch
- Too useful to start a pattern to which one intends to add later.prefer-immediate-return
- Can be useful for documenting even if method name should be descriptive, especially if there are different returns with subtly different results
check-examples
- If examples are present, they ought to follow one's standards, including if overrides are in place to loosen/tighten. Set to match any Markdown rules (.md
extension) by default and excludes any example beginning with a backtick.check-syntax
- Following typescript, not Closure syntaximports-as-dependencies
- Usefulmatch-description
- Cleaner to see complete sentences which its default allows.no-bad-blocks
- Useful to catch blocks likely intended as jsdocrequire-returns-check
- If the return value doesn't match, there may be a problem.require-file-overview
- Don't need@file
in every file.
These are good practices, but cumbersome, not as familiar to developers, prohibitive during ongoing debugging or conversion of existing projects, etc. But perhaps useful for a new project which can pay closer attention to standards without the undue burden of having to refactor lots of code (which may not all be under one's control).
class-methods-use-this
- Good for new code (though even here may need disabling). May break existing APIs.consistent-this
- A good practice, but sometimes, especially with jQuery or DOM event handlers, and large functions where it can be difficult to track what a genericthat
is in reference to,this
may be more clearly named as the objectdefault-case
- Refactoring code to know whether to throw or silently ignore requires time.no-implicit-globals
withlexicalBindings
totrue
- Light browser apps might now wantmax-len
- May require a lot of refactoring.no-alert
- No quick easy replacement yet with poordialog
support.no-console
- Useful for debugging (and sometimes for reporting progress) to have to disable it at every turn and to distract one from actual errors, even for production.no-empty-function
- Cumbersome to add comments within every no-op.no-shadow
- Can catch errors, but also some work to refactor (See also section "Rationale for changing required rules' configuration away from defaults".)prefer-numeric-literals
- Good but some work.require-unicode-regexp
- Good, but some work to fix all.vars-on-top
- Not needed forlet
/const
, and if overriding, this is cumbersome, despite being usefulimport/unambiguous
- A good practice, and one whichoverrides
can override (e.g., for polyfills or simple HTML tests), but cumbersome to label all filespromise/prefer-await-to-callbacks
- Sometimes useful, but callbacks may be used within repeating eventsunicorn/no-array-callback-reference
- May be cumbersome though does catch potential problemsunicorn/prefer-number-properties
- Good but some refactoring needed (and not always readily fixable).jsdoc/require-returns
(recommended) - Put inash-nazg/sauron
as it is more than just a consistent styling convention, and it is not impossible to follow, but a bit difficult. AddedforceRequireReturn
option to ensure return type considered even ifvoid
/undefined
and addedcontexts: ['any']
so it checks virtual functions (e.g., with@implements
).jsdoc/require-jsdoc
(recommended) - Imposes a heavy burden on preexisting large projects (added as "error" ingreat-eye.js
); we have expanded its options there though to check onClassDeclaration
,ClassExpression
, andMethodDefinition
in addition toFunctionDeclaration
. This may stillFunctionExpression
andArrowFunctionExpression
, and these may admittedly be used on such as exports, but until the context option discussed at gajus/eslint-plugin-jsdoc#384 may be fixed, that may be too oppressive to impose.jsdoc/require-param-name
(recommended): Expanded this tocontexts: ['any']
; see description forjsdoc/require-jsdoc
.jsdoc/require-param-type
(recommended): Expanded this tocontexts: ['any']
; see description forjsdoc/require-jsdoc
.jsdoc/require-returns-type
(recommended): Expanded this tocontexts: ['any']
; see description forjsdoc/require-jsdoc
.jsdoc/implements-on-classes
- Added withcontexts: ['any']
; see description forjsdoc/require-jsdoc
. Better to be TypeScript-compatible.
The forceRequireReturn
setting was also applied therein as it may be
cumbersome to add to all returns or not favored as a requirement in
all projects though it does note that a method's return was considered
even if undefined
.
The preferredTypes
setting was enabled here as it can be cumbersome
for projects to specify all child types.
capitalized-comments
- May be very prevalent; reports with commented out codecomplexity
- A generally good practice, but can be work to refactor, and sometimes impractical to enforce.no-shadow
withhoist: 'all'
- A person should generally be able to track what they have in a function and it can be useful to reuse the variable name, but to really prevent any possible confusion, this should be set.max-statements-per-line
- Tyrannical when prohibiting single-lineif (...) { continue; }
; might revisit if allowed for control statementsmax-statements
- A bit tyrannical even if good for clear codeno-magic-numbers
- Very helpful for clear code, but cumbersome, and sometimes very cumbersome.no-plusplus
- Would be nice if there were an option to allow if not combined inline with other expressionsno-warning-comments
(with default value onterms
option blocking "todo") - Good to catch to-dos, but better to search or parse code as a separate process rather than polluting one's ESLint warnings--some to-dos are ok to be left for the long termimport/no-unused-modules
- Useful (formissingExports
at least), but doesn't catch dynamic imports and reports for other deliberately non-modular scriptsjsdoc/check-alignment
(recommended) - A pretty good practice, but not that important.jsdoc/check-indentation
- A pretty good practice, but that that important.jsdoc/require-description
- Though a very good practices, this is difficult for large code bases to implement and even cumbersome for new ones to have to follow for lesser parameters, so that's why they are not even inash-nazg/sauron
, though if you feel you can succeed at imposing such rigor for your hordes of developer minions, by all means, have a hand at it...jsdoc/require-param-description
(recommended) - Seejsdoc/require-description
.jsdoc/require-returns-description
(recommended) - Seejsdoc/require-description
.jsdoc/require-property-description
(recommended) - Seejsdoc/require-description
.jsdoc/require-example
- Seejsdoc/require-description
.sonarjs/cognitive-complexity
- As withcomplexity
perhaps (though may add to sauron if demonstrates not to be too oppressive)unicorn/numeric-separators-style
- Good but may involve many changes.unicorn/prevent-abbreviations
- Very cumbersome for frequent conventions such ase
forevent
unicorn/prefer-set-has
- Very good, but troublesome to refactor.unicorn/prefer-object-has-own
- Good but only available by polyfill
The preferredTypes
setting was enabled here for integer/float as it can
be cumbersome for projects to distinguish and because Promise
even
subclassed doesn't indicate the rejector type.
@brettz9/for-of
- Iterating functions can be easier to refactor
no-implicit-globals
- Included despite not applying to modules, in case overriding.strict
- Included despite not being needed for modules, in case overriding.
no-return-await
- As per this issue, it causes problems with stack traces and fails to flag function return as async (particularly in conjunction withrequire-await
which effectively enforces not usingasync
on such functions either).prefer-object-has-own
- Not yet supported in all Node- (This section is incomplete)
Deprecated and removed items from ESLint are also naturally not included.
While I will admit to being opinionated, and one may need to disable some rules (or possibly add a few ones mentioned in my non-inclusion sections), feel free to file issues if you really feel there are compelling reasons for different defaults. But again, I have to add caution that ring bearers can be picky about giving up their preh-shus...
- Restore the following as may become available in flat config:
- eslint-plugin-import
- eslint-plugin-unsanitized
- @fintechstudios/eslint-plugin-chai-as-promised (has PR)
- eslint-plugin-mocha-cleanup (has PR)
- Waiting: Add eslint-plugin-no-constructor-bind when class properties start landing
- Add own rules:
- tweak for
no-new-object
; now no-object-constructor - allow npm_config_* with
no-process-env
- to-do query tool/extractor
- tweak for
- Review https://github.com/dustinspecker/awesome-eslint#practices
- See if https://github.com/sarbbottam/eslint-find-rules may eliminate need for our comparison code
- Rule for no functions with
this
(to useclass
)? Might adapt https://github.com/matijs/eslint-plugin-this? - To consider:
- https://yeonjuan.github.io/html-eslint Lint HTML itself
- https://github.com/ota-meshi/eslint-plugin-regexp
- https://github.com/BrainMaestro/eslint-plugin-optimize-regex (Catches basic errors like
/{/u
and/(/
too) - https://github.com/ota-meshi/eslint-plugin-jsonc
- https://www.npmjs.com/package/eslint-plugin-const-case
- https://github.com/johnstonbl01/eslint-no-inferred-method-name / https://github.com/johnstonbl01/eslint-no-inferred-method-name/blob/master/docs/rules/no-inferred-method-name.md
- https://github.com/getify/eslint-plugin-proper-arrows
- https://github.com/selaux/eslint-plugin-filenames
- https://github.com/kantord/eslint-plugin-write-good-comments
- See also
eslint-plugin-privileges
for plugins/config to add for security/transparency - Make plugins/tool config/toolkit?
- https://github.com/not-an-aardvark/eslint-plugin-eslint-plugin
- https://github.com/j-f1/eslint-docs
- https://github.com/jfmengels/eslint-rule-documentation
- https://github.com/sarbbottam/eslint-find-rules
- https://github.com/pimlie/eslint-multiplexer
- https://github.com/wagerfield/eslint-index
- https://github.com/nickdeis/eslint-plugin-notice
- https://github.com/eslint/generator-eslint (global install of
yo
also) - Note
eslint --print-config file
for getting at applied config for a file