☂️ HTML Parsing and Formatting

[dyc3]

Description

This will track the overall status of the HTML parser and formatter. This issue can be closed when the feature flag for HTML is removed, the HTML parser and formatter is publicly available, and it is enabled by default. This does not track anything for the HTML analyzer (for lint rules).

This is necessary in order for Biome to support framework specific template languages, like Vue, Svelte, and Angular. If you are a user of one of these frameworks, Biome already has support for processing embedded JS/TS in these files, but with some caveats. We have recommended configuration here to help provide the best experience for the time being.

Status

Overall: Kinda flaky, but technically functional.

• Available in the playground
• Parses all prettier formatter tests.
• Formats all prettier formatter tests.
• Support for prettier's options
  • 📎 HTML: Implement "Bracket same line" option #4024
  • 📎 HTML: Implement "Attribute Position" option #4828
  • HTML specific
    • htmlWhitespaceSensitivity
    • vueIndentScriptAndStyle
• Formats embedded languages, CSS and JS in style and script tags. (see also: 📎 Embedded language formatting #3334 )
• Migrations for relevant prettier configuration to biome

How to Contribute

All well defined smaller tasks can be found by looking at the L-HTML label. Looking to contribute? Start by looking there.

[TyOverby]

This issue can be closed when the feature flag for HTML is removed, and the HTML parser and formatter is publicly available.

What is this feature flag? In addition to the automated tests, I'd like to be able to run the main biome executable while hacking on html support!

[dyc3]

I'm referring to this:

biome/crates/biome_cli/Cargo.toml

Line 81 in eedb22e

experimental-html = ["biome_service/experimental-html"]

The easiest way to hack on the formatter is to use the quick_test thing we have set up: https://github.com/biomejs/biome/blob/next/crates/biome_html_formatter/tests/quick_test.rs

[sandstrom]

Probably something you've thought about, but HTML isn't always the 'vanilla' flavour. Handlebars, Liquid, ERB and several other templating languages exist.

They often add some 'special tags' on top of HTML.

As a first, it would be great if it could just 'ignore' those sections, i.e. continue parsing the file but not trying to interpret anything non-standard.

Then maybe as a second step also understand the handlebars/liquid/erb etc. stuff (probably via plugins?).

[ematipico]

@sandstrom you might not know that, but Biome parsers are recoverable and error resilient, which means you can have even non-standard syntax inside (in this case) an HTML file, and you'll still get something somewhat analysable :)

https://biomejs.dev/playground/?lintRules=all&files.main.html=PAB1AGwAIABjAGwAYQBzAHMAPQAiAHAAZQBvAHAAbABlAF8AbABpAHMAdAAiAD4ACgAgACAAewB7ACMAZQBhAGMAaAAgAHAAZQBvAHAAbABlAH0AfQAKACAAIAAgACAAPABsAGkAPgB7AHsAdABoAGkAcwB9AH0APAAvAGwAaQA%2BAAoAIAAgAHsAewAvAGUAYQBjAGgAfQB9AAoAPAAvAHUAbAA%2BAA%3D%3D

[sandstrom]

@ematipico Sounds like you've already thought about it! 😄 Great!

[ismailkarsli]

Is there a chance to bring this feature as --experimental?

[dyc3]

I'm planning to have the HTML formatter in 2.0 in some form. It just won't be enabled by default most likely so that we can have users try it out and report bugs.

[codetroll]

Will there be a way to ignore tags that has i18n tags in them? Currently Prettier pretty much destroys everything i18n for us.

[ematipico]

@codetroll can you please be more specific with some examples and context? Some people might not know what you're talking about

[codetroll]

Sure,

currently we might have text like this :

<p i18n>Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</p>

Once Prettier has been over it, it might look like this:

<p i18n>
    Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
    Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
</p>

This means that our i18n extractions gets new keys, and thus looses any translations.

So if there were an option to let biome know it should skip changing anything inside the tag, leaving the text as it was.

The newlines etc which prettier has inserted in the text causes the new keys to be generated during i18n extraction.

ESLint has a configuration for prettier to ignore attributes with i18n:

 {
            "files": [
                "*.html"
            ],
            "excludedFiles": [
                "*inline-template-*.component.html"
            ],
            "extends": [
                "plugin:@angular-eslint/template/recommended",
                "plugin:@angular-eslint/template/accessibility",
                "plugin:prettier/recommended"
            ],
            "rules": {
                "max-len": "off",
                "prettier/prettier": [
                    "error",
                    {
                        "parser": "angular",
                        "printWidth": 400,
                        "proseWrap": "preserve",
                        "ignoredAttributes": [
                            "i18n"
                        ]
                    }
                ]
            }
        }

But the VS Code plugin for example doesn't take prettier rules in ESLint configrations into considerations, so while the above should work in VSCode it doesn't.

As we are using different IDE's in our team, a general solution would be much prefrerrable.

[dyc3]

@codetroll Interesting. Would you mind opening up a new discussion for this so we aren't flooding people with notifs here?

[codetroll]

@codetroll Interesting. Would you mind opening up a new discussion for this so we aren't flooding people with notifs here?

Done : #5327