Skip to content
This repository has been archived by the owner on Jan 9, 2019. It is now read-only.

Is webhint a general purpose hinter/linter? #49

Closed
donaldpipowitch opened this issue Oct 26, 2018 · 4 comments
Closed

Is webhint a general purpose hinter/linter? #49

donaldpipowitch opened this issue Oct 26, 2018 · 4 comments
Labels
question Further information is requested

Comments

@donaldpipowitch
Copy link

Hi there,

this is issue is based on this Twitter conversation. First things first: Thank you for this project.

I'd like to know what is the exact scope of webhint? The website says "webhint is a linting tool that will help you with your site's accessibility, speed, security and more, by checking your code for best practices and common errors.". I'd like to know if it should be treated as a (pluggable?) general purpose hinter/linter?

Why do I ask?
Currently we use multiple linters. Every linter slightly differs in output/configurations/and so on. I'm looking for a tool which tries to generalize and abstract the common behavior. Ideally I would like to have a basic linting foundation which works similar to prettier: it is has some common rules/APIs and is pluggable for new languages.
I'd like to lint my CSS/HTML/JS/TS/etc. files with the same tools, especially when I have a linting rule which affects multiple languages (changing path, renaming things which correspond to each other and so on).
It would be nice if webhint could hook into existing language service (e.g. the on for TypeScript) to use them for analyzing the code and triggering refactors.

Is this in the scope of this project?

@alrra
Copy link

alrra commented Oct 26, 2018

Is this in the scope of this project?

Short answer is: yes.

I'd like to know if it should be treated as a (pluggable?) general purpose hinter/linter?

We designed webhint to be very modular/pluggable. Everything even in webhint is a separate module/package. External, more specific modules are not only supported, but they are basically the same as core modules, the only difference being the core ones live in the hint repository and are maintained by us.

We also tried to simplify the process of creating new modules such as new hints or parsers. So, today that can be done by running npm create hint or npm create parser, responding to some questions, and then a base for the new module/package will be created.

Currently we use multiple linters. Every linter slightly differs in output/configurations/and so on. I'm looking for a tool which tries to generalize and abstract the common behavior.

We don't want to reinvent the wheel, so that is exactly what we were thinking when we first created webhint.

Our thinking is: when we find tools that we as a community decide are very useful and do a great job at what they test, we will try to integrate them into webhint. We decide what should be the best default configurations for them, but also allow the user to pass different configurations, but in essence, we want webhint to abstract the setup/differences between those tools and just make them work without extra effort from the user.

We already do this with a few of them. E.g.: aXe (hint-axe), Snyk (hint-no-vulnerable-javascript-libraries), SSL Labs (hint-ssllabs), etc..

new languages.

For that we have the concept of parsers. We have a few, and we can add more, or the community can create more as they are needed.

linting rule which affects multiple languages (changing path, renaming things which correspond to each other and so on).

Since everything is modular, multiple parsers can be used and a new hint can be created that can check (relying on the parsers) for things in different types of files.


I hope that answers your questions. Let us know if you have more, or something isn't clear.

@donaldpipowitch
Copy link
Author

Hi @alrra ,

thank you for this indepth answer.

For that we have the concept of parsers.

Do the parsers have any kind of constraints? For example I'd like to use the complete TypeScript language service in a hint (to have access to getSuggestionDiagnostics). This is something which can't be done in TSLint for example (as far as I know).


Let us know if you have more,

What would be a good place to start adding something like a no-unused-vars rule based on TypeScripts getSuggestionDiagnostics? Add a "parser", figure out how to start the TypeScript language service, add a hint which requires and uses the language service... Does any existing parser creates a language service?

(By the way, some packages linked in https://webhint.io/docs/user-guide/concepts/parsers/#list-of-official-parsers only show a 404 page.)

Are there already existing discussions about a "auto-fix" feature? (Which would be quite useful for no-unused-vars.)

Some totally different topic: You said webhint is quite pluggable - how much actually? :) Could I write a "zero config" feature, which automatically loads custom hints (e.g. based on the dependencies I use and if they have a webhint property or something like this in their package.json? I once talked about a similar feature for TypeScript here which contains some examples: microsoft/TypeScript#15589).

Thank you!

@molant molant added the question Further information is requested label Oct 29, 2018
@molant
Copy link
Member

molant commented Oct 30, 2018

Do the parsers have any kind of constraints?

The only constraint will be how to access and shared the information. All the different parts of webhint communicate with each other via events. Parsers subscribe mostly to fetch::end::FILETYPE where FILETYPE can be json, css, javascript, etc. Then they do whatever they want and expose the information via other events.

For your case you will use the local connector, subscribe to fetch::end::ts and when you receive it emit whatever event you want with whatever payload is useful. In the case of JavaScript, we are sending the AST for example but it can be virtually any object.

By the way, some packages linked in https://webhint.io/docs/user-guide/concepts/parsers/#list-of-official-parsers only show a 404 page.

Nice catch, while we update it you can replace packages with package in the url to access the good one.

Are there already existing discussions about a "auto-fix" feature?

That's something we want to do but haven't thought yet on how to do it. Not all the rules will support autofix but it's definitely something we eventually want to explore more seriously. Feel free to open an issue in this same repo if you have some ideas about it!

You said webhint is quite pluggable - how much actually? :)

A lot, everything has its own package: hints, parsers, connectors...

Could I write a "zero config" feature, which automatically loads custom hints (e.g. based on the dependencies I use and if they have a webhint property or something like this in their package.json?

Yes you can. You will have to write the code to parser the package.json, have the logic to know which hints and parsers to load based on the dependencies and then pass that configuration to the engine. I recommend you to read the architecture section to have a better idea of how things communicate to each other. The example there is for the CLI but hopefully that will give you a better idea (and if not let us know so we can improve it).

What you are proposing is really interesting. Maybe open a new issue with more details, scenarios that could fix, how that would work, etc.?

Thanks!

@donaldpipowitch
Copy link
Author

Thank you very much for the detailed answer. I'll read the architecture section and anything additional I can find and I hope I find time to play around with the APIs, before I create a more detailed issue. Thank you so far!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants