Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/rashfael/eslint-plugin-vue-pug below:

rashfael/eslint-plugin-vue-pug: linting your pug templates in vue single file components

Extends eslint-plugin-vue to support pug templates.

npm install --save-dev eslint@8 eslint-plugin-vue eslint-plugin-vue-pug

Most eslint-plugin-vue rules work out of the box with just adding this plugin in your eslint config:

module.exports = {
  extends: [
    'plugin:vue/vue3-recommended',
    'plugin:vue-pug/vue3-recommended'
  ]
}

• pug-lexer seems to convert windows-style CRLF line endings to LF line endings, which may break token position and will give you errors. Make sure to only use LF line endings.

This plugin only lints pug syntax that directly corresponds to html syntax. Pug syntax that is not supported includes mixins, js code, loops, if/else, case, include/extends. The linter will just skip those features, which means that tags inside mixins will not be linted. The rule no-pug-control-flow will help you to avoid unsupported pug syntax.

Do we want own docs for that? Also, pug has no inline comments.

Shorthands get dropped from attributes list to not affect attribute order. We need to add separate linter rules for those.

• no-useless-template-attributes checks for class on template, we need to also check shorthands.
• no-restricted-class needs special handling

Existing rule fails at fixing and does not replace " quotes with `.

pug splits up attribute names like :[[a,b,][1]]

first-attribute-linebreak adds a space between tag( and attr="" in certain scenarios.

Things like max-attributes-per-line would need to include the , in the attribute range for some fixes to work correctly, but this would break attribute-order.

there are some rules relying on HTML* tokens, like no-multi-spaces.

having both lang and src attributes on template, what does that even do?

Rules for HTML don't apply to pug, but do not seem to interfere with pug templates since they check HTML* tokens, which we don't emit. Should we still disable those rules or leave them on?

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4