Open bobrocke opened 9 years ago
Here's how it's gonna look like
We are gonna have a config in every linter that says Use Global Linter
.
It'll be off by default, but when we try to lint and we get an EONET error, we're gonna display the warning and turn that option on ourselves to make sure the linter keeps on working for the user.
Do you really think it's a good idea to attempt to package every linter for every OS? Linters are for developers, and developers should be able to install the software they need.
@AsaAyers At least we can embed the node ones. It's just that I see tons of comments/posts around the internet saying they couldn't get the linter to work. We want to make it easier for them to use it.
Then I think we need some better messaging around missing linters.
It's valid for some linter plugins to package their own linters. linter-coffeelint comes with a default version, but will pick up a different version if you've configured your project correctly.
The fact that this is in Meta indicates the target audience is to get all of the linter plugins to package their linters, which I think is a bad idea.
Sometimes it's a missing linter and sometimes it's figuring out the path to the linter that is installed. With a Node, Unix and Windows executable, would that not cover 90% of the cases?
It does put the burden of updating the executable on the linter creator, but at least he/she is intimately aware of the "right" way to get things working. Other wise the user has to work it out for all the linters used.
Is there a better way to reduce the confusion?
he/she is intimately aware of the "right" way to get things working
This statement is wrong. I run Ubuntu Linux. I don't know the right way to handle Windows, Mac, or other flavors of Linux. And again, our target audience is Developers, not my Grandma. They can handle some basic instructions to go install some additional software, or guidance in how to troubleshoot the problem.
I see your point.
How would you suggest solving the complications and problems inspiring this whole thread?
Do you have some specific examples? I think the general approach is "better messaging", but that's obviously too broad.
Well, one example is not having the executable installed.
Another is not having the executable installed in the right place.
And another is not having the linter module pointed at the right linter executable.
The linter plugin I wrote I included the linter executable itself as dependency with its path set as a default that could be changed. It makes sense to me to have it like that, it is a dependency of the plugin working after all and there's no harm in having the path to the executable as an option. For the node based linters I would say it's definitely worth it, may be a little more effort for the non node ones though e.g. php lint
For node based linters I think this isn't a bad idea, but for anything else? I think this is a terrible idea. Several linters this would be impossible for (linter-php
, linter-ruby
, ...), and the rest it still is a terrible idea as installing them properly often involves configuration and dependencies.
From this morning's Slack linter channel:
hi, I've just installed linter and linter-pep8 but it doesn't show the errors
dukebody [5:10 AM]
I mean I type something I know is an error but it doesn't whine, says everything is correct
dukebody [5:11 AM]
how do I know it's calling the correct linter?
The problem is real, the solution may not be easy.
So linter plugins need to be noisy when they can't find their linter. linter-coffeelint
will generate an artificial error on line 1 of every file if you're using an incompatible version of CoffeeLint.
Maybe there needs to be a way of having it in the status bar at the bottom. Something like a red or green icon next to the 'no issues' text that indicates whether you've got things set right. It would be up to each linter plugin to support this. So lint issues would be separate from configuration issues.
I like the way linter-coffeelint
handles that too, would be easy to port that to using a new configuration flag.
What is there to configure? IMO every linter should produce an error on line 1 if they were unable to run.
Missing executable, missing config file anything like that..
I agree with you, but i do feel there are steps we can take to give people a bit more of a configuration guide.
Instead of requiring the user to separately install the linter executable and the linter package, include the executable in the package and use that in place of the (possibly) system level installed linter executable.