Fix false positives for JS variables in value-keyword-case

[jsg2021]

Clearly describe the bug

stylelint is checking and flagging/fixing javascript as if it were css.

Which rule, if any, is the bug related to?

all? value-keyword-case in this example.

What code is needed to reproduce the bug?

some file named with .jsx extension

demo.jsx:

function Foo(props) {
	const myBackground = '....';
	const style = {
		...props.style,

		backgroundImage: myBackground ? myBackground : 'url(...)',
	};

	return <div {...props} style={style} />;
}

What stylelint configuration is needed to reproduce the bug?

e.g.

{
  "extends": [
    "stylelint-config-standard"
  ]
}

Which version of stylelint are you using?

13.11.0

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

VS code extension and cli... my cli ignores JS files for now. But when I save in vs code, it breaks if I allow its save-action.

Does the bug relate to non-standard syntax (e.g. SCSS, Less etc.)?

no

What did you expect to happen?

No validation/fixing on js. CSS in tag template literals is fine to check because that IS css. But JS properties should not be validated.

What actually happened (e.g. what warnings or errors did you get)?

CSS errors are flagged. (and fixes attempted)

demo.jsx
 4:2   ✖  Expected indentation of 4 spaces               indentation       
 6:2   ✖  Expected indentation of 4 spaces               indentation       
 6:19  ✖  Expected "myBackground" to be "mybackground"   value-keyword-case
 6:34  ✖  Expected "myBackground" to be "mybackground"   value-keyword-case
 7:2   ✖  Expected indentation of 2 spaces               indentation

[jeddy3]

@jsg2021 Thanks for the report and for using the template.

I can reproduce this using the demo.

It's likely a problem with the parser stylelint uses to support CSS-in-JS. I've added this issue to #4574, which is a growing list of the problems with the syntax that we need help to fix.

Please consider contributing to the parser if you have time.

---

VS code extension and cli... my cli ignores JS files for now. But when I save in vs code, it breaks if I allow its save-action.

You can either:

• configure stylelint to ignore JS files - the VS Code extension will respect this
• configure the VS Code extension to only validate CSS files, e.g. validate: ["css"].

---

No validation/fixing on js. CSS in tag template literals is fine to check because that IS css. But JS properties should not be validated.

The majority of the built-in rules are applicable to CSS-in-JS object notation, especially the possible errors and feature limiting rules. Even a number of stylistic rules are applicable to strings within object notation, e.g. the following:

const Button = styled("button", {
  width: "Min( 100VW ,  .1%)"
}

Will be fixed to:

const Button = styled("button", {
  width: "min(100vw,  0.1%)"
}

[jsg2021]

Thanks!

No validation/fixing on js. CSS in tag template literals is fine to check because that IS css. But JS properties should not be validated.

The majority of the built-in rules are applicable to CSS-in-JS object notation, especially the possible errors and feature limiting rules. Even a number of stylistic rules are applicable to strings within object notation, e.g. the following:

const Button = styled("button", {
  width: "Min( 100VW ,  .1%)"
}

Will be fixed to:

const Button = styled("button", {
  width: "min(100vw,  0.1%)"
}

ah, that's a good point. My statement was too broad. I was specifically thinking about identifiers, not string literals.

[jsg2021]

I've added this to my code config to prevent js/css lint conflicting fix loops:

"editor.codeActionsOnSave": {
    "source.fixAll": true,
    "source.fixAll.stylelint": false
  },

[jsg2021]

Did some digging.

stylelint/lib/rules/value-keyword-case/index.js

Line 65 in 16ae9e4

const parsed = valueParser(getDeclarationValue(decl));

At this point, the value in the example is a JS expression, and the decl.parent.type is object... parsing the js expression as a CSS value. I would guess that it should ignore non-string-literal values in the expression?

[jeddy3]

Thanks for digging.

I would guess that it should ignore non-string-literal values in the expression?

The CSS-in-JS syntax should probably substitute JS expressions for dummy values in the PostCSS AST.

For example:

backgroundImage: myBackground ? myBackground : 'url(...)',

Becomes:

{
  "type": "root",
  "nodes": [
    {
      "type": "decl",
      "prop": "background-image",
      "value": "$dummyvalue"
    }
  ],
}

There's experimental work looking into doing this for interpolation in template literals.

[ahuglajbclajep]

There is a same problem with function-name-case.
stylelint-disable comments do not work for these.

[Alecell]

Same here, I've been trying to ignore the ${} pattern but without success.

There isn't a work around on this?

Edit:
I barely manage to make a work around on this, in my case I could only ignore all patterns that have a . and _ on the value, so something like foo.barBaz or FOO_BAR_BAZ will be ignored, but I'm certain that I'll need to update that pattern very soon.

Thats the pattern if someone is interested: "ignoreKeywords": ["/(\\.|_)+/"]

[rbong]

The CSS-in-JS syntax should probably substitute JS expressions for dummy values in the PostCSS AST.

Is that the best approach? It just seems like postcss-value-parser isn't meant to parse CSS-in-JS values. Maybe a new parser could help traverse CSS-in-JS values more accurately? I know that it would be a lot of work to develop a new parser and update rules, but all of the information you need to distinguish Javascript variables from strings is in the node, it's only discarded when the declaration value is read as a plain string and parsed.

[kachkaev]

I think I’m having the same issue in JSX:

const MyComponent = () => {
  const minWidth = 42;
  return <div style={{ minWidth }}>hello</div>;
}

This shows: Expected "minWidth" to be "minwidth" (value-keyword-case) stylelint(value-keyword-case).

We already have .stylelintignore with the following contents:

## file extensions
*.*
LICENSE
!*.css
!*.less


## shared between linters
...


## copied from .gitignore
...

(this approach to .stylelintignore file structure is described in prettier/prettier#6280 (comment))

All works in CLI, but because of a bug in the VSCode extension, the false positive still shows up in the editor. It is possible to set "stylelint.validate": ["css", "less"] in VSCode, but that only works for user preferences, so cannot be shared with the team via [project]/.vscode/settings.json.

Interestingly, replacing style={{ minWidth }} with blah={{ minWidth }} removes the error. Is there any workaround that would help ignore value-keyword-case by saying ‘don’t look at jsx → style prop’? 🤔

[jeddy3]

Closing as stylistic rules are frozen. The community is welcome to migrate the rule to a plugin and fix this bug.