Clearly describe the bug

::-moz-focus-inner is treated as a pseudo-class, not a pseudo-element, and so can cause false positives in no-descending-specificity.

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

no-descending-specificity

What code is needed to reproduce the bug?

a::-moz-focus-inner {}
a 

Hey. Just a question. Can we add possibility to extend from single string not just from array? So it will work like other linting libraries (eslint, stylelint, etc.).

package.json

"babel":  {
  "extends": "shared-tools"
},
"commitlint": {
  "extends": [
    "shared-tools"
  ]
},
"eslintConfig": {
  "extends": "shared-tools"
}

What it does

Suggest option.and_then(|value| value.inner_option) instead of option.and_then(|value| Some(value.inner_option?))

Categories (optional)

• Kind: style or complexity

What is the advantage of the recommended code over the original code

There's no reason to take an option, wrap it in another option, and use ? to short-circuit. and_then will work fine without

Currently the webhint codebase doesn't follow its own best practice of using importHelpers: true to reduce the amount of redundant helper code generated by TypeScript (also requires adding tslib as a dependency). This causes unnecessary bloat in the built webhint code, particularly for large bundles like the bro

There's a formatting specification for Tag Keys and Values. One issue with applying some changes is that you are disallowed from using certain characters (notably the ,) in a Tag Value, and this is not being caught by tflint currently.

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-resource-tags.html#w2ab1c25c10d254c13c17

Current

export declare type TextlintRuleReportHandler = {
    [P in ASTNodeTypes]?: (node: TypeofTxtNode<P>) => void | Promise<any>;
} & {
    [index: string]: (node: any) => void | Promise<any>;
};
/**
 * Textlint rule reporter function
 */
export declare type TextlintRuleReporter<T extends object = {}> = (context: Readonly<TextlintRuleContext>, options?: TextlintRuleOptions<T>) 

I really like enforcing one expectation per example. But with RSpec's exception matching, you need two expect calls if you want to assert something about an exception:

expect { my_code }.to raise_error(MyErrorType) do |error|
  expect(error.message).to match /something went wrong/
end

There's no way to match against the error message without first wrapping the call, and RSpec o