by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 02:53
    bconnorwhite commented #13693
  • 02:53
    bconnorwhite commented #13693
  • 02:53
    bconnorwhite commented #13693
  • 00:32
    nzakas closed #13079
  • 00:32
    nzakas commented #13079
  • 00:29
    nzakas closed #13675
  • 00:29
    nzakas commented #13675
  • Sep 29 22:39
    ljharb commented #13685
  • Sep 29 17:28
    eslint[bot] labeled #12809
  • Sep 29 17:28
    eslint[bot] locked #12809
  • Sep 29 17:28
    eslint[bot] commented #13625
  • Sep 29 17:28
    eslint[bot] labeled #13110
  • Sep 29 17:28
    eslint[bot] labeled #13625
  • Sep 29 17:28
    eslint[bot] locked #13110
  • Sep 29 17:28
    eslint[bot] closed #13625
  • Sep 29 17:27
    eslint[bot] labeled #13115
  • Sep 29 17:27
    eslint[bot] locked #13115
  • Sep 29 15:23
    mdjermanovic commented #13689
  • Sep 29 13:48
    RunDevelopment commented #13721
  • Sep 29 13:33
    mdjermanovic commented #13721
Jordan Harband
@ljharb
--quiet suppresses things set to "warn"
rouxfeur
@rouxfeur
I see. Thank you!
Jordan Harband
@ljharb
(but warnings don't fail the build, so it's not really a viable approach to set all non-autofixable to warn, in case that's what you're thinking)
rouxfeur
@rouxfeur
I was actually thinking about it haha 😄 but yeah, I agree. I think I’ll just run prettier —write && eslint —fix on save for a few days and will see.
Roy Sutton
@webOS101
You can always force a failure on build with --max-warnings 0. I don’t know whether that will also fail on fixable warnings or only unfixable ones, though.
(If you also wanted to be fixing at build time)
Kevin Partington
@platinumazure

@webOS101 --max-warnings only takes into account warnings left after autofix.

In practice this means non-autofixable warnings, although it could also happen if one rule's autofix causes a violation in another rule, and that rule's autofix causes a violation in another rule, etc. (in such a way that there is a cycle/loop). ESLint bails out after 10 autofix attempts, so in that degenerate case, an autofixable rule could fix and still leave a warning (on the 10th pass).

Roy Sutton
@webOS101
That’s what I suspected.
ku64
@Jaku6Rojek
Do you know how can I solve the this kind of problem:
ESLint couldn't find the config "eslint-config-airbnb-es5" to extend from. Please check that the name of the config is correct.
Kai Cataldo
@kaicataldo
Kevin Partington
@platinumazure
@Jaku6Rojek Did you intentionally extend from that config in your ESLint configuration? If not-- sounds like you are linting node_modules, which you shouldn't do.
Dimitri KOPRIWA
@kopax
hi
I am having issue with eslint --fix and lint-stagef
ESLint couldn't find the config "@ljharb" to extend from. Please check that the name of the config is correct.
The config "@ljharb" was referenced from the config file in "/home/dka/workspace/project1/server/node_modules/qs/.eslintrc".
Kai Cataldo
@kaicataldo
It sounds like you might be linting a nested node_modules directory. Best to ignore those using .eslintignore files.
tidel999
@tidel999_gitlab
I'm using the eslint extension with vscode. Do i have to configure anything special for the linter to work with mocha .test.js files?
does anyone know?
tidel999
@tidel999_gitlab
I created another .eslintrc.json file in my test folder and set the "root" to true. Is this the proper way to set up eslint for the test file
ku64
@Jaku6Rojek
@platinumazure I installed this npm install -g eslint-config-airbnb-es5 and wanted lint to use this schema to check the syntax.
@platinumazure Do you know how I can fix it?
Kai Cataldo
@kaicataldo
@tidel999_gitlab If you're only running ESLint on your test files, that seems like an okay thing to do, but I wouldn't necessarily recommend it. Generally, I would recommend creating a .eslintrc file in the root of the repository (i.e. where package.json is) and add root: true to that file. ESLint merges configs it finds in parent directories without root: true set.
Strider
@StreetStrider
Hello. I distribute my eslint config as a package. On the receiver end I require config as a whole. I want my plugins to be hard dependencies of my package and not the reciever. However I was unable to resolve plugins inside package when run eslint on receiver end. Is it possible to do so? Previously I resolve parser with parser: require.resolve('babel-eslint') inside the package, this trick does not work with plugins.
Jordan Harband
@ljharb
@streetstrider if your package is a shared config, then you have no choice and all of the plugins it includes must be peer deps, and thus must also be in the consumer's package.json
tidel999
@tidel999_gitlab
How do i properly setup eslint for mocha to work with my nodejs project?
I'm not sure what i am doing wrong. This is what i did
In my project root, .eslintrc.json file
{
"root": true,
"extends": [
"airbnb-base"
],
}
In the test/ folder
{
"plugins": [
"mocha"
],
"extends": [
"plugin:mocha/recommended"
]
}
The problem i have is that it still flags the prefer-arrow-callback rule
am i missing something?
Jordan Harband
@ljharb
still flags it where
the mocha plugin would have to disable that core rule for what you want, i think
tidel999
@tidel999_gitlab
simplest example to reproduce

describe('testing', function a() {
it('test', function b() {

});
});

it flags the prefer-arrow-callback rule
it shows
1:21 error Unexpected function expression prefer-arrow-callback
2:14 error Unexpected function expression prefer-arrow-callback
the file is located at test\newapp.test.js same directory as the .eslintrc.json file that contains the mocha plugin line
Kai Cataldo
@kaicataldo
You'll need to add this to the .eslintrc.json in the test/ directory:
{
  "rules": {
    "prefer-arrow-callback": "off"
  }
}
tidel999
@tidel999_gitlab
this only disable that particular rule, but there are other rules in the plugin that flags too
Kai Cataldo
@kaicataldo
This is a core rule, not a plugin rule
I don't think it matters with Mocha though, right? I don't think Mocha has Jasmine's magic this.
tidel999
@tidel999_gitlab
@kaicataldo Thanks alot. I guess thats the only way to solve it.
Kai Cataldo
@kaicataldo
That rule is turned on because you're extending off of airbnb-base
tidel999
@tidel999_gitlab
I'm not familiar with eslint. Is there a reason why they do not do this in the plugin itself?
Kai Cataldo
@kaicataldo
Do what?
tidel999
@tidel999_gitlab
the "prefer-arrow-callback": "off" rule itself
Kai Cataldo
@kaicataldo
I don't think there's a reason for the mocha plugin to