Fix with workaround a TypeError thrown for "html"

[jeddy3]

Which issue, if any, is this issue related to?

Closes #4793

Is there anything in the PR that needs further explanation?

It's not clear what's happening here, and a deeper investigation is needed. It appears the HTML syntax is somehow interfering with JavaScript files that contain the word "html".

We can workaround the issue by not lazy loading the HTML syntax ourselves and instead relying on postcss-syntax mechanism. We can do this because we are using the original postcss-html module, unlike with postcss-markdown and postcss-css-in-js where we are using our own forks.

I'll create a follow-up issue at some point to discuss what we do about postcss-syntax going forward. At the moment the syntax inferring is being handled by an unmaintained package.

[mattxwang]

Seems like a reasonable workaround for now, LGTM!

[m-allanson]

Updated changelog:

• Fixed: workaround CSS-in-JS syntax throws a TypeError in the following conditions: 1. encounter a call or template expression named 'html' and 2. syntax loads via autoSyntax().

[m-allanson]

I've created a reproduction for this issue here: https://github.com/m-allanson/stylelint-issue-4793

In case anyone wants to dig into this further. The bug is caused by using a call expression (such as html()) or a tagged template expression (such as html`foo`).

Here's how it's happening.

It's triggered when stylelint autoloads syntaxes. When autoloading syntaxes, stylelint adds the html syntax to its own options.

When running, the css-in-js syntax checks the global stylelint options for available syntaxes.

The css-in-js syntax sees that the options specify an html syntax, and so (incorrectly) assumes the html expression contains parseable styles.

It then runs into some unexpected behaviour, triggering a TypeError.

The error is triggered in the isStylePath function.