WebHint The Website Scanner To Identify Web Site's Your Weaknesses
Last Updated -
At the September 2017 Microsoft Edge Web Summit The team announced a new tool, WebHint. This is a website scanning tool to identify issues with your web site, most you probably don't know about.
WebHint is a customizable linting tool that scans a URL, running a set of rules to identify weaknesses and report how well the page implements many web best practices.
Some of the areas it covers out of the box include:
- accessibility
- security
- performance
- bundling
- transpiling
The tool is an open source project, backed by the JS Foundation project. This means you can clone or fork the project and make it your own.
An overriding principle the Microsoft Edge team wanted WebHint to be was unopinionated. The open nature of the WebHint make it a tool that anyone can customize and share with the community.
WebHint is based on a series of external modules:
- Rules
- Configurations
- Connectors
- Formatters
- Parsers
You can read more about contributing to the community project here.
WebHint itself is more of a task runner than a scanning tool. That's because it runs a series of rules defined by your configuration. There is a default configuration and rule set, but you can customize the rules it executes and create your own.
Installing WebHint
The tool is a node module, with a command line interface (CLI). This means you can run WebHint as part of your development workflow.
You can install WebHint locally like any node module. It does require nodejs v8.9.2 or later. I recommend installing it as a global node module:
>npm install -g --engine-strict hint
WebHint uses a .hintrc file, which is its source configuration. The tool searches the current folder and then in the user�s home directory for a .hintrc file. You can generate a default configuration file by executing hint with the --init switch:
>hint --init
This initiates a command line wizard, asking you a series of questions to build a custom configuration. Because I focus on Progressive Web Apps I chose a predefined progressive web app configuration.
{ "extends": [ "progressive-web-apps" ] } > hint https://love2dev.com/blog/
WebHint Configurations
Creating a custom configuration file could be daunting task, which is why there are example configurations you can use or reference to create your own. A WebHint configuration is just a JSON document. The Progressive Web App configuration looks like:
{ "connector": { "name": "jsdom", "options": { "waitFor": 5000 } }, "formatters": [ "summary" ], "parsers": [ "manifest" ], "rules": { "apple-touch-icons": "error", "manifest-app-name": "error", "manifest-exists": "error", "manifest-file-extension": "error", "manifest-is-valid": "error" }, "rulesTimeout": 120000 } WebHint Connectors
Connectors are how WebHint loads the target URL and executes tests. What this really means is how are the pages loaded, in a browser or some sort of emulator. The default connectors are:
- jsdom
- chrome
- edge
You can define the connector in your configuration file:
"connector": { "name": "connectorName", "options": {} } It is possible to create a new connector. For example you might want to execute the URL using Google's new Puppeteer.
WebHint Formatters
A formatter takes the test results and transforms them into a target data format, JSON, Excel or XML for example. Like other WebHint aspects you can create your own formatters.
I am partial to JSON, but if you are providing client reports Excel might be your preferred tool. Think about it this way, you can pre-format the data into a custom report. Plus you can automate the test process for a repeatable experience.
WebHint Parsers
Parsers do deep evalaution and execute events. You can build rules on top of parser events to generate report data.
Currently WebHint includes JavaScript, TypeScript, Web Manifest and WebPack parsers.
Parsers can be used like linting tools to ensure source files follow their syntax rules or in the case of a web manifest file includes require properties and all values are valid.
You can also create your own parsers. I can see HTML and CSS parses being dcreated in the future.
WebHint Rules
Rules are tests executed against a URL. The tool comes with nice list of default rules. For example sites upgrading to a progressive web app need a valid web manifest file.
This is where WebHint expresses its power. That's because you can configure which rules are executed against a web page and create your own.
Extensibility and Comparision to Chrome Lighthouse
I like the fact I can create my own rules and have the option to contribute them to the community or create custom reports for my own use. This extensibility is probably WebHint's greatest power.
Other tools are not as extensible, like Lighthouse. I love Chrome's Lighthouse, but it is limited to rules the Chrome team releases. Both are effectively task runners, but WebHint's openess makes it more flexible and customizable.
Summary
WebHint is a fantastic tool provided by the Microsoft Edge team. It recently celebrated its official version 1.0 release. If you are a web developer I encourage your to install it and started testing your web sites.
Because WebHint is a node command line tool you can add it to your continuous build and test scripts. You can also automatically run it over multiple pages in a single test run. This means you can continually check for common mistakes you may introduce as you update content or your build scripts. You can also automate reports for your own internal consumption or for your clients.
WebHint is completely extensible and allows custom configurations. You can benefit from community contributions, add your own contributions and create custom internal tests.
Recently Google announced a similar online tool, Web.Dev, which uses a hosted version of Lighthouse.