eslint path problems #1692
Comments
Use |
Thank you!
This works. |
If you don't want to add a custom task to your package scripts, the following setting will always run the locally installed eslint
|
Note that may help someone else: for me the approaches described by @acthp and @gurpreetatwal, which are aimed at using a project's local version of |
@stuartsan Just point let g:syntastic_javascript_eslint_exec = '/bin/ls' |
Ahh gtk, thanks @lcd047 ! |
I wrote a solution to use the local node_module script or fallback to the global installation, when not available: let g:syntastic_javascript_eslint_exe = '[ -f $(npm bin)/eslint ] && $(npm bin)/eslint || eslint' |
@kogakure Alternatively, write a wrapper script and point |
I have tried a couple of these examples for getting syntastic to use the local eslint but to no avail. The above:
Led to output like this:
Like @stuartsan, I've only been able to get eslint to work with syntastic if I have it installed globally, which is not ideal. |
@ezmiller Like @stuartsan, you can just point let g:syntastic_javascript_eslint_exec = '/bin/ls' That's because
|
@lcd047 I tried the
I also wanted to see if for some reason
And it worked. So I'm not sure what might be going wrong here. Thoughts? |
You also have to set |
@lcd047 thanks. Is this stuff in the docs somewhere? You are right node is also a mess. |
@lcd047 adding that line doesn't get things working unfortunately. The error output seems virtually identical:
|
@ezmiller Setting |
From my testing, this approach (setting |
hmm that's odd, what properties are you setting exactly? This solution was worked fine for me for as long as I used syntastic. (Using ALE these days) |
That basically comes from here as far as I can see.
leads to
Note: |
Interestingly enough I never had the
If you're having issues with the |
@gareth The recommended approach is the one in the first post above. It takes a time investment of ~2 minutes to understand and apply correctly. Most of the reminder of the thread is just people trying random other things they picked up elsewhere, hoping to avoid spending those ~2 minutes. shrug |
@lcd047 The approach in the first post seems to rely on Am I right that having a globally accessible install of Maybe if you've used npm a lot, and maybe if you know vimscript, and maybe if you wrote Syntastic then it only takes 2 minutes to understand and apply these concepts, but for someone who hasn't made a thousand commits to this project I did spend a couple of hours actually trying to work out the execution flow before posting here. I just didn't detail everything I tried in my message because, well, who wants to read an essay? It's a little offputting to try asking the author of a plugin for help and basically be told "You're not clever enough to use my plugin" |
@gareth Ah, so the problem is
It isn't strictly required, you can also write a wrapper script that handles all those executable-finding contortions, and point syntastic's The other solution if you don't want to install a global
Sorry if you read it that way. I suppose it was the result of my idle meditation on how everybody complains about syntastic not being able to handle all this crap automatically, or at least smoothly, while nobody ever questions why |
Thanks for the considered reply, that's a great summary of my options. Believe me, I also have a lot of opinions about the amount of crap that node forces on you 😉 But I think asking questions about large projects is even harder because of the weight of development behind those, and speaking up is pretty intimidating. But that's not a topic for this thread, which I have a solution for now 😄 |
Hey folks, just wanted to let you know that since npm v5 ships with npx you can use this in place of let g:syntastic_javascript_eslint_exe = 'npx standard' |
To summarize: you have two options to get vim-syntastic to use a locally installed version of ESLint. With ESLint installed globallyInstall ESLint globally. Syntastic won't use this version, it just checks it for a few things.
In your
Without global ESLint installedIn your
Set g:syntastic_javascript_eslint_exec to a wrapper scriptI'm not sure how this option would work but it's described above. |
@ericandrewlewis Please don't make authoritative statements until you understand exactly what's going on. Setting |
@lcd047 good point. If I open a file in a separate project ESLint is not run properly against it. If I change the working directory for that buffer and run Alternatively I gave a shot to making a wrapper script which does the trick. To set this up: In #!/bin/bash
if [ "$1" = "--version" ]
then
echo '1.0.0'
exit
fi
$(npm bin)/eslint $@ then in
|
@ericandrewlewis Most syntastic checkers would work with A simple-minded wrapper as above still won't work, unless you change Vim's idea of current directory with Also, you don't need |
Making syntastic support "in-project" eslint needs a few configurations. With 'yarn', it looks easier... for a bit. Ref: vim-syntastic/syntastic#1692
After trying several of the approaches in this issue, I settled on an implementation which uses executables in |
@kevinoid I has been a while since I wrote the registry code, and I'm not entirely convinced what you're doing makes sense in all possible situations (among other things, the registry is initialized only when some checkers are actually requested). But it's good to know it solves your problem. 😄 |
@lcd047 Thanks for taking a look at it. If you would like me to convince you (possibly by fixing cases I've overlooked in the process), I'm open to that. Probably only worth our time if there is a chance it could be merged. 😄 |
@kevinoid If your change requires the registry to be fully loaded for certain filetypes this slows down the first run of a checker, sometimes by a few seconds. So no, I'm afraid I won't merge it. 😄 Then again, I'm pretty sure I don't understand the problem you're trying to solve. In particular, I see no reason to do all the work after syntastic and the registry have been initialized, instead of doing it with a script ( |
@lcd047 I'm trying to have Syntastic use linter executables from |
Also, to clarify, the |
Like I said, I probably don't understand the problem you're trying to solve. So "clarify" might not be the right word for it.
That's one way to do it: a small Vim script in the base directory of the project, that sets the relevant syntastic variables. You could source that from an Another way to do it would be to write wrapper scripts for the relevant linters. Those scripts would determine the right executable to run, set the relevant parameters etc. dfepending on the current directory and the path to the file or directory being checked. There are also plugins that allow you to set variables based on project. And so on. |
I contribute to enough projects which I don't maintain that using per-project configuration is not workable for me. I could certainly write a wrapper script to call the appropriate checker executable. I could even write it in VimL and call it once when the JavaScript filetype is detected and remember the executable path, rather than on each check, and package it as a plugin so I can easily copy it to the places I need it... and end up with exactly what I have. 😄 |
The following worked for me:
|
That's only because you didn't read the thread above. Which, honestly, you should. It isn't like none of the people above haven't thought of that, you know. |
Sorry. Do you know if there's a way in Vim to set |
There is no such thing. |
I don't want to install ESLint globally. After parsing through this thread, the only solution that worked for me is from this blog post: http://www.spencer.sx/posts/eslint
Note that I was testing opening Vim with the project folder that contains the package.json file. After a while I realized the terminal I ran |
You can easily debug this with setting:
then write the file in the gvim You can also run test commands
In my case nvm turned out to be the culprit, despite it working fine for years. It ended up with the following settings:
I still don't understand why "gvim" read my ".bashrc" before, but now it doesn't. It happened after the system upgrade. |
As noted in another issue, global eslint will not run the eslint version installed in a project. The recommended way to run the correct version is via npm, like
npm run lint
, after creating a lint script directive inpackage.json
, like{'lint': 'eslint'}
.However, setting
javascript_eslint_exec
tonpm run lint
in syntastic results in syntastic not finding the executable. Setting it tonpm
andjavascript_eslint_args
torun lint --
results in command linewhich is wrong. It needs to be
The
args_before
call botches the order.We need better control of the command line to make it work.
The text was updated successfully, but these errors were encountered: