Are rules (implemented by plugins) responsible for checking if syntax is standard/non-standard?

Describe the issue. Is it a bug or a feature request (new rule, new option, etc.)?

I maintain a plugin (https://github.com/ismay/stylelint-no-unsupported-browser-features) which currently breaks when used with LESS. It seems to be breaking because of the non-standard syntax being passed to doiuse, which can't handle that (see RJWadley/stylelint-no-unsupported-browser-features#36).

Now in the docs (https://stylelint.io/developer-guide/rules/#criteria-for-inclusion) it states that a rule needs to be applicable to standard syntax to be considered for inclusion. So I'm wondering, am I responsible for making sure that what my plugin is checking is standard-syntax, or is the LESS processor misbehaving by passing non-standard syntax to my plugin? Because other non-standard syntaxes seem to be working, so I'm wonderingif this is due to some issue with the LESS processor.

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

stylelint-no-unsupported-browser-features

What CSS is needed to reproduce this issue?

See related issue

What stylelint configuration is needed to reproduce this issue?

See related issue

Which version of stylelint are you using?

8

How are you running stylelint: CLI, PostCSS plugin, Node API?

See related issue

Does your issue relate to non-standard syntax (e.g. SCSS, nesting, etc.)?

Yes. Less.

What did you expect to happen?

See related issue

What actually happened (e.g. what warnings or errors you are getting)?

See related issue

[jeddy3]

@ismay Thanks for the question and for your continued maintenance of the plugin.

tl;dr I believe this line in doiuse can be changed to simple ignore node types that doiuse doesn't recognise, rather than throw an error.

---

Now in the docs (https://stylelint.io/developer-guide/rules/#criteria-for-inclusion) it states that a rule needs to be applicable to standard syntax to be considered for inclusion.

This is one of the criteria for built-in rules. Plugins, on the other hand, can do what they like. However, we encourage plugin authors to be considerate of non-standard syntax.

For example, the non-standard map construct introduced in SCSS is parsed as a declaration in PostCSS e.g. $map: (key1: value1, key2: value2, key3: value3); is parsed as a declaration with a property of $map and a value of (key1: value1, key2: value2, key3: value3).

We use the isStandardSyntax* utils (e.g. isStandardSyntaxDeclaration) in the built-in in rules to ignore these construct i.e. all the declaration-* rules will only target normal CSS declarations rather than non-standard constructs that are parsed as declarations. This allows all users, regardless of whether they use non-standard constructs in their code, to use the built-in rules and then frees up plugin authors to target these non-standard constructs, see the list of rules in stylelint-scss.

So I'm wondering, am I responsible for making sure that what my plugin is checking is standard-syntax

This isn't really applicable in your plugin's case as the whole source is passed to doiuse. I mean, you could check the whole AST for an occurrence of the import node type and then not pass the whole source to doiuse, but that seems excessive and it's probably better just addressing this upstream in doiuse.

or is the LESS processor misbehaving by passing non-standard syntax to my plugin?

I believe the Less parser introduced a new node type (import) to the AST and it is entitled to do so. All PostCSS plugins should probably ignore node types they don't recognise, rather than throwing an error, as this allows for additional node types to be added to the AST by either the PostCSS standard CSS parser or by any of other PostCSS parsers (postcss-less, postcss-scss, sugarss etc).

Because other non-standard syntaxes seem to be working

I don't believe any of the other parsers have introduced a new node type before. That's why this issue is only surfacing now.

This isn't really applicable in your plugin's case as the whole source is passed to doiuse. I mean, you could check the whole AST for an occurrence of the import node type and then not pass the whole source to doiuse, but that seems excessive and it's probably better just addressing this upstream in doiuse.

Yeah I was thinking about that and not looking forward to it :). Just ignoring unfamiliar syntax seems more straightforward.

All PostCSS plugins should probably ignore node types they don't recognise, rather than throwing an error, as this allows for additional node types to be added to the AST by either the PostCSS standard CSS parser or by any of other PostCSS parsers (postcss-less, postcss-scss, sugarss etc).

That makes sense. I also don't see a reason for it to be a problem to remove the current error from doiuse (as I think you'll only want to be warned when syntax isn't supported, and unfamiliar syntax can just be ignored).

Thanks for the question and for your continued maintenance of the plugin.

No problem, thanks for the quick and detailed reply! 👍

[jeddy3]

That makes sense. I also don't see a reason for it to be a problem to remove the current error from doiuse (as I think you'll only want to be warned when syntax isn't supported, and unfamiliar syntax can just be ignored).

Agreed. I suspect that simply skipping over unfamiliar syntax is what is best for the user. Would you be able to submit an issue and/or PR for this? It looks like you've access.

I'll close this issue for now.

Would you be able to submit an issue and/or PR for this? It looks like you've access.

Yep, I'll do that in the near future. Thanks for the feedback!

@jeddy3 I've encountered a similar issue with the above plugin again. Stylelint 8 doesn't filter non-standard syntax, so a user using for example .scss would cause my plugin to pass non-standard syntax to doiuse, which doiuse can't handle.

I know that stylelint has the isStandard... utils, but they're not explicitly exported it seems, so I'm not sure if I can rely on them. Also it seems awkward to have to test the css with every rule.

So I'm wondering if there are any other plugins dealing with this problem, and what the recommended way is to handle it.

[jeddy3]

Stylelint 8 doesn't filter non-standard syntax, so a user using for example .scss would cause my plugin to pass non-standard syntax to doiuse, which doiuse can't handle.

@ismay I mostly answered this in RJWadley/stylelint-no-unsupported-browser-features#45 (comment). I recommend just documenting that your plugin is only compatible with standard syntax. Alternatively, you can update doiuse itself to ignore non-standard constructs.

So I'm wondering if there are any other plugins dealing with this problem,

Not so much. I believe the majority of plugins are not wrappers for other PostCSS plugins.

I know that stylelint has the isStandard... utils, but they're not explicitly exported it seems, so I'm not sure if I can rely on them.

I think around version 4 we did export a few of these utils. We stopped because they were in flux so much. They've settled down now and I think we could consider adding them back. For example, stylelint-order duplicates a few of them. It might be a good idea to publish them as a separate packages (like we did with stylesearch), rather than as part of the public API e.g. postcss-is-standard-syntax-rule, postcss-is-standard-syntax-selector etc within a monorepo.