fix: skip validating values containing env() in no-invalid-properties

[minseonkkim]

Prerequisites checklist

• I have read the contributing guidelines.

AI acknowledgment

• I did not use AI to generate this PR.
• (If the above is not checked) I have reviewed the AI-generated content before submitting.

What is the purpose of this pull request?

Fixes a false positive in no-invalid-properties: any declaration whose value contains env() was reported as Unknown property '...' found, even for obviously valid properties like padding-top.

What changes did you make? (Give an overview)

As noted in #509, the csstree fork bails out with a plain Error ("Matching for a tree with env() is not supported") when a value contains env(), but the rule was routing that error to the unknownProperty report.

I added an isEnvMatchError() helper to src/util.js and made the rule skip validation when that error occurs, since env() values come from the user agent and can't be validated anyway.

Unknown property names are still reported for declarations with env() values, because the lexer checks the property reference before the env() check — added an invalid test (paddin-top: env(...)) to lock that in, plus valid tests for env() alone, with a fallback, inside calc(), and in a shorthand.

Related Issues

fixes #509

Is there anything you'd like reviewers to focus on?

isEnvMatchError() matches the lexer's error by its exact message string. Let me know if there's a better way to detect this error.

[eslint-github-bot]

Hi @minseonkkim!, thanks for the Pull Request

The pull request title isn't properly formatted. We ask that you update the pull request title to match this format, as we use it to generate changelogs and automate releases.

• The length of the commit message must be less than or equal to 72

To Fix: You can fix this problem by clicking 'Edit' next to the pull request title at the top of this page.

Read more about contributing to ESLint here

[DMartens]

Could please add a valid test case for a declaration with multiple values but one of them is invalid (e.g. a { padding: env(safe-area-inset-top) red }) as we do not support partial validation.

[minseonkkim]

Thanks, good catch! Added it. I confirmed it stays valid since env() causes the whole value to skip validation.

[lumirlumir]

Non-blocking comment: relying on an internal error message seems fragile because changes in csstree could break this check. Error messages are generally not a stable API and may vary between versions.

Currently, there does not appear to be a reliable way to distinguish this unsupported env() matching case from other generic errors, so checking the message may be the most practical option for now.

In the longer term, introducing a custom error class -- similar to the existing SyntaxReferenceError and SyntaxMatchError -- or exposing a stable error code such as ERR_LEXER_ENV_MATCH_UNSUPPORTED would provide a more robust solution.

[DMartens]

This is an error only our fork of csstree throws (reference for upstream), so we could add an error code to this, but we can do this after this PR.

[lumirlumir]

@minseonkkim

If you’d like to open an issue about it, that would be welcome.

[minseonkkim]

Opened eslint/csstree#141 for this. Thanks for the suggestion!

[lumirlumir]

LGTM, thanks!

Would like @DMartens to verify before merging.

[DMartens]

These test cases should not be the first test cases as they check for specific scenarios.

[minseonkkim]

Thanks for the review! I've moved the env() test cases (including the new var()-in-env() case) after the existing generic cases in both arrays, grouped with a comment like the other scenario-specific test groups.

[DMartens]

Changes LGTM, thanks.