[WIP] Color format checking for bslint #94
Conversation
disc7
commented
Jul 27, 2023
•
disc7
commented
- proposed way to check for color formatting in brs and bs files.
|
does this also include transparency suffix? I believe that bs will accept: I'd recommend it forces the |
|
Not yet. I've got a local branch with alpha values allowed, default alpha allowed, case (upper or lower) and Roku broadcast safe color cert requirement compliance. Once I know we can determine a range to flag known color styling issues (in brs / bs and xml files - given that there is no color token type in ESlint) will update this to include those. |
There was a problem hiding this comment.
there is no color token type in ES lint, how do we determine the range to flag line numbers?
Just for clarification: bslint is written as a brighterscript plugin, ESLint is not involved at all.
there is no color token type
There probably will never be a color token type. in brs/bs files, Tokens like TokenKind.StringLiteral, TokenKind.IntegerLiteral represent all of the various formats that colors can be stored as, so those are what you'll want to be inspecting.
However, I'm not really sure how you'll be able to validate anything accurately other than in XML files for known "color" fields on built-in roku nodes.
A better type systep is right around the corner, but we still haven't added support for any of the component types, so you won't know which fields are color type.
test/project1/source/colors/literals/color-alpha-mixed-values.brs
Outdated
Show resolved
Hide resolved
src/plugins/codeStyle/index.ts
Outdated
| } | ||
| }, | ||
| TemplateStringExpression: e => { | ||
| const token = e.quasis[0].expressions[0].token; |
There was a problem hiding this comment.
Are all the expressions always string literals?
Also this expects the very first expression to be provided - I suspect it can break in a number of ways:
- empty template string,
- complex template like
${value}something.
Probably you shouldn't check any case of template string with zero or more than one expression, and you need to ensure the 1st expression is a string. No?
There was a problem hiding this comment.
Empty template string as in ``, @elsassph , @philippe-wm ?
| @@ -0,0 +1,11 @@ | |||
| sub init() | |||
| color = `0xfffff0FF` | |||
There was a problem hiding this comment.
You need more cases, like empty strings, complex templates with variables (at the beginning, end...).
… color-style-checking
…into color-style-checking
|
I've just pushed some changes.
@elsassph any other concerns? |
src/plugins/codeStyle/index.ts
Outdated
| }, | ||
| TemplateStringExpression: e => { | ||
| if (validateColorStyle) { | ||
| for (const quasi of e.quasis.map(x => x.expressions).flat()) { |
There was a problem hiding this comment.
IMHO I think the linter should bail if there is more than 1 quasi and if it has more than one expression - we shouldn't try to look for colours in a complex template literal, because that's not a use case for setting UI colours, isn't it?
There was a problem hiding this comment.
Yeah that's fair. I guess we're only validating whole strings, so we should do the same with template strings.
