We Keep Coding

What lint configuration to use to eliminate the warning : Invalid JSDoc tag name

I am using eslint to set up my node js project but I keep getting the following warnings:
Now in my .eslint.json I am unable to find a rule/technique to help ignore these new tags and types. I have looked in the following documentation:
https://eslint.org/docs/rules/

I assume that you are also using https://github.com/gajus/eslint-plugin-jsdoc
If so then you have to add this rule to your eslint config file:
"jsdoc/check-tag-names": ["error", { "definedTags": ["consumes", "produces", "route"] }],
and whatever custom tags you also have in your docs...

Designate additional alias names for eslint consistent-this rule?

I recently started using the eslint module to help clean-up some JavaScript files. The following error is being reported when I lint one of my files:
127:17 error Unexpected alias 'me' for 'this' consistent-this
After checking the documentation, I understand the error is being reported because my code is assigning the value of this to a variable named me instead of that.
What is the proper way to configure my project's .eslintrc.json to make it so the following line of code is not reported as an error: var me = this;?

The rule should be like this in your .eslintrc
{
"rules" : {
"consistent-this": ["error", "me"]
}
}

ESLint warning in camelcase for locale code

I use ESLint for improving my code quality but I need it not warning some declaration such as locale code en_US.
ESLint warning for camelcase rule
If I add some configuration in comment just like the document told
/* eslint camelcase: ["error", "properties": ["never"]] */
import zh_TW from 'moment/locale/zh-tw';
ESLint still warning the camelcase issue. How can I turn the warning off in this case?

I have a doubt about the configuration line:
Doc says:
/* eslint camelcase: ["error", {properties: "never"}] */
But you did this:
/* eslint camelcase: ["error", "properties": ["never"]] */
( Edit: Buuut it does not seem to make a difference (see comments). Problem must be somewhere else )
Also I'm not sure you got #vahdet's suggestion:
import { zh_TW as zhTw } from 'moment/locale/zh-tw';
^^^^^^^
Then you use zhTw in your code instead of zh_TW, and no need for an exclusion for the linter :)

How to change an IIFE with an argument to ES6. [duplicate]

I am using Grunt as my Build Tool and ESLint as my linting tool for an app I am working on. I am also using the Underscore Node package, and have made use of it in my app. Unfortunately, when I run ESLint on my code, it thinks that _ is an undefined variable in the following line:
return _.pluck(objects, nameColumn);
This is the error it is giving me:
78:21 error "_" is not defined no-undef
I would prefer not to disable the no-undef rule for ESLint, and I have tried installing the Underscore plugin, but I am still receiving this error. If anyone else has any ideas for what to try with this, I would be very appreciative!
If there is any further information I can give that would help anyone with helping me get this figured out, just let me know!

The official documentation should give you an idea on how to fix this.
Any reference to an undeclared variable causes a warning, unless the variable is explicitly mentioned in a /*global ...*/ comment, or specified in the globals key in the configuration file.
The easiest fix would be to add
/* global _ */
at the top of your file.
Or better, explicitly specify that the variable is read-only, to disallow overwriting the variable:
/* global _:readonly */
But since you'll have to do that for each new js file, it can get annoying. If you are using underscore often, I'd suggest to add globals to your .eslintrc file, for example:
{
"globals": {
"_": "readonly"
}
}
And save this as .eslintrc in your project root, or optionally in your user home directory. Although some say the latter not recommended, it can sometimes be convenient, but you have to remember that you have it there :)
Explanation of the above rule: "_": "readonly" (used to be "_": false, now deprecated) means that a variable named _ tells eslint that this variable is defined globally and it will not emit any no-undef errors for this variable. As #sebastian pointed out, "readonly" (or false - deprecated) means that the variable can't be overwritten, so the code _ = 'something else' would yield an error no-global-assign. If you were to instead use "_": "writable" (or "_": true - deprecated), this means that the value can be re-assigned and the previously mentioned error will not occur.
But keep in mind that this will only happen if you assign directly to the global variable as I have shown in the example. You can still shadow it and eslint won't say anything. For example, these snippets wouldn't yield the no-global-assign:
const _ = 'haha I broke your _'
or as function argument name, e.g.
function (_) {
console.log(_, 'might not be the _ you were looking for')
}

If you are using jest for testing - in your environment - in eslintrc.json
"env":{
"jest":true
}

Has ESlint a rule about blank line before the first statement in function?

Due ESLint I found a rule newline-before-return about empty line before return statements. But did not see a rule about empty line before the first statement in function. F.e.:
function (a) {
var b = +a;
}
Has ESlint a rule about this? If it has, what is the name this rule?
Thanks

The padded-blocks rule allows you to require newlines at the start and end of blocks, including function bodies. In addition to function bodies, it also covers the bodies of if statements, for and while loops, and other block-like structures, which you may or may not want.
Try pasting the following code in the demo to see if it works for you:
/* eslint padded-blocks: "error" */
function foo(bar) {
if (bar) {
foo();
}
}
If you only want to check function bodies, you could follow #Dhananjay's suggestion and edit the rule's source code into your own custom rule.

I don't think there is such a rule available out of the box based on the list of available rules You can try to add a custom rule for this check as explained here

Such rule is implemented in the HAPI ESLint plugin, installed this way:
npm install #hapi/eslint-plugin-hapi --save-dev
// Add in your `.eslintrc`
{
plugins: [
'#hapi/eslint-plugin-hapi',
],
rules: {
'#hapi/hapi/scope-start': ['error'],
},
};
}
Or you may use it as part of HAPI ESLint config.
Mind, that Airbnb style guide recommends against padding blocks.