SublimeLinter-eslint: Error when eslint can't find an .eslintrc
Steps to reproduce
- Open a new window.
- Set the syntax to
JavaScript.
Result
The console opens and the following message is printed:
SublimeLinter: #154 eslint <untitled 718> ERROR:
Oops! Something went wrong! :(
ESLint: 4.18.2.
ESLint couldn't find a configuration file. To set up a configuration file for this project, please run:
eslint --init
ESLint looked for configuration files in /opt/sublime_text and its ancestors. If it found none, it then looked in your home directory.
If you think you already have a configuration file or if you need more help, please stop by the ESLint chat room: https://gitter.im/eslint/eslint
Environment
Sublime Text 3157, Linux x64.
This linter will try to invoke eslint on any JavaScript file. However, not every file or project has a lint configuration, and when none is present this package prints an error message on every modification. This can be very disruptive if the user is doing something with the console.
Possible solutions
- Silently ignore that particular eslint error.
- When that error is received, disable linting for that view.
- When that error is received, offer the user a choice (via dialog) to disable linting.
- Don’t try to lint anonymous views.
- Check before linting whether a config file can be found and don’t run the linter if none exists.
- Use a default eslint config when none can be found.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 15
- Comments: 30 (21 by maintainers)
I’m not sure this is a solution. I’ve created the “global” .eslintrc file, but now the linter is complaining that
The keyword 'const' is reserved, in the first line of every file, because that’s an ES6 feature that is not enabled by default with the empty configuration file.Can’t you just ignore the error when the .eslintrc file is missing, instead of showing that popup? I believe that should be the default behaviour, without requiring every user to manually create a configuration file for getting rid of that popup…
It would also avoid eslint to be launched frequently for no reason, when there are no rules to enforce.
If you set up an empty .eslintrc in your home dir, it will indeed work. Just a simple
will work fine. Previously however, we didn’t have this problem. It’s the latest updated to SL4 that caused this. Easy workaround, but should probably be in the docs somewhere. Troubleshooting maybe? I’m more than happy to add it if you find it useful.
Not really. We throw any and all javascript files at eslint (unless configured otherwise) and having an eslint config in your home dir ensures it can always find a config. There is nothing hacky about that.
There’s another thing to take into account here. If you have not installed eslint globally (npm install -g eslint or yarn global add eslint), then this error will not show up, even without that empty .eslintrc in your home directory.
I know eslint supports both local and global install (and so does this plugin). I try not to have global installs if I can help it, so maybe that’s why I also run into this issue less frequently.
FWIW
disable_if_not_dependencysetting, which will enable (if set) this plugin only when eslint is locally installedFWIW: Update from today will demote the config error. 😅 You need SublimeLinter 4.3 and the new whatever eslint version for that.
We had this pushed as pre-release for one week. So I hope we didn’t mess it up. 🤞
Regarding this problem that @matteocontrini mentioned:
I was getting a similar problem where the call to eslint itself was failing. And once that happened, none of my js files were being linted.
After a bit of frustration, I realized that somewhere on my system I still had v0.10 installed and this was being used to run eslint (instead of my user’s nvm version of node).
I simply upgraded the global version and the eslinter is working fine now.
As far as I’m concerned, there are two ways to enable/disable the linter, and none of them depend on this specific plugin.
.sublime-project.As to guessing the user’s intention, I don’t think we can do this reliably. We have API access to opened files, so we know the currently viewed file. We could traverse the tree upwards and if there is no eslint, don’t display errors, but up to where?
Even so, can we tell SublimeLinter to disable a linter from a plugin? Or do we just ignore the error (not even ignore it, just don’t show the console).
For individual files that you don’t want linted? I’m not sure what to do. In an ideal world, we’d lint them on demand (meaning, linter is disabled and we manually say lint this view) - which is what I think option 2 above does.
I agree. The workaround removes the error message from the console but adds spurious error regions. In addition, it’s annoying to have to create a dummy global config file on every computer I run Sublime on.
Thank you @tricinel