What is the problem you're trying to solve?

I would like me and my colleagues to be able to use edge-of-your-seat new features to CSS. Sometimes features are not known to Stylelint yet and it would be nice if developers wouldn't have to disable linting for a few lines in the meantime.

What solution would you like to see

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"
}

cargo clippy -- -W help seems to run clippy, so it takes a while on a first build and, of course, it requires a project. Would it be possible to print the available lints and quit, similar to rustc -W help?

Context: in rust-analyzer we'd like to offer code completions for the various lints, but the only way to get them is to download http://rust-lang.github.io/rust-clippy/master/lin

moment is considered legacy now by their team, we should think about moving to other alternatives

Originally posted by @molant in webhintio/hint#4040 (comment)

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