open-index/open-npm huggingface dataset:
npm package: @hint/hint-no-broken-links
Description: Verify that all links and resources the page uses are available online.
Latest version: 4.2.27

# No broken links (`broken-links`)

This hint checks and reports if any links in your page are broken.
This includes anchor tag `href` value, image `src` value,
script `src` value, video `src` value etc.

## Why is this important?

Broken links gives your user a bad user experience.

## What does the hint check?

This hint gets executed on all the below elements.

1. `img` - checks `src` and `srcset` attribute values
2. `script`- checks for `src` attribute value
3. `anchor` - checks for `href` attribute value
4. `audio` - checks for `src` attribute value
5. `video` - checks for `src` and `poster` attribute values
6. `source` - checks for `src` attribute value
7. `object` - checks for `data` value attribute value
8. `link` - checks for `src` attribute value
9. `track` - checks for `src` attribute value

If the response status of the resource link is either `404` or `410`
or `500` or `503`, the URL will be flagged as a broken link.

## Can the hint be configured?

You can change the HTTP method to make the requests (`HEAD`, `GET`,
etc.). To do so, you need to configure the property `method` in your
configuration [`.hintrc`][hintrc] file:

```json
{
    "connector": {...},
    "formatters": [...],
    "hints": {
        "no-broken-links": ["error", {
            "method": "GET|HEAD"
        }],
        ...
    },
    ...
}
```

By default, this hint will use the HTTP `GET` method to request
the URLs.

### Examples that **trigger** the hint

#### Absolute URL

`<a href="https://example.com/404">Register</a>`

`<img src="https://example.com/image.png" alt="logo">`

#### Relative URL

`<a href="/page-does-not-exist">Profile</a>`

`<img src="/image_does_not_exist.png" alt="logo">`

### Examples that **pass** the hint

URLs which return 200 OK will pass this hint.

