-
-
Notifications
You must be signed in to change notification settings - Fork 946
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
Added: function-url-scheme-blacklist
rule.
#2626
Conversation
/cc @stylelint/core |
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.
Looking good.
Minor doc request. Additionally, can you update:
docs/user-guide/example-config.md
.docs/user-guide/rules.md
.
If we ever add any more rules which operate on the scheme of a URL I suggest we abstract some of the code this and the whitelist
rule, e.g. is schemeless url, into utilities. I think it's fine at the moment, though.
@@ -0,0 +1,67 @@ | |||
# function-url-scheme-blacklist | |||
|
|||
Specify a blacklist of allowed url schemes. |
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.
Specify a blacklist of disallowed url schemes.
@jeddy3 stupid error, sorry |
76e07a7
to
9f7c21f
Compare
/cc @jeddy3 |
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.
LGTM thanks
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.
Great work!
I have few questions, though, in comments.
Also, please, make all “url” → “URL” in readme, because “URL” is an acronym.
const ruleName = "function-url-scheme-blacklist" | ||
|
||
const messages = ruleMessages(ruleName, { | ||
rejected: scheme => `Unexpected url scheme "${scheme}:"`, |
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.
Upper case “URL”.
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.
done, also in whitelist
rule.
return (root, result) => { | ||
const validOptions = validateOptions(result, ruleName, { | ||
actual: blacklist, | ||
possible: [_.isString], |
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.
Readme says it accepts array|string
. I'm not sure if it checks that. There're no tests if only one string
was in config (not array with one string
).
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.
@hudochenkov we use this in all *-blacklist/*-whitelist
rules.
|
||
testRule(rule, { | ||
ruleName, | ||
config: [[]], |
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.
Why this test group rejects https
and data
? Is it an undocumented behaviour?
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.
@hudochenkov this used if your want add all schemes to blacklist, analogy in whitelist
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.
But still behaviour isn't documented anywhere. We should document this.
|
||
testRule(rule, { | ||
ruleName, | ||
config: [""], |
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.
Why this test group rejects https
and data
? Is it an undocumented behaviour?
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.
@hudochenkov we already have same tests in function-url-scheme-whitelist
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.
But still behaviour isn't documented anywhere. We should document this.
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.
@hudochenkov can your help me with this, I would like the current time to concentrate on the new rules (#2528) and I'm bad at documentation 😞
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.
@hudochenkov Good catch! Sorry I missed this. This isn't the correct behaviour. Both [""]
and [[]]
should allow all schemes.
This is how the other -blacklist
rules behave. The -whitelist
rules behave differently because whitelists and blacklists are different.
It's useful to think as:
blacklist: []
= "blacklist nothing" i.e. "everything is ok"
whitelist: []
= "whitelist nothing" i.e. "nothing is ok".
9f7c21f
to
93b5a52
Compare
/cc @hudochenkov |
93b5a52
to
bae664d
Compare
|
||
testRule(rule, { | ||
ruleName, | ||
config: [""], |
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.
@hudochenkov Good catch! Sorry I missed this. This isn't the correct behaviour. Both [""]
and [[]]
should allow all schemes.
This is how the other -blacklist
rules behave. The -whitelist
rules behave differently because whitelists and blacklists are different.
It's useful to think as:
blacklist: []
= "blacklist nothing" i.e. "everything is ok"
whitelist: []
= "whitelist nothing" i.e. "nothing is ok".
@jeddy3 can your help with documentation this? |
It's a behaviour issue, not a documentation one. I'm pushing up a commit to fix though. |
|
@jeddy3 After commits what are my actions here? Or just wait when @hudochenkov do review? |
Just wait on @hudochenkov as my commits came off the back of his original review. |
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.
RegEx addition is 🔥
And again about ""
and []
configurations. We won't document them?
|
||
A [URL scheme](https://url.spec.whatwg.org/#syntax-url-scheme) consists of alphanumeric, `+`, `-`, and `.` characters. It can appear at the start of a URL and is followed by `:`. | ||
|
||
This rule treats URL schemes as case insensitive (`https` and `HTTPS` are the same). |
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've removed the tests for case insensitive primary options. None of the other *-*list rules have case-insensitive primary options. If we want to revisit this behaviour, so should do so across the board and in a separate issue. — @jeddy3
Is this line in readme still valid?
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.
Yes. I've added tests to show this.
Like all the other *-*list
rules, this rule now only accepts lowercase primary options but is case insensitive when checking for matches.
So function-url-scheme-blacklist: "http"
will disallow both http://g.co/x.jpg
and HTTP://g.co/x.jpg
.
#2660 is about allowing the user to specify primary options in any case e.g. function-url-scheme-blacklist: "HTTP"
, or function-blacklist: "translateX"
.
I'm not sure there's any need to do that now because the behaviour is intuitive. We don't document this behaviour in any of the other
|
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.
Thank you for your work, @evilebottnawi and @jeddy3!
Changelog
|
#2513
No, it's self explanatory.