Skip to content

feat: no-invalid-properties allowUnknownVariables option #178

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 6 commits into from
Jun 26, 2025

Conversation

jgoz
Copy link
Contributor

@jgoz jgoz commented Jun 19, 2025

Prerequisites checklist

What is the purpose of this pull request?

Adds an option to no-invalid-properties called allowUnknownVariables. When true, variable references that can't be traced to a custom property definition are ignored.

What changes did you make? (Give an overview)

Added an options schema for no-invalid-properties describing allowUnknownVariables. When the option is true, do the following:

  • Ignore variable references that were not found up to this point (skip reporting unknownVar)
  • Only report unknownProperty for errors of type SyntaxReferenceError, which indicate that the property is unknown

Also updated documentation for the rule to reflect this option as best I could.

Related Issues

Fixes #175

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

Adds an option to `no-invalid-properties` called
`allowUnknownVariables`. When true, variable references that can't be
traced to a custom property definition are ignored.

Fixes eslint#175
Copy link

linux-foundation-easycla bot commented Jun 19, 2025

CLA Signed

The committers listed above are authorized under a signed CLA.

@lumirlumir lumirlumir added the accepted There is consensus among the team that this change meets the criteria for inclusion label Jun 20, 2025
@nzakas nzakas requested a review from Copilot June 20, 2025 18:52
Copy link

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

Adds an allowUnknownVariables option to the no-invalid-properties rule, letting users ignore variable references that can’t be traced to custom properties and adjust which errors are reported accordingly.

  • Updated rule schema and logic to default allowUnknownVariables to false, skip unknownVar reports when enabled, and only report unknownProperty on reference errors.
  • Introduced a new helper isSyntaxReferenceError in util.js and modified imports.
  • Expanded tests and documentation to cover the new option.

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File Description
tests/rules/no-invalid-properties.test.js Added valid and invalid tests exercising allowUnknownVariables
src/util.js Added isSyntaxReferenceError helper and updated import doc
src/rules/no-invalid-properties.js Introduced schema option, wired up allowUnknownVariables in reporting logic
docs/rules/no-invalid-properties.md Documented the new allowUnknownVariables option and examples
Comments suppressed due to low confidence (2)

src/util.js:30

  • [nitpick] The JSDoc @returns type uses a TypeScript type predicate. For clarity and consistency with JSDoc conventions, consider changing this to @returns {boolean} and describing the predicate in the description.
 * @returns {error is SyntaxReferenceError} True if the error is a syntax reference error, false if not.

docs/rules/no-invalid-properties.md:47

  • [nitpick] After replacing the old Limitations section, you may want to reintroduce it (or rename it) to explain any remaining parser limitations, or ensure that the table of contents and heading hierarchy are updated for clarity.
## Options

properties: {
allowUnknownVariables: {
type: "boolean",
default: false,
Copy link
Preview

Copilot AI Jun 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ESLint does not apply default values from the schema at runtime. Since you already fallback in code (?? false), you can remove this default property to avoid confusion.

Suggested change
default: false,

Copilot uses AI. Check for mistakes.

@@ -72,6 +73,18 @@ export default {
url: "https://github.com/eslint/css/blob/main/docs/rules/no-invalid-properties.md",
},

schema: [
Copy link
Preview

Copilot AI Jun 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[nitpick] Consider adding additionalProperties: false inside the schema object to prevent unknown or misspelled options from silently being accepted.

Copilot uses AI. Check for mistakes.

Copy link
Member

@nzakas nzakas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is looking really good. Just one note to clean things up a bit.

@@ -95,6 +108,9 @@ export default {
*/
const replacements = [];

const allowUnknownVariables =
context.options?.[0]?.allowUnknownVariables ?? false;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you use defaultOptions (example), then you can do this:

Suggested change
context.options?.[0]?.allowUnknownVariables ?? false;
context.options.[0].allowUnknownVariables;

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, thank you. Updated, but used destructuring syntax to match the style in relative-font-units

@nzakas nzakas moved this from Needs Triage to Implementing in Triage Jun 20, 2025
Copy link
Contributor

@snitin315 snitin315 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR. I found one issue while defining fallbacks in var

/* eslint css/no-invalid-properties: ["error"] */

:root {
	--my-color: red;
}

a {
	color: var(--my-color, red); // This now reports error - Unknown property 'color' found  css/no-invalid-propertie
}

@snitin315
Copy link
Contributor

snitin315 commented Jun 21, 2025

Another case:

/* eslint css/no-invalid-properties: ["error",  { allowUnknownVariables: false }] */

:root {
	--my-color: red;
}

.two {
	color: var(--my-color, var(--my-background, pink));  //  error  Unknown property 'color' found  css/no-invalid-properties
}

@jgoz
Copy link
Contributor Author

jgoz commented Jun 21, 2025

Thanks for the PR. I found one issue while defining fallbacks in var

Good catch, but I think this issue exists in main. Maybe it should be treated as a separate issue?

Edit: Both of the cases you point out are unrelated to my changes and are both issues that exist in main.

@Tanujkanti4441
Copy link
Contributor

Good catch, but I think this issue exists in main. Maybe it should be treated as a separate issue?

Edit: Both of the cases you point out are unrelated to my changes and are both issues that exist in main.

I can also reproduce this in main, have created an issue to discuss this #180

@snitin315
Copy link
Contributor

Good catch, but I think this issue exists in main. Maybe it should be treated as a separate issue?

I see. Yes, let's tackle it separately.

jgoz and others added 2 commits June 23, 2025 08:46
Co-authored-by: Tanuj Kanti <86398394+Tanujkanti4441@users.noreply.github.com>
@jgoz jgoz requested review from Tanujkanti4441 and snitin315 June 23, 2025 14:49
Copy link
Member

@nzakas nzakas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks! Would like @snitin315 and @Tanujkanti4441 to verify their feedback has been addressed before merging.

@nzakas
Copy link
Member

nzakas commented Jun 24, 2025

@jgoz please double-check the lint error.

@nzakas nzakas moved this from Implementing to Second Review Needed in Triage Jun 24, 2025
@jgoz
Copy link
Contributor Author

jgoz commented Jun 24, 2025

@nzakas That was a formatting error in a file I didn't change, so I'm not sure what happened there. I merged the latest from main in case it was an artifact of GHA's pull_request behavior that operates on a synthetic merge commit.

@lumirlumir
Copy link
Member

Hi everyone, The CI failure is due to the newly released Prettier v3.6.0.

I’ve opened #182 to fix the issue. Once it’s merged into main, the error should be resolved.

@lumirlumir
Copy link
Member

#182 has now been merged, so the CI error should be resolved once we merge the main branch. 👍

@nzakas
Copy link
Member

nzakas commented Jun 25, 2025

Thanks @lumirlumir 🙏

@jgoz
Copy link
Contributor Author

jgoz commented Jun 25, 2025

Merged from main

Copy link
Contributor

@snitin315 snitin315 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!

@snitin315 snitin315 dismissed Tanujkanti4441’s stale review June 26, 2025 08:27

Stale & comments resolved

@snitin315 snitin315 merged commit 932cf62 into eslint:main Jun 26, 2025
22 checks passed
@github-project-automation github-project-automation bot moved this from Second Review Needed to Complete in Triage Jun 26, 2025
@jgoz jgoz deleted the feat-allowUnknownVariables branch June 26, 2025 14:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accepted There is consensus among the team that this change meets the criteria for inclusion contributor pool feature
Projects
Status: Complete
Development

Successfully merging this pull request may close these issues.

Rule Change: no-invalid-properties option to only validate property names with unknown variables
5 participants