URLs requested via `<link rel="dns-prefetch">` or `<link rel="preconnect">`
[resource hints](https://www.w3.org/TR/resource-hints/#resource-hints) will
pass this hint if the request succeeds, regardless of status code.

## How to use this hint?

This package is installed automatically by webhint:

```bash
npm install hint --save-dev
```

To use it, activate it via the [`.hintrc`][hintrc] configuration file:

```json
{
    "connector": {...},
    "formatters": [...],
    "hints": {
        "no-broken-links": "error",
        ...
    },
    "parsers": [...],
    ...
}
```

**Note**: The recommended way of running webhint is as a `devDependency` of
your project.

<!-- Link labels: -->

[hintrc]: https://webhint.io/docs/user-guide/configuring-webhint/summary/
npm package: @hint/hint-no-inline-styles
Description: Invalidate the use of CSS inline styles in HTML
Latest version: 1.0.19

# No Inline CSS Styles

This hint checks if the HTML is using inline CSS styles.

## Why is this important?

The use of inline CSS styles prevent the reuse of the styles anywhere else.
The html markup of the page becomes hard to read for the naked eye. The inline
CSS styles are hard to maintain and does not provide consistency since they are
not stored in a single place. The inline styles are repeated downloaded by the
client on every request since it does not provide you with browser cache
advantage. Inline styles take precedence of external stylesheets, this could
accidentally override styles that you did not intend to overwrite.

## What does the hint check?

This hint checks if the HTML is using inline CSS styles.

Examples of inline CSS styles

`<div style="color: blue;"></div>`

`<style></style>`

It checks that no element has the attribute `style`.
It also checks that no internal styles `<style>` is used.

### Examples that **trigger** the hint

The hint will trigger if any element have the attribute `style`

```html
<div style="color: blue;"></div>
```

The hint will trigger if you use internal styles, this is disabled by default

```html
<style>
    div {
        color: blue;
    }
</style>
```

### Examples that **pass** the hint

No inline style in the element

```html
<!DOCTYPE html>
<html lang="en">
    <head>
        ...
    </head>
    <body>
        ...
        <div>Hi styles</div>
    </body>
</html>
```

## Can the hint be configured?

`requireNoStyleElement` can be set to `true` to disallow and require the use of
no `style` tag.

In the [`.hintrc`][hintrc] file:

```json
{
    "connector": {...},
    "formatters": [...],
    "hints": {
        "no-inline-styles": [ "warning", {
            "requireNoStyleElement": true
        }],
        ...
    },
    ...
}
```

## How to use this hint?

Install this hint with:

```bash
npm install @hint/hint-no-inline-styles --save-dev
```

To use it, activate it via the [`.hintrc`][hintrc] configuration file:

```json
{
    "connector": {...},
    "formatters": [...],
    "parsers": [...],
    "hints": {
        "no-inline-styles": "error",
        ...
    },
    ...
}
```

## Further Reading

- [Why CSS inline styles are considered harmful for accessibility][why-css-inline-styles-are-considered-harmful-accessibility]

<!-- Link labels: -->

[hintrc]: https://webhint.io/docs/user-guide/configuring-webhint/summary/
[why-css-inline-styles-are-considered-harmful-accessibility]: https://www.nomensa.com/blog/2011/css-inline-styles-and-why-they-are-considered-harmful-accessibility
npm package: @hint/hint-no-vulnerable-javascript-libraries
Description: hint that that checks using Snyk for vulnerable JavaScript libraries
Latest version: 2.12.22

# No vulnerable libraries (`no-vulnerable-javascript-libraries`)

`no-vulnerable-javascript-libraries` checks for known vulnerabilities
within client-side JavaScript libraries and frameworks detected on a
web site.

`webhint` uses Snyk’s [Vulnerability DB][snykdb] to lookup known
vulnerabilities.

## Why is this important?

Making sure your website dependencies are free of known
vulnerabilities is important in preventing malicious attacks such as
[cross-site scripting][XSS] attacks that can be used to compromise web
site information.

## What does the hint check?

This hint uses Snyk’s [Vulnerability DB][snykdb] and
[js-library-detector][js-library-detector] to check if the
website is running a vulnerable version of a client-side JavaScript
library or framework.

The vulnerability database is updated automatically from [Snyk][snykdb]
if the cached content is older than 24h.

## Can the hint be configured?

You can configure the minimum severity to report in the
[`.hintrc`][hintrc] file:

```json
{
    "connector": {...},
    "formatters": [...],
    "hints": {
        "no-vulnerable-javascript-libraries": ["error", {
            "severity": "low|medium|high"
        }],
        ...
    },
    ...
}
```

The `severity` possible values are: `low` (default), `medium`,
and `high`.

If you configure this hint to `high`, and `webhint` only finds
`low` or `medium` vulnerabilities, no issues will be raised.

## How to use this hint?

This package is installed automatically by webhint:

```bash
npm install hint --save-dev
```

To use it, activate it via the [`.hintrc`][hintrc] configuration file:

```json
{
    "connector": {...},
    "formatters": [...],
    "hints": {
        "no-vulnerable-javascript-libraries": "error",
        ...
    },
    "parsers": [...],
    ...
}
```

**Note**: The recommended way of running webhint is as a `devDependency` of
your project.

## Further Reading

* [77% of sites use at least a vulnerable JavaScript library][77 vulnerable]
* [Thou shalt not depend on me: analysing the use of outdated JavaScript
   libraries on the web][not depend on me]

<!-- Link labels: -->

[77 vulnerable]: https://snyk.io/blog/77-percent-of-sites-use-vulnerable-js-libraries/
[js-library-detector]: https://npmjs.com/package/js-library-detector
[not depend on me]: https://blog.acolyer.org/2017/03/07/thou-shalt-not-depend-on-me-analysing-the-use-of-outdated-javascript-libraries-on-the-web/
[snykdb]: https://snyk.io/vuln/
[hintrc]: https://webhint.io/docs/user-guide/configuring-webhint/summary/
[XSS]: https://developer.mozilla.org/en-US/docs/Glossary/Cross-site_scripting
npm package: @hint/hint-scoped-svg-styles
Description: Scoped SVG Styles checks if SVG styles affect any other elements outside the svg.
Latest version: 1.3.28

# scoped-svg-styles (`@hint/hint-scoped-svg-styles`)

Scoped SVG Styles checks if SVG styles affect any other elements outside the svg.

## Why is this important?

As `<style>` inside inline `<svg>` elements are not scoped to `<svg>`,
these can affect elements of dom outside the SVG. So it is important to
detect if any style (CSS rule or selector) inside `<svg>` selects
elements outside it.

## What does the hint check?

This hint checks if styles inside SVG affect any other elements outside
it. If any such style is found, it reports the CSS rule that is
affecting and html elements that are being affected.

### Examples that **trigger** the hint

Any style rule inside SVG that selects elements outside it will trigger
the hint.

Example:

```html
<html>
    <body>
        <h1 class="my-style">Heading</h1>

        <svg>
            <style>
                .my-style {
                    opacity: 0.5;
                }
            </style>
            <text class="my-style">SVG text</text>
        </svg>
    </body>
</html>
```

### Examples that **pass** the hint

If in document, all styles inside SVGs are scoped to SVG only and are
not affecting any element outside it, hint will pass.

Example:

```html
<html>
    <body>
        <h1 class="html-style">Heading</h1>

        <svg>
            <style>
                .svg-style {
                    opacity: 0.5;
                }
            </style>
            <text class="svg-style">SVG text</text>
        </svg>
    </body>
</html>
```

## Can the hint be configured?

This hint can be configured to limit the number of HTML elements reported
per CSS rule. If the hint finds an affecting CSS rule, it generates one report
related to that rule and an additional report for each HTML element
matched by that rule.

If the `maxReportsPerCSSRule` option is passed to this hint, it will limit the
number of reports related to affected elements, but reports related to the
CSS rule will still be there.

### How to pass `maxReportsPerCSSRule` option to hint

`maxReportsPerCSSRule` can be added in `.hintrc` as given below:

```json
    ...
    "hints": {
            "scoped-svg-styles": [
                    "warning", {
                        "maxReportsPerCSSRule": 5
                    }
            ]
        },
    ...
```

In above example, for every affecting rule, there can be a maximum of six
reports. One report related to the CSS rule itself and a maximum of
five reports related to affected elements.

## How to use this hint?

This package is installed automatically by webhint:

```bash
npm install hint --save-dev
```

To use it, activate it via the [`.hintrc`][hintrc] configuration file:

```json
{
    "connector": {...},
    "formatters": [...],
    "parsers": [...],
    "hints": {
        "scoped-svg-styles": "error"
    },
    ...
}
```

**Note**: The recommended way of running webhint is as a `devDependency` of
your project.

<!-- Link labels: -->

[hintrc]: https://webhint.io/docs/user-guide/configuring-webhint/summary/
npm package: @hint/hint-stylesheet-limits
Description: Checks if CSS exceeds known stylesheet limits
Latest version: 3.3.27

# Avoid CSS limits (`stylesheet-limits`)

`stylesheet-limits` checks if CSS exceeds known stylesheet limits.

## Why is this important?

Internet Explorer 9 and below have limits on the number of CSS
stylesheets, imports, and rules which are relatively small compared
to modern browsers. Once these limits are exceeded, additional
stylesheets, imports, and rules are ignored. For more details see
[_"Stylesheet limits in Internet Explorer"_][stylesheet limits].

Similar behavior existed in older versions of other browsers, such
as [Chrome][chrome limits]. Newer browsers have much higher limits
such as 65535 rules in [Internet Explorer 10+ and Edge][stylesheet
limits].

Even in modern browsers large numbers of CSS selectors can negatively
impact performance. You [can customize](#can-the-hint-be-configured)
this hint and set appropriate limits for your project or team.

## What does the hint check?

When targeting versions of Internet Explorer 9 and below, this hint
checks if one of the following [limits][stylesheet limits] is exceeded:

* 4095 rules
* 31 stylesheets
* 4 levels of imports

### Examples that **trigger** the hint

* A page targeting Internet Explorer 9 containing 4096 or more CSS
  rules.

### Examples that **pass** the hint

* A page targeting Internet Explorer 9 with fewer than 4096 CSS rules.
* A page not targeting Internet Explorer 9 or below regardless of the
  number of CSS rules.

## Can the hint be configured?

You can overwrite the defaults by specifying custom values for the
number of CSS rules to allow. Note that if the custom values are above
the default values, the default values will still be used.

In the [`.hintrc`][hintrc] file:

```json
{
    "connector": {...},
    "formatters": [...],
    "hints": {
        "stylesheet-limit": ["error", {
            "maxRules": 1000,
            "maxSheets": 10,
            "maxImports": 2
        }],
        ...
    },
    ...
}
```

## How to use this hint?

This package is installed automatically by webhint:

```bash
npm install hint --save-dev
```

To use it, activate it via the [`.hintrc`][hintrc] configuration file:

```json
{
    "connector": {...},
    "formatters": [...],
    "hints": {
        "stylesheet-limits": "error",
        ...
    },
    "parsers": [...],
    ...
}
```

**Note**: The recommended way of running webhint is as a `devDependency` of
your project.

<!-- Link labels: -->

[chrome limits]: https://stackoverflow.com/questions/20828995/how-long-can-a-css-selector-be]
[hintrc]: https://webhint.io/docs/user-guide/configuring-webhint/summary/
[stylesheet limits]: https://blogs.msdn.microsoft.com/ieinternals/2011/05/14/stylesheet-limits-in-internet-explorer/
npm package: @hint/hint-typescript-config
Description: hint that that checks if the TypeScript configuration is valid.
Latest version: 2.5.16

# TypeScript configuration hints set (`typescript-config`)

`typescript-config` contains hints to check if your TypeScript
configuration has the most recommended configuration.

## Why is this important?

If you are building an app or a website using TypeScript, you
need to be sure that your configuration is the best for your needs.

## Hints

* [typescript-config/import-helpers][import-helpers]
* [typescript-config/is-valid][is-valid]
* [typescript-config/no-comments][no-comments]
* [typescript-config/strict][strict]
* [typescript-config/target][target]

## How to use these hints?

This package is installed automatically by webhint:

```bash
npm install hint --save-dev
```

To use it, activate it via the [`.hintrc`][hintrc] configuration file:

```json
{
    "connector": {...},
    "formatters": [...],
    "hints": {
        "typescript-config/is-valid": "error",
        "typescript-config/no-comment": "error",
        "typescript-config/target": "error",
        ...
    },
    "parsers": [...],
    ...
}
```

**Note**: The recommended way of running webhint is as a `devDependency` of
your project.

## Further Reading

* [TypeScript Documentation][typescript docs]

<!-- Link labels: -->

[import-helpers]: https://github.com/webhintio/hint/blob/HEAD/packages/hint-typescript-config/docs/import-helpers.md
[is-valid]: https://github.com/webhintio/hint/blob/HEAD/packages/hint-typescript-config/docs/is-valid.md
[no-comments]: https://github.com/webhintio/hint/blob/HEAD/packages/hint-typescript-config/docs/no-comments.md
[hintrc]: https://webhint.io/docs/user-guide/configuring-webhint/summary/
[strict]: https://github.com/webhintio/hint/blob/HEAD/packages/hint-typescript-config/docs/strict.md
[target]: https://github.com/webhintio/hint/blob/HEAD/packages/hint-typescript-config/docs/target.md
[typescript docs]: https://www.typescriptlang.org/docs/home.html
npm package: @hint/hint-webpack-config
Description: hint thats to check the webpack configuration.
Latest version: 2.4.30

# webpack configuration hints set (`webpack-config`)

`webpack-config` contains set of hints to check if your webpack
configuration file (`webpack.config.js`) has the most recommended
configuration.

## Why is this important?

If you are building an app or a website using webpack, you need to
be sure that your configuration is the best for your needs.

## Hints

* [webpack-config/config-exists][config-exists]
* [webpack-config/is-installed][is-installed]
* [webpack-config/is-valid][is-valid]
* [webpack-config/module-esnext-typescript][module-esnext-typescript]
* [webpack-config/modules-false-babel][modules-false-babel]
* [webpack-config/no-devtool-in-prod][no-devtool-in-prod]

## How to use these hints?

This package is installed automatically by webhint:

```bash
npm install hint --save-dev
```

To use it, activate it via the [`.hintrc`][hintrc] configuration file:

```json
{
    "connector": {...},
    "formatters": [...],
    "hints": {
        "webpack-config/config-exists": "error",
        "webpack-config/is-installed": "error",
        "webpack-config/is-valid": "error",
        "webpack-config/module-esnext-typescript": "error",
        "webpack-config/no-devtool-in-prod": "error",
        ...
    },
    "parsers": ["webpack-config", "typescript-config"],
    ...
}
```

**Note**: The recommended way of running webhint is as a `devDependency` of
your project.

## Further Reading

* [webpack Documentation][webpack docs]

<!-- Link labels: -->

[config-exists]: https://github.com/webhintio/hint/blob/HEAD/packages/hint-webpack-config/docs/config-exists.md
[is-installed]: https://github.com/webhintio/hint/blob/HEAD/packages/hint-webpack-config/docs/is-installed.md
[is-valid]: https://github.com/webhintio/hint/blob/HEAD/packages/hint-webpack-config/docs/is-valid.md
[module-esnext-typescript]: https://github.com/webhintio/hint/blob/HEAD/packages/hint-webpack-config/docs/module-esnext-typescript.md
[modules-false-babel]: https://github.com/webhintio/hint/blob/HEAD/packages/hint-webpack-config/docs/modules-false-babel.md
[no-devtool-in-prod]: https://github.com/webhintio/hint/blob/HEAD/packages/hint-webpack-config/docs/no-devtool-in-prod.md
[hintrc]: https://webhint.io/docs/user-guide/configuring-webhint/summary/
[webpack docs]: https://webpack.js.org/concepts/
npm package: @hint/parser-babel-config
Description: webhint parser to analyze babel config
Latest version: 2.1.43

# Babel config (`@hint/parser-babel-config`)

The `babel-config` parser allows the user to analyze the Babel
configuration in their projects.

This package is installed automatically by webhint:

```bash
npm install hint --save-dev
```

To use it, activate it via the [`.hintrc`][hintrc] configuration file:

And then activate it via the [`.hintrc`][hintrc] configuration file:

```json
{
    "connector": {...},
    "formatters": [...],
    "hints": {
        ...
    },
    "parsers": ["babel-config"],
    ...
}
```

This parser detects if a `.babelrc` configuration file is present,
or if the Babel configuration is specified in `package.json`, and
validates the Babel configuration against the schema.

**Note**: The recommended way of running webhint is as a `devDependency` of
your project.

## Events emitted

This `parser` emits the following events:

* `parse::start::babel-config`, of type `BabelConfigParseStart`
  which contains the following information:

  * `resource`: the resource we are going to parse.

* `parse::end::babel-config`, of type `BabelConfigParse`
  which contains the following information:

  * `resource`: the parsed resource.
  * `config`: an object with a valid configuration.

* `parse::error::babel-config::json`, of type `BabelConfigInvalidJSON`
  which contains the following information:

  * `resource`: the parsed resource.
  * `error`: the error emited parsing the configuration file.

* `parse::error::babel-config::circular`, of type `BabelConfigInvalidJSON`
  which contains the following information:

  * `resource`: the parsed resource.
  * `error`: the error emited parsing the configuration file.

* `parse::error::babel-config::extends`, of type `BabelConfigInvalidJSON`
  which contains the following information:

  * `resource`: the parsed resource.
  * `error`: the error emited parsing the configuration file.

* `parse::error::babel-config::schema`, of type `BabelConfigInvalidSchema`
  which contains the following information:

  * `resource`: the parsed resource.
  * `errors`: all the errors that the schama validator returns.

## Types

If you need to import any type or enum defined in this parser,
you need to import them as follows:

```ts
import { TypeOrEnumYouWantToUse } from '@hint/parser-babel-config';
```

<!-- Link labels: -->

[hintrc]: https://webhint.io/docs/user-guide/configuring-webhint/summary/
npm package: @hint/parser-css
Description: webhint parser needed to analyze CSS files
Latest version: 3.0.39

# CSS (`@hint/parser-css`)

The `CSS` parser is built on top of [PostCSS][postcss] so hints can
analyze `CSS` files.

This package is installed automatically by webhint:

```bash
npm install hint --save-dev
```

To use it, activate it via the [`.hintrc`][hintrc] configuration file:

```json
{
    "connector": {...},
    "formatters": [...],
    "hints": {
        ...
    },
    "parsers": ["css"],
    ...
}
```

**Note**: The recommended way of running webhint is as a `devDependency` of
your project.

## Events emitted

This `parser` emits the following events:

* `parse::start::css` of type `Event` which contains the following information:

  * `resource`: the resource we are going to parse.

* `parse::end::css` of type `StyleParse` which has the following information:

  * `ast`: a PostCSS `Root` object containing the AST.
    See the [PostCSS `walk*` APIs][postcss-walk] for help navigating
    the AST.
  * `code`: a string containing the raw stylesheet source code.
  * `element`: an `HTMLElement` reference if the source was inline
    in HTML; `null` otherwise.
  * `resource`: the parsed resource. If the CSS is in a `style tag`
    and not a file, the value will refer to the HTML document containing
    the stylesheet.

<!-- Link labels: -->

[hintrc]: https://webhint.io/docs/user-guide/configuring-webhint/summary/
[postcss]: https://postcss.org/
[postcss-walk]: https://api.postcss.org/Container.html#walk
npm package: @hint/parser-html
Description: webhint parser needed to analyze HTML files
Latest version: 3.1.4

# HTML (`@hint/parser-html`)

The `HTML` parser is built on top of [`jsdom`][jsdom] so hints can
analyze `HTML` files.

Note: This parser is currently only needed if using the `local`
[connector][connectors]. Other connectors provide their own DOM to
generate events instead.

This package is installed automatically by webhint:

```bash
npm install hint --save-dev
```

To use it, activate it via the [`.hintrc`][hintrc] configuration file:

```json
{
    "connector": {...},
    "formatters": [...],
    "hints": {
        ...
    },
    "parsers": ["html"],
    ...
}
```

**Note**: The recommended way of running webhint is as a `devDependency` of
your project.

## Events emitted

This `parser` emits the event `parse::end::html` of type `HTMLParse`
which has the following information:

* `document`: an `HTMLDocument` object containing the
  parsed document.
* `html`: a string containing the raw HTML source code.
* `resource`: the parsed resource.

And the event `parse::start::html` of type `Event` which has the
following information:

* `resource`: the resource that is going to be parsed.

<!-- Link labels: -->

[connectors]: https://webhint.io/docs/user-guide/concepts/connectors/
[events]: https://webhint.io/docs/contributor-guide/getting-started/events/
[hintrc]: https://webhint.io/docs/user-guide/configuring-webhint/summary/
[jsdom]: https://github.com/jsdom/jsdom
npm package: @hint/parser-javascript
Description: webhint parser needed to analyze JavaScript files
Latest version: 3.1.25

# JavaScript (`@hint/parser-javascript`)

The `javascript` parser allows hints to analyze `JavaScript` files.

This package is installed automatically by webhint:

```bash
npm install hint --save-dev
```

To use it, activate it via the [`.hintrc`][hintrc] configuration file:

```json
{
    "connector": {...},
    "formatters": [...],
    "hints": {
        ...
    },
    "parsers": ["javascript"],
    ...
}
```

**Note**: The recommended way of running webhint is as a `devDependency` of
your project.

## Events emitted

This `parser` emits the following events:

* `parse::start::javascript` of type `Event` which contains the following
  information:

  * `resource`: the resource we are going to parse.

* `parse::end::javascript`, of type `ScriptParse` which contains the following
  information:

  * `ast`: an `ESTree` AST generated from the script.
  * `element`: an `HTMLElement` reference if the source was inline
    in HTML; `null` otherwise.
  * `resource`: the parsed resource. If the JavaScript is in
    a `script tag` and not a file, the value will refer to the
    HTML document containing the script.
  * `sourceCode`: the raw source code that was parsed.
  * `tokens`: a list of tokens generated from the source code.
  * `walk`: helper methods for walking the AST.

<!-- Link labels: -->

[hintrc]: https://webhint.io/docs/user-guide/configuring-webhint/summary/
npm package: @hint/parser-jsx
Description: webhint parser needed to analyze HTML elements in JSX
Latest version: 1.1.6

# JSX (`@hint/parser-jsx`)

The `jsx` parser allows hints to analyze HTML elements from `JSX` files.
It operates on ASTs received via `parse::end::javascript` events and
emits the same events as `@hint/parser-html`. This ensures existing hints
targeting `HTML` files will work without modification.

This package is installed automatically by webhint:

```bash
npm install hint --save-dev
```

To use it, activate it via the [`.hintrc`][hintrc] configuration file:

```json
{
    "connector": {...},
    "formatters": [...],
    "hints": {
        ...
    },
    "parsers": ["javascript", "jsx"],
    ...
}
```

**Note**: The recommended way of running webhint is as a `devDependency` of
your project.

## Events emitted

This `parser` emits the event `parse::end::html` of type `HTMLParse`
which has the following information:

* `document`: an `HTMLDocument` object containing the
  parsed document.
* `html`: a string containing the generated HTML source code.
* `resource`: the parsed resource.

And the event `parse::start::html` of type `Event` which has the
following information:

* `resource`: the resource that is going to be parsed

<!-- Link labels: -->

[hintrc]: https://webhint.io/docs/user-guide/configuring-webhint/summary/
npm package: @hint/parser-less
Description: webhint parser needed to analyze LESS files
Latest version: 1.0.31

# LESS (`@hint/parser-less`)

The `LESS` parser is built on top of [PostCSS][postcss] and
[postcss-less] so hints can analyze `LESS` files. It emits the same
events as `@hint/parser-css` so existing hints targeting `CSS` files
will work without modification.

This package is installed automatically by webhint:

```bash
npm install hint --save-dev
```

To use it, activate it via the [`.hintrc`][hintrc] configuration file:

```json
{
    "connector": {...},
    "formatters": [...],
    "hints": {
        ...
    },
    "parsers": ["less"],
    ...
}
```

**Note**: The recommended way of running webhint is as a `devDependency` of
your project.

## Events emitted

This `parser` emits the following events:

* `parse::start::css` of type `Event` which contains the following information:

  * `resource`: the resource we are going to parse.

* `parse::end::css` of type `StyleParse` which has the following information:

  * `ast`: a PostCSS `Root` object containing the AST.
    See the [PostCSS `walk*` APIs][postcss-walk] for help navigating
    the AST.
  * `code`: a string containing the raw stylesheet source code.
  * `element`: an `HTMLElement` reference if the source was inline
    in HTML; `null` otherwise.
  * `resource`: the parsed resource. If the CSS is in a `style tag`
    and not a file, the value will refer to the HTML document containing
    the stylesheet.

## Limitations

This parser is not fault-tolerant (unlike `@hint/parser-css`) so only
well-formed files will be parsed.

<!-- Link labels: -->

[hintrc]: https://webhint.io/docs/user-guide/configuring-webhint/summary/
[postcss]: https://postcss.org/
[postcss-less]: https://github.com/shellscape/postcss-less
[postcss-walk]: https://api.postcss.org/Container.html#walk
npm package: @hint/parser-manifest
Description: webhint parser for web app manifest files
Latest version: 2.3.20

# Manifest (`@hint/parser-manifest`)

The `manifest` parser detects if a [web app manifest file][manifest] was
specified, and if so, it will try to fetch it, parse and check if its
content is valid.

This package is installed automatically by webhint:

```bash
npm install hint --save-dev
```

To use it, activate it via the [`.hintrc`][hintrc] configuration file:

```json
{
    "connector": {...},
    "formatters": [...],
    "hints": {
        ...
    },
    "parsers": ["manifest"],
    ...
}
```

**Note**: The recommended way of running webhint is as a `devDependency` of
your project.

## Events emitted

The following events are emitted by the `parser`:

### `fetch::start::manifest`

Event is of type [`FetchStart`][fetchstart] and is emitted when the
parser starts downloading the web app manifest file.

### `fetch::end::manifest`

Event is of type [`FetchEnd`][fetchend] and is emitted when the parser
successfully downloaded the web app manifest file.

### `fetch::error::manifest`

Event is of type [`FetchError`][fetcherror] and is emitted when the
parser encounters a problem trying to fetch the web app manifest file.

### `parse::end::manifest`

Event is emitted when the parser successfully completed parsing
the web app manifest file.

**Format:**

```ts
export type ManifestParsed = FetchEnd & {
    /** The content of manifest parsed */
    parsedContent: Manifest;
};
```

### `parse::error::manifest::json`

Event is emitted when the content of the web app manifest file
is not valid JSON.

**Format:**

```ts
export type ManifestInvalidJSON = ErrorEvent & {
    /** The parse JSON error. */
    error: Error;
};
```

### `parse::error::manifest::schema`

Event is emitted when the content of the web app manifest file
is not valid according to the schema.

**Format:**

```ts
export type ManifestInvalidSchema = ErrorEvent & {
    /** The parse errors as returned by ajv. */
    errors: ajv.ErrorObject[];
    /** The errors in a more human readable format. */
    prettifiedErrors: string[];
};
```

## Types

If you need to import any type or enum defined in this parser, you just
need to import them as follows:

```ts
import { TypeOrEnumYouWantToUse } from '@hint/parser-manifest';
```

<!-- Link labels: -->

[fetchend]: https://webhint.io/docs/contributor-guide/getting-started/events/#fetchend
[fetcherror]: https://webhint.io/docs/contributor-guide/getting-started/events/#fetcherror
[fetchstart]: https://webhint.io/docs/contributor-guide/getting-started/events/#fetchstart
[hintrc]: https://webhint.io/docs/user-guide/configuring-webhint/summary/
[manifest]: https://www.w3.org/TR/appmanifest/
npm package: @hint/parser-package-json
Description: webhint parser to analyze the package.json file
Latest version: 1.1.43

# package.json config (`@hint/parser-package-json`)

This parser detects if a `package.json` file is present in the project and
validates its configuration against the `package.json` schema.

This package is installed automatically by webhint:

```bash
npm install hint --save-dev
```

To use it, activate it via the [`.hintrc`][hintrc] configuration file:

```json
{
    "connector": {...},
    "formatters": [...],
    "hints": {
        ...
    },
    "parsers": ["package-json"],
    ...
}
```

**Note**: The recommended way of running webhint is as a `devDependency` of
your project.

## Events emitted

This `parser` emits the following events:

* `parse::start::package-json`, of type `PackageJsonParseStart`
  which contains the following information:

  * `resource`: the resource we are going to parse.

* `parse::end::package-json`, of type `PackageJsonParsed`
  which contains the following information:

  * `resource`: the parsed resource.
  * `config`: an object with a valid configuration.
  * `getLocation`: method yeilding the resource's problem location.

* `parse::error::package-json::json`, of type `PackageJsonInvalidJSON`
  which contains the following information:

  * `resource`: the parsed resource.
  * `error`: the error emited parsing the package.json.

* `parse::error::package-json::schema`, of type `PackageJsonInvalidSchema`
  which contains the following information:

  * `resource`: the parsed resource.
  * `error`: the error message.
  * `errors`: all the errors that the schama validator returns.
  * `prettifiedErrors`: the errors formatted in a way that is easy to understand.

## Types

If you need to import any type or enum defined in this parser,
you need to import them as follows:

```ts
import { TypeOrEnumYouWantToUse } from '@hint/parser-package-json';
```

<!-- Link labels: -->

[hintrc]: https://webhint.io/docs/user-guide/configuring-webhint/summary/
npm package: @hint/parser-sass
Description: webhint parser needed to analyze SASS and SCSS files
Latest version: 1.0.31

# SASS (`@hint/parser-sass`)

The `SASS` parser is built on top of [PostCSS][postcss] so hints can
analyze `SASS` and `SCSS` files. It emits the same events as
`@hint/parser-css` so existing hints targeting `CSS` files will work
without modification.

This package is installed automatically by webhint:

```bash
npm install hint --save-dev
```

To use it, activate it via the [`.hintrc`][hintrc] configuration file:

```json
{
    "connector": {...},
    "formatters": [...],
    "hints": {
        ...
    },
    "parsers": ["sass"],
    ...
}
```

**Note**: The recommended way of running webhint is as a `devDependency` of
your project.

## Events emitted

This `parser` emits the following events:

* `parse::start::css` of type `Event` which contains the following information:

  * `resource`: the resource we are going to parse.

* `parse::end::css` of type `StyleParse` which has the following information:

  * `ast`: a PostCSS `Root` object containing the AST.
    See the [PostCSS `walk*` APIs][postcss-walk] for help navigating
    the AST.
  * `code`: a string containing the raw stylesheet source code.
  * `element`: an `HTMLElement` reference if the source was inline
    in HTML; `null` otherwise.
  * `resource`: the parsed resource. If the CSS is in a `style tag`
    and not a file, the value will refer to the HTML document containing
    the stylesheet.

## Limitations

This parser is not fault-tolerant (unlike `@hint/parser-css`) so only
well-formed files will be parsed.

<!-- Link labels: -->

[hintrc]: https://webhint.io/docs/user-guide/configuring-webhint/summary/
[postcss]: https://postcss.org/
[postcss-walk]: https://api.postcss.org/Container.html#walk
npm package: @hint/parser-typescript
Description: webhint parser needed to analyze TypeScript files
Latest version: 1.0.26

# TypeScript (`@hint/parser-typescript`)

The `typescript` parser emits the same events as `@hint/parser-javascript`
so existing hints targeting JavaScript files can analyze TypeScript files
without modification. Existing hints targeting HTML files can also analyze
TSX content without modification if `@hint/parser-jsx` is active in addition
to this parser.

This package is installed automatically by webhint:

```bash
npm install hint --save-dev
```

To use it, activate it via the [`.hintrc`][hintrc] configuration file:

```json
{
    "connector": {...},
    "formatters": [...],
    "hints": {
        ...
    },
    "parsers": ["jsx", "typescript"],
    ...
}
```

**Note**: The recommended way of running webhint is as a `devDependency` of
your project.

## Events emitted

This `parser` emits the following events:

* `parse::start::javascript` of type `Event` which contains the following
  information:

  * `resource`: the resource we are going to parse.

* `parse::end::javascript`, of type `ScriptParse` which contains the following
  information:

  * `ast`: an `ESTree` AST generated from the script.
  * `element`: an `HTMLElement` reference if the source was inline
    in HTML; `null` otherwise.
  * `resource`: the parsed resource. If the script is in
    a `script tag` and not a file, the value will refer to the
    HTML document containing the script.
  * `sourceCode`: the raw source code that was parsed.
  * `tokens`: a list of tokens generated from the source code.
  * `walk`: helper methods for walking the AST.

<!-- Link labels: -->

[hintrc]: https://webhint.io/docs/user-guide/configuring-webhint/summary/
npm package: @hint/parser-typescript-config
Description: webhint parser needed to analyze TypeScript config files
Latest version: 2.4.31

# TypeScript config (`@hint/parser-typescript-config`)

The `typescript-config` parser allows the user to analyze the
TypeScript configuration in their projects.

It will detect if a TypeScript configuration file is present in
your project, checking the name of the file (i.e. `tsconfig.json`,
`tsconfig.developement.json`). This parser detects if a config file
has a valid content.

This package is installed automatically by webhint:

```bash
npm install hint --save-dev
```

To use it, activate it via the [`.hintrc`][hintrc] configuration file:

```json
{
    "connector": {...},
    "formatters": [...],
    "hints": {
        ...
    },
    "parsers": ["typescript-config"],
    ...
}
```

**Note**: The recommended way of running webhint is as a `devDependency` of
your project.

## Events emitted

This `parser` emits the following events:

* `parse::start::typescript-config`, of type `TypeScriptConfigParseStart`
  which contains the following information:

  * `resource`: the resource we are going to parse.

* `parse::end::typescript-config`, of type `TypeScriptConfigParse`
  which contains the following information:

  * `resource`: the parsed resource.
  * `getLocation`: helper to find the location of a path within the original
    JSON source.
  * `config`: the final configuration after adding default values
    (`TypeScriptConfig`).
  * `mergedConfig`: the merged configuration after inlining `extends`.
  * `originalConfig`: the original configuration before resolving `extends`.

* `parse::error::typescript-config::json`, of type `TypeScriptConfigInvalidJSON`
  which contains the following information:

  * `resource`: the parsed resource.
  * `error`: the error emited parsing the configuration file.

* `parse::error::typescript-config::cicular`, of type `TypeScriptConfigInvalidJSON`
  which contains the following information:

  * `resource`: the parsed resource.
  * `error`: the error emited parsing the configuration file.

* `parse::error::typescript-config::extends`, of type `TypeScriptConfigInvalidJSON`
  which contains the following information:

  * `resource`: the parsed resource.
  * `error`: the error emited parsing the configuration file.

* `parse::error::typescript-config::schema`, of type
  `TypeScriptConfigInvalidSchema` which contains the following information:

  * `resource`: the parsed resource.
  * `errors`: all the errors that the schama validator returns.

## Types

If you need to import any type or enum defined in this parser, you
need to import them as follows:

```ts
import { TypeOrEnumYouWantToUse } from '@hint/parser-typescript-config';
```

<!-- Link labels: -->

[hintrc]: https://webhint.io/docs/user-guide/configuring-webhint/summary/
npm package: @hint/parser-webpack-config
Description: webhint parser needed to analyze webpack config files
Latest version: 2.1.42

# webpack config (`@hint/parser-webpack-config`)

The `webpack-config` parser allows the user to analyze the webpack
configuration in their projects.

It will detect if a webpack configuration file is present in your
project, checking the name of the file (`webpack.config.json`).

This package is installed automatically by webhint:

```bash
npm install hint --save-dev
```

To use it, activate it via the [`.hintrc`][hintrc] configuration file:

```json
{
    "connector": {...},
    "formatters": [...],
    "hints": {
        ...
    },
    "parsers": ["webpack-config"],
    ...
}
```

**Note**: The recommended way of running webhint is as a `devDependency` of
your project.

## Events emitted

This `parser` emits the following events:

* `parse::end::webpack-config`, of type `WebpackConfigParse`
  which contains the following information:

  * `resource`: the parsed resource.
  * `config`: an object with a valid configuration (`webpack.Configuration`).
  * `version`: the webpack version installed locally.

* `parse::error::webpack-config::configuration`, of type `WebpackConfigInvalidConfiguration`
  which contains the following information:

  * `resource`: the parsed resource.
  * `error`: the error emited parsing the configuration file.

* `parse::error::webpack-config::not-install`. This event is sent if
  the package `webpack` is not installed locally. This event doesn't
  containt anything else.

* `parse::error::webpack-config::not-found`. This event is sent if
  the parser doesn't find any configuration file at the end of the
  scan. This event doesn't containt anything else.

## Types

If you need to import any type defined in this parser, you need to
import them as follows:

```ts
import { TypeYouWantToUse } from '@hint/parser-webpack-config';
```

<!-- Link labels: -->

[hintrc]: https://webhint.io/docs/user-guide/configuring-webhint/summary/
npm package: @hint/utils
Description: hint tools
Latest version: 7.0.24

# Utils (`@hint/utils`)

Set of tools for hint.

## Installation

To install the package, you need to run:

```bash
npm install @hint/utils
```

## Tools

The tools included in this package are:

* `asyncTry`: Wrap an async function, returning null if the evaluation throws
and exception.
* `get-hints-from-extends`: Returns all hints in a configuration, including
hints inside the extended configurations.

### compat

* `getFriendlyName`: Get the friendly name of a browser from an id.
* `getUnsupported`: Get browsers without support for CSS or HTML features.
* `getUnsupportedDetails`: Get browsers without support with details on
  when support was added or removed.
* `isSupported`: Query MDN for support of CSS or HTML features.

### configStore

* `get`: Get the value from the config store.
* `set`: Set a value in the config store.

### contentType

* `determineMediaTypeBasedOnFileExtension`: Get a mime-type associated
  with the specified file extension.
* `determineMediaTypeBasedOnFileName`: Get a mime-type associated with
  the specified filename.
* `determineMediaTypeForScript`: Check if the provided mime-type is a
  recognized mime-type for JavaScript, returning the recommended
  mime-type if so, `null` otherwise.
* `getContentTypeData`: Try to determine the correct mime-type for a
  response.
* `getFileExtension`: Try to determine a resource's file extension.
* `getType`: Returns the group to which the mediaType belongs to. E.g.:
  `image`, `font`, `script`, `css`, `html`, `manifest`, `xml` or
  `unknown`.
* `isTextMediaType`: Check if a mime-type represents a text-based
  resource.

### logger

* `error`: Cover for console.error.
* `log`: Cover for console.log.
* `warn`: Cover for console.warn.

### misc

* `askQuestion`: Asks a y/n question to the user defaulting to Yes.
* `delay`: Convenience wrapper to add a delay using promises.
* `mergeEnvWithOptions`: Merges any `webhint_` prefixed environment
  variable available with the given `options` object.

### npm

* `installPackages`: Install the given packages.
* `search`: Searches all the packages in npm given `searchTerm`.
* `getOfficialPackages`: Get core packages from npm.
* `getUnnoficialPackages`: Get external packages from npm.

### packages

* `findNodeModulesRoot`: Find the node_modules folder where hint is installed
as a dependency or returns the hint node_modules folder if not.
* `findPackageRoot`: Searches for the first folder that contains the
`fileToFind` going up the tree.
* `isOfficial`: Returns if the hint that is going to be created is an
official.
* `loadPackage`: Returns the package found in the given `pathString` or an
exception if no package is found.
* `hasMultipleResources`: Returns true if a hint package is a multi-hint.
* `isFullPackageName`: Returns true if the name is a full package name.
* `loadHintPackage`: Returns the package `hint`.
* `loadResource`: Returns a resource if it exists.
* `requirePackage`: Require a package, compatible with webpack.
npm package: @hint/utils-connector-tools
Description: hint tools for connectors
Latest version: 4.0.42

# Connector utils (`@hint/utils-connector-tools`)

Set of tools for connectors

## Installation

To install the package, you need to run:

```bash
npm install @hint/utils-connector-tools
```

## Tools

* `normalize-headers`: Normalize headers setting the header name
  to lowercase.
* `redirects`: Redirects manager to keep track of the redirects.
* `requester`: Do request to a given url using the package request.
* `resolver`: Resolve urls.
npm package: @hint/utils-create-server
Description: hint create server util
Latest version: 3.4.27

# Create Server (`@hint/utils-create-server`)

Create a server to run tests

## Installation

This package is installed automatically when using `npm create hint`,
no need to do anything from your side.

## Architecture

The test web server can run in a different thread (default) or the same one
(when in CI or if indicated by the user ) as the tests.
The following is a summary on the benefits of each one:

* Independent:
  * Better isolation
  * Improve the debugging experience (website can load even if the execution
    is stopped in a breakpoint)
* Same thread:
  * Less resources needed
  * Faster execution

There main pieces are:

* `index.ts`: This is what modules consume. Depending on the configuration
  or the environment it will use one type of server or another.
* `same-thread-server.ts`: The real web server. It uses `express` and listens
  to the messages sent by `index.ts`. This will also be the class used when
  running in CI. If `spawn`ed then it will listen for IPC messages for the
  configuration.
* `independent-thread-server.ts`: It is a "wrapper" on top of
  `same-thread-server.ts`. It `spawn`s that process and handles the
  communication with it asynchronously.

When using a different process, each message sent needs a response to confirm
the action has been completed, i.e. if it sends a `start` message it should
receive a `start` message as well.
In the case of same thread all the methods are `async` as well so both servers
implement the same interface and the code does not need to special handle one
or the other.

The following is an example of messages used:

```json
{
    "webhint": {
        "type": "start"
    }
}
```

Please note that all messages are "scoped" to `webhint` to avoid collision
with other possible messages.

IPC serializes the messages to `JSON`. Unfortunatelly it does not accept
[`replacer`][replacer]/[`reviver`][reviver] functions. The server
configuration accepts `Buffer`s so in order to send the right data we need
to manually (de)serialize the messages in both ends.

<!-- Link labels -->

[replacer]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify#The_replacer_parameter
[reviver]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse#Using_the_reviver_parameter
npm package: @hint/utils-css
Description: utils for CSS
Latest version: 1.0.15

# CSS utils (`@hint/utils-CSS`)

Set of helpers to process CSS.

## Installation

This package is installed automatically when adding webhint to your project
so running the following is enough:

```bash
npm install hint --save-dev
```

## Utils

* `getCSSCodeSnippet`: Generate a Snippet code for a CSS node.
* `getCSSLocationFromNode`: Returns the location of a CSS node.
* `getFullCSSCodeSnippet`: Generate a full Snippet code for a CSS node.