-
Notifications
You must be signed in to change notification settings - Fork 15
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
[WIP] Color format checking for bslint #94
[WIP] Color format checking for bslint #94
Conversation
disc7
commented
Jul 27, 2023
•
edited
Loading
edited
- 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Empty template string as in ``, @elsassph , @philippe-wm ?
@@ -0,0 +1,11 @@ | |||
sub init() | |||
color = `0xfffff0FF` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that's fair. I guess we're only validating whole strings, so we should do the same with template strings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I pushed those changes.