test: incorrect html formatting

[claytonrcarter]

This adds a test for a couple of cases where the plugin is formatting markup in a way that changes the layout. For example, some (all?) cases of things like <a ...>foo</a>. are being formatted as

<a ...>
  foo
</a>
.

Which – depending on CSS – changes the rendered content in the browser because of the added whitespace around foo and .

The two tests I added are both taken from (obfuscated) examples I came across while running this plugin on our codebase at work, so they're nominally real-world examples. 😆 I just added assertions to see if the blade plugin produced identical output to the core prettier HTML parser/formatter, and both are failing.

As noted in #90, I'm new around here, so it's possible that this is a known issue, or is being done intentionally, but these surprised me so I thought I'd report them. Thank you!

[JohnathonKoster]

Currently done intentionally as it manually manages Prettier's html-whitespace-sensitivity option. The current challenges (and reason it manually adjusts this) is when some setting combinations produces output like this:

<a target="_blank" href="/arbitrary-path/to-a-file"
    >Lorem ipsum dolor sit amet, consectetur</a
>

The layout engine produces quite a few temporary HTML tags in the background that this really confuses. Definitely wouldn't mind improving this and respecting that setting, but will take some thinking

[claytonrcarter]

Currently done intentionally

OK, I see.

Definitely wouldn't mind improving this and respecting that setting, but will take some thinking

Any pointers on where in the codebase to look at this, just as a jumpstart? I changed the html-whitespace-sensitivity locally and basically everything exploded, so I couldn't focus in on any particular area. Not that I'll be helpful in improving things, but I'd like to at least poke at it a bit. Respecting the intent of the input markup feels like an important improvement.