Identical blocks of code found in 2 locations. Consider refactoring. Open
export interface ClientApiAddon<StoryFnReturnType = unknown> extends Addon {
apply: (a: StoryApi<StoryFnReturnType>, b: any[]) => any;
}
- Read upRead up
Duplicated Code
Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).
Tuning
This issue has a mass of 51.
We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.
The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.
If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.
See codeclimate-duplication
's documentation for more information about tuning the mass threshold in your .codeclimate.yml
.
Refactorings
- Extract Method
- Extract Class
- Form Template Method
- Introduce Null Object
- Pull Up Method
- Pull Up Field
- Substitute Algorithm
Further Reading
- Don't Repeat Yourself on the C2 Wiki
- Duplicated Code on SourceMaking
- Refactoring: Improving the Design of Existing Code by Martin Fowler. Duplicated Code, p76
Shadowed name: 'Args' Open
export interface BaseAnnotations<Args, StoryFnReturnType> {
- Read upRead up
- Exclude checks
Rule: no-shadowed-variable
Disallows shadowing variable declarations.
Rationale
When a variable in a local scope and a variable in the containing scope have the same name, shadowing occurs. Shadowing makes it impossible to access the variable in the containing scope and obscures to what value an identifier actually refers. Compare the following snippets:
const a = 'no shadow';
function print() {
console.log(a);
}
print(); // logs 'no shadow'.
const a = 'no shadow';
function print() {
const a = 'shadow'; // TSLint will complain here.
console.log(a);
}
print(); // logs 'shadow'.
ESLint has an equivalent rule. For more background information, refer to this MDN closure doc.
Config
You can optionally pass an object to disable checking for certain kinds of declarations.
Possible keys are "class"
, "enum"
, "function"
, "import"
, "interface"
, "namespace"
, "typeAlias"
and "typeParameter"
. You can also pass "underscore
" to ignore variable names that begin with _
.
Just set the value to false
for the check you want to disable.
All checks default to true
, i.e. are enabled by default.
Note that you cannot disable variables and parameters.
The option "temporalDeadZone"
defaults to true
which shows errors when shadowing block scoped declarations in their
temporal dead zone. When set to false
parameters, classes, enums and variables declared
with let
or const
are not considered shadowed if the shadowing occurs within their
temporal dead zone.
The following example shows how the "temporalDeadZone"
option changes the linting result:
function fn(value) {
if (value) {
const tmp = value; // no error on this line if "temporalDeadZone" is false
return tmp;
}
let tmp = undefined;
if (!value) {
const tmp = value; // this line always contains an error
return tmp;
}
}
Examples
"no-shadowed-variable": true
"no-shadowed-variable": true,[object Object]
Schema
{
"type": "object",
"properties": {
"class": {
"type": "boolean"
},
"enum": {
"type": "boolean"
},
"function": {
"type": "boolean"
},
"import": {
"type": "boolean"
},
"interface": {
"type": "boolean"
},
"namespace": {
"type": "boolean"
},
"typeAlias": {
"type": "boolean"
},
"typeParameter": {
"type": "boolean"
},
"temporalDeadZone": {
"type": "boolean"
},
"underscore": {
"type": "boolean"
}
}
}
For more information see this page.
Type literal has only a call signature — use ((args: Args, context: StoryContext) => StoryFnReturnType;)
instead. Open
(args: Args, context: StoryContext): StoryFnReturnType;
- Read upRead up
- Exclude checks
Rule: callable-types
An interface or literal type with just a call signature can be written as a function type.
Rationale
style
Notes
- TypeScript Only
- Has Fix
Config
Not configurable.
For more information see this page.
Shadowed name: 'Args' Open
export type BaseStoryFn<Args, StoryFnReturnType> = {
- Read upRead up
- Exclude checks
Rule: no-shadowed-variable
Disallows shadowing variable declarations.
Rationale
When a variable in a local scope and a variable in the containing scope have the same name, shadowing occurs. Shadowing makes it impossible to access the variable in the containing scope and obscures to what value an identifier actually refers. Compare the following snippets:
const a = 'no shadow';
function print() {
console.log(a);
}
print(); // logs 'no shadow'.
const a = 'no shadow';
function print() {
const a = 'shadow'; // TSLint will complain here.
console.log(a);
}
print(); // logs 'shadow'.
ESLint has an equivalent rule. For more background information, refer to this MDN closure doc.
Config
You can optionally pass an object to disable checking for certain kinds of declarations.
Possible keys are "class"
, "enum"
, "function"
, "import"
, "interface"
, "namespace"
, "typeAlias"
and "typeParameter"
. You can also pass "underscore
" to ignore variable names that begin with _
.
Just set the value to false
for the check you want to disable.
All checks default to true
, i.e. are enabled by default.
Note that you cannot disable variables and parameters.
The option "temporalDeadZone"
defaults to true
which shows errors when shadowing block scoped declarations in their
temporal dead zone. When set to false
parameters, classes, enums and variables declared
with let
or const
are not considered shadowed if the shadowing occurs within their
temporal dead zone.
The following example shows how the "temporalDeadZone"
option changes the linting result:
function fn(value) {
if (value) {
const tmp = value; // no error on this line if "temporalDeadZone" is false
return tmp;
}
let tmp = undefined;
if (!value) {
const tmp = value; // this line always contains an error
return tmp;
}
}
Examples
"no-shadowed-variable": true
"no-shadowed-variable": true,[object Object]
Schema
{
"type": "object",
"properties": {
"class": {
"type": "boolean"
},
"enum": {
"type": "boolean"
},
"function": {
"type": "boolean"
},
"import": {
"type": "boolean"
},
"interface": {
"type": "boolean"
},
"namespace": {
"type": "boolean"
},
"typeAlias": {
"type": "boolean"
},
"typeParameter": {
"type": "boolean"
},
"temporalDeadZone": {
"type": "boolean"
},
"underscore": {
"type": "boolean"
}
}
}
For more information see this page.
Shadowed name: 'Args' Open
export type BaseStory<Args, StoryFnReturnType> =
- Read upRead up
- Exclude checks
Rule: no-shadowed-variable
Disallows shadowing variable declarations.
Rationale
When a variable in a local scope and a variable in the containing scope have the same name, shadowing occurs. Shadowing makes it impossible to access the variable in the containing scope and obscures to what value an identifier actually refers. Compare the following snippets:
const a = 'no shadow';
function print() {
console.log(a);
}
print(); // logs 'no shadow'.
const a = 'no shadow';
function print() {
const a = 'shadow'; // TSLint will complain here.
console.log(a);
}
print(); // logs 'shadow'.
ESLint has an equivalent rule. For more background information, refer to this MDN closure doc.
Config
You can optionally pass an object to disable checking for certain kinds of declarations.
Possible keys are "class"
, "enum"
, "function"
, "import"
, "interface"
, "namespace"
, "typeAlias"
and "typeParameter"
. You can also pass "underscore
" to ignore variable names that begin with _
.
Just set the value to false
for the check you want to disable.
All checks default to true
, i.e. are enabled by default.
Note that you cannot disable variables and parameters.
The option "temporalDeadZone"
defaults to true
which shows errors when shadowing block scoped declarations in their
temporal dead zone. When set to false
parameters, classes, enums and variables declared
with let
or const
are not considered shadowed if the shadowing occurs within their
temporal dead zone.
The following example shows how the "temporalDeadZone"
option changes the linting result:
function fn(value) {
if (value) {
const tmp = value; // no error on this line if "temporalDeadZone" is false
return tmp;
}
let tmp = undefined;
if (!value) {
const tmp = value; // this line always contains an error
return tmp;
}
}
Examples
"no-shadowed-variable": true
"no-shadowed-variable": true,[object Object]
Schema
{
"type": "object",
"properties": {
"class": {
"type": "boolean"
},
"enum": {
"type": "boolean"
},
"function": {
"type": "boolean"
},
"import": {
"type": "boolean"
},
"interface": {
"type": "boolean"
},
"namespace": {
"type": "boolean"
},
"typeAlias": {
"type": "boolean"
},
"typeParameter": {
"type": "boolean"
},
"temporalDeadZone": {
"type": "boolean"
},
"underscore": {
"type": "boolean"
}
}
}
For more information see this page.
unused expression, expected an assignment or function call Open
StoryId,
StoryKind,
StoryName,
StoryIdentifier,
ViewMode,
- Read upRead up
- Exclude checks
Rule: no-unused-expression
Disallows unused expression statements.
Unused expressions are expression statements which are not assignments or function calls (and thus usually no-ops).
Rationale
Detects potential errors where an assignment or function call was intended.
Config
Three arguments may be optionally provided:
-
allow-fast-null-checks
allows to use logical operators to perform fast null checks and perform method or function calls for side effects (e.g.e && e.preventDefault()
). -
allow-new
allows 'new' expressions for side effects (e.g.new ModifyGlobalState();
. -
allow-tagged-template
allows tagged templates for side effects (e.g.this.add\
foo`;`.
Examples
"no-unused-expression": true
"no-unused-expression": true,allow-fast-null-checks
Schema
{
"type": "array",
"items": {
"type": "string",
"enum": [
"allow-fast-null-checks",
"allow-new",
"allow-tagged-template"
]
},
"minLength": 0,
"maxLength": 3
}
For more information see this page.
Shadowed name: 'Args' Open
export interface Annotations<Args, StoryFnReturnType>
- Read upRead up
- Exclude checks
Rule: no-shadowed-variable
Disallows shadowing variable declarations.
Rationale
When a variable in a local scope and a variable in the containing scope have the same name, shadowing occurs. Shadowing makes it impossible to access the variable in the containing scope and obscures to what value an identifier actually refers. Compare the following snippets:
const a = 'no shadow';
function print() {
console.log(a);
}
print(); // logs 'no shadow'.
const a = 'no shadow';
function print() {
const a = 'shadow'; // TSLint will complain here.
console.log(a);
}
print(); // logs 'shadow'.
ESLint has an equivalent rule. For more background information, refer to this MDN closure doc.
Config
You can optionally pass an object to disable checking for certain kinds of declarations.
Possible keys are "class"
, "enum"
, "function"
, "import"
, "interface"
, "namespace"
, "typeAlias"
and "typeParameter"
. You can also pass "underscore
" to ignore variable names that begin with _
.
Just set the value to false
for the check you want to disable.
All checks default to true
, i.e. are enabled by default.
Note that you cannot disable variables and parameters.
The option "temporalDeadZone"
defaults to true
which shows errors when shadowing block scoped declarations in their
temporal dead zone. When set to false
parameters, classes, enums and variables declared
with let
or const
are not considered shadowed if the shadowing occurs within their
temporal dead zone.
The following example shows how the "temporalDeadZone"
option changes the linting result:
function fn(value) {
if (value) {
const tmp = value; // no error on this line if "temporalDeadZone" is false
return tmp;
}
let tmp = undefined;
if (!value) {
const tmp = value; // this line always contains an error
return tmp;
}
}
Examples
"no-shadowed-variable": true
"no-shadowed-variable": true,[object Object]
Schema
{
"type": "object",
"properties": {
"class": {
"type": "boolean"
},
"enum": {
"type": "boolean"
},
"function": {
"type": "boolean"
},
"import": {
"type": "boolean"
},
"interface": {
"type": "boolean"
},
"namespace": {
"type": "boolean"
},
"typeAlias": {
"type": "boolean"
},
"typeParameter": {
"type": "boolean"
},
"temporalDeadZone": {
"type": "boolean"
},
"underscore": {
"type": "boolean"
}
}
}
For more information see this page.
Shadowed name: 'Args' Open
export type BaseStoryObject<Args, StoryFnReturnType> = {
- Read upRead up
- Exclude checks
Rule: no-shadowed-variable
Disallows shadowing variable declarations.
Rationale
When a variable in a local scope and a variable in the containing scope have the same name, shadowing occurs. Shadowing makes it impossible to access the variable in the containing scope and obscures to what value an identifier actually refers. Compare the following snippets:
const a = 'no shadow';
function print() {
console.log(a);
}
print(); // logs 'no shadow'.
const a = 'no shadow';
function print() {
const a = 'shadow'; // TSLint will complain here.
console.log(a);
}
print(); // logs 'shadow'.
ESLint has an equivalent rule. For more background information, refer to this MDN closure doc.
Config
You can optionally pass an object to disable checking for certain kinds of declarations.
Possible keys are "class"
, "enum"
, "function"
, "import"
, "interface"
, "namespace"
, "typeAlias"
and "typeParameter"
. You can also pass "underscore
" to ignore variable names that begin with _
.
Just set the value to false
for the check you want to disable.
All checks default to true
, i.e. are enabled by default.
Note that you cannot disable variables and parameters.
The option "temporalDeadZone"
defaults to true
which shows errors when shadowing block scoped declarations in their
temporal dead zone. When set to false
parameters, classes, enums and variables declared
with let
or const
are not considered shadowed if the shadowing occurs within their
temporal dead zone.
The following example shows how the "temporalDeadZone"
option changes the linting result:
function fn(value) {
if (value) {
const tmp = value; // no error on this line if "temporalDeadZone" is false
return tmp;
}
let tmp = undefined;
if (!value) {
const tmp = value; // this line always contains an error
return tmp;
}
}
Examples
"no-shadowed-variable": true
"no-shadowed-variable": true,[object Object]
Schema
{
"type": "object",
"properties": {
"class": {
"type": "boolean"
},
"enum": {
"type": "boolean"
},
"function": {
"type": "boolean"
},
"import": {
"type": "boolean"
},
"interface": {
"type": "boolean"
},
"namespace": {
"type": "boolean"
},
"typeAlias": {
"type": "boolean"
},
"typeParameter": {
"type": "boolean"
},
"temporalDeadZone": {
"type": "boolean"
},
"underscore": {
"type": "boolean"
}
}
}
For more information see this page.
Do not use comma operator here because it can be easily misunderstood or lead to unintended bugs. Open
StoryId,
StoryKind,
StoryName,
StoryIdentifier,
ViewMode,
- Read upRead up
- Exclude checks
Rule: ban-comma-operator
Disallows the comma operator to be used.
Read more about the comma operator here.
Rationale
Using the comma operator can create a potential for many non-obvious bugs or lead to misunderstanding of code.
Examples
foo((bar, baz)); // evaluates to 'foo(baz)' because of the extra parens - confusing and not obvious
switch (foo) {
case 1, 2: // equals 'case 2' - probably intended 'case 1: case2:'
return true;
case 3:
return false;
}
let x = (y = 1, z = 2); // x is equal to 2 - this may not be immediately obvious.
Examples
"ban-comma-operator": true
For more information see this page.
missing whitespace Open
Args,
} from '@storybook/csf';
- Read upRead up
- Exclude checks
Rule: whitespace
Enforces whitespace style conventions.
Rationale
Helps maintain a readable, consistent style in your codebase.
Notes
- Has Fix
Config
Several arguments may be optionally provided:
-
"check-branch"
checks branching statements (if
/else
/for
/while
) are followed by whitespace. -
"check-decl"
checks that variable declarations have whitespace around the equals token. -
"check-operator"
checks for whitespace around operator tokens. -
"check-module"
checks for whitespace in import & export statements. -
"check-separator"
checks for whitespace after separator tokens (,
/;
). -
"check-rest-spread"
checks that there is no whitespace after rest/spread operator (...
). -
"check-type"
checks for whitespace before a variable type specification. -
"check-typecast"
checks for whitespace between a typecast and its target. -
"check-type-operator"
checks for whitespace between type operators|
and&
. -
"check-preblock"
checks for whitespace before the opening brace of a block. -
"check-postbrace"
checks for whitespace after an opening brace.
Examples
"whitespace": true,check-branch,check-operator,check-typecast
Schema
{
"type": "array",
"items": {
"type": "string",
"enum": [
"check-branch",
"check-decl",
"check-operator",
"check-module",
"check-separator",
"check-rest-spread",
"check-type",
"check-typecast",
"check-type-operator",
"check-preblock",
"check-postbrace"
]
},
"minLength": 0,
"maxLength": 11
}
For more information see this page.
Do not use comma operator here because it can be easily misunderstood or lead to unintended bugs. Open
StoryId,
StoryKind,
StoryName,
StoryIdentifier,
- Read upRead up
- Exclude checks
Rule: ban-comma-operator
Disallows the comma operator to be used.
Read more about the comma operator here.
Rationale
Using the comma operator can create a potential for many non-obvious bugs or lead to misunderstanding of code.
Examples
foo((bar, baz)); // evaluates to 'foo(baz)' because of the extra parens - confusing and not obvious
switch (foo) {
case 1, 2: // equals 'case 2' - probably intended 'case 1: case2:'
return true;
case 3:
return false;
}
let x = (y = 1, z = 2); // x is equal to 2 - this may not be immediately obvious.
Examples
"ban-comma-operator": true
For more information see this page.
Do not use comma operator here because it can be easily misunderstood or lead to unintended bugs. Open
StoryId,
StoryKind,
StoryName,
StoryIdentifier,
ViewMode,
- Read upRead up
- Exclude checks
Rule: ban-comma-operator
Disallows the comma operator to be used.
Read more about the comma operator here.
Rationale
Using the comma operator can create a potential for many non-obvious bugs or lead to misunderstanding of code.
Examples
foo((bar, baz)); // evaluates to 'foo(baz)' because of the extra parens - confusing and not obvious
switch (foo) {
case 1, 2: // equals 'case 2' - probably intended 'case 1: case2:'
return true;
case 3:
return false;
}
let x = (y = 1, z = 2); // x is equal to 2 - this may not be immediately obvious.
Examples
"ban-comma-operator": true
For more information see this page.
unused expression, expected an assignment or function call Open
} from '@storybook/csf';
- Read upRead up
- Exclude checks
Rule: no-unused-expression
Disallows unused expression statements.
Unused expressions are expression statements which are not assignments or function calls (and thus usually no-ops).
Rationale
Detects potential errors where an assignment or function call was intended.
Config
Three arguments may be optionally provided:
-
allow-fast-null-checks
allows to use logical operators to perform fast null checks and perform method or function calls for side effects (e.g.e && e.preventDefault()
). -
allow-new
allows 'new' expressions for side effects (e.g.new ModifyGlobalState();
. -
allow-tagged-template
allows tagged templates for side effects (e.g.this.add\
foo`;`.
Examples
"no-unused-expression": true
"no-unused-expression": true,allow-fast-null-checks
Schema
{
"type": "array",
"items": {
"type": "string",
"enum": [
"allow-fast-null-checks",
"allow-new",
"allow-tagged-template"
]
},
"minLength": 0,
"maxLength": 3
}
For more information see this page.
Array type using 'Array<t>' is forbidden. Use 'T[]' instead.</t> Open
export type BaseDecorators<StoryFnReturnType> = Array<
(story: () => StoryFnReturnType, context: StoryContext) => StoryFnReturnType
>;
- Read upRead up
- Exclude checks
Rule: array-type
Requires using either 'T[]' or 'Array<t>' for arrays.</t>
Notes
- TypeScript Only
- Has Fix
Config
One of the following arguments must be provided:
-
"array"
enforces use ofT[]
for all types T. -
"generic"
enforces use ofArray<T>
for all types T. -
"array-simple"
enforces use ofT[]
ifT
is a simple type (primitive or type reference).
Examples
"array-type": true,array
"array-type": true,generic
"array-type": true,array-simple
Schema
{
"type": "string",
"enum": [
"array",
"generic",
"array-simple"
]
}
For more information see this page.
unused expression, expected an assignment or function call Open
export type {
- Read upRead up
- Exclude checks
Rule: no-unused-expression
Disallows unused expression statements.
Unused expressions are expression statements which are not assignments or function calls (and thus usually no-ops).
Rationale
Detects potential errors where an assignment or function call was intended.
Config
Three arguments may be optionally provided:
-
allow-fast-null-checks
allows to use logical operators to perform fast null checks and perform method or function calls for side effects (e.g.e && e.preventDefault()
). -
allow-new
allows 'new' expressions for side effects (e.g.new ModifyGlobalState();
. -
allow-tagged-template
allows tagged templates for side effects (e.g.this.add\
foo`;`.
Examples
"no-unused-expression": true
"no-unused-expression": true,allow-fast-null-checks
Schema
{
"type": "array",
"items": {
"type": "string",
"enum": [
"allow-fast-null-checks",
"allow-new",
"allow-tagged-template"
]
},
"minLength": 0,
"maxLength": 3
}
For more information see this page.
statements are not aligned Open
export type {
- Read upRead up
- Exclude checks
Rule: align
Enforces vertical alignment.
Rationale
Helps maintain a readable, consistent style in your codebase.
Consistent alignment for code statements helps keep code readable and clear. Statements misaligned from the standard can be harder to read and understand.
Notes
- Has Fix
Config
Five arguments may be optionally provided:
-
"parameters"
checks alignment of function parameters. -
"arguments"
checks alignment of function call arguments. -
"statements"
checks alignment of statements. -
"members"
checks alignment of members of classes, interfaces, type literal, object literals and object destructuring. -
"elements"
checks alignment of elements of array literals, array destructuring and tuple types.
Examples
"align": true,parameters,statements
Schema
{
"type": "array",
"items": {
"type": "string",
"enum": [
"arguments",
"elements",
"members",
"parameters",
"statements"
]
},
"minLength": 1,
"maxLength": 5
}
For more information see this page.
statements are not aligned Open
} from '@storybook/csf';
- Read upRead up
- Exclude checks
Rule: align
Enforces vertical alignment.
Rationale
Helps maintain a readable, consistent style in your codebase.
Consistent alignment for code statements helps keep code readable and clear. Statements misaligned from the standard can be harder to read and understand.
Notes
- Has Fix
Config
Five arguments may be optionally provided:
-
"parameters"
checks alignment of function parameters. -
"arguments"
checks alignment of function call arguments. -
"statements"
checks alignment of statements. -
"members"
checks alignment of members of classes, interfaces, type literal, object literals and object destructuring. -
"elements"
checks alignment of elements of array literals, array destructuring and tuple types.
Examples
"align": true,parameters,statements
Schema
{
"type": "array",
"items": {
"type": "string",
"enum": [
"arguments",
"elements",
"members",
"parameters",
"statements"
]
},
"minLength": 1,
"maxLength": 5
}
For more information see this page.
Missing semicolon Open
} from '@storybook/csf';
- Read upRead up
- Exclude checks
Rule: semicolon
Enforces consistent semicolon usage at the end of every statement.
Notes
- Has Fix
Config
One of the following arguments must be provided:
-
"always"
enforces semicolons at the end of every statement. -
"never"
disallows semicolons at the end of every statement except for when they are necessary.
The following arguments may be optionally provided:
-
"ignore-interfaces"
skips checking semicolons at the end of interface members. -
"ignore-bound-class-methods"
skips checking semicolons at the end of bound class methods. -
"strict-bound-class-methods"
disables any special handling of bound class methods and treats them as any other assignment. This option overrides"ignore-bound-class-methods"
.
Examples
"semicolon": true,always
"semicolon": true,never
"semicolon": true,always,ignore-interfaces
"semicolon": true,always,ignore-bound-class-methods
Schema
{
"type": "array",
"items": [
{
"type": "string",
"enum": [
"always",
"never"
]
},
{
"type": "string",
"enum": [
"ignore-interfaces"
]
}
],
"additionalItems": false
}
For more information see this page.
Missing semicolon Open
export type {
- Read upRead up
- Exclude checks
Rule: semicolon
Enforces consistent semicolon usage at the end of every statement.
Notes
- Has Fix
Config
One of the following arguments must be provided:
-
"always"
enforces semicolons at the end of every statement. -
"never"
disallows semicolons at the end of every statement except for when they are necessary.
The following arguments may be optionally provided:
-
"ignore-interfaces"
skips checking semicolons at the end of interface members. -
"ignore-bound-class-methods"
skips checking semicolons at the end of bound class methods. -
"strict-bound-class-methods"
disables any special handling of bound class methods and treats them as any other assignment. This option overrides"ignore-bound-class-methods"
.
Examples
"semicolon": true,always
"semicolon": true,never
"semicolon": true,always,ignore-interfaces
"semicolon": true,always,ignore-bound-class-methods
Schema
{
"type": "array",
"items": [
{
"type": "string",
"enum": [
"always",
"never"
]
},
{
"type": "string",
"enum": [
"ignore-interfaces"
]
}
],
"additionalItems": false
}
For more information see this page.
unused expression, expected an assignment or function call Open
} from '@storybook/csf';
- Read upRead up
- Exclude checks
Rule: no-unused-expression
Disallows unused expression statements.
Unused expressions are expression statements which are not assignments or function calls (and thus usually no-ops).
Rationale
Detects potential errors where an assignment or function call was intended.
Config
Three arguments may be optionally provided:
-
allow-fast-null-checks
allows to use logical operators to perform fast null checks and perform method or function calls for side effects (e.g.e && e.preventDefault()
). -
allow-new
allows 'new' expressions for side effects (e.g.new ModifyGlobalState();
. -
allow-tagged-template
allows tagged templates for side effects (e.g.this.add\
foo`;`.
Examples
"no-unused-expression": true
"no-unused-expression": true,allow-fast-null-checks
Schema
{
"type": "array",
"items": {
"type": "string",
"enum": [
"allow-fast-null-checks",
"allow-new",
"allow-tagged-template"
]
},
"minLength": 0,
"maxLength": 3
}
For more information see this page.
Do not use comma operator here because it can be easily misunderstood or lead to unintended bugs. Open
StoryId,
StoryKind,
StoryName,
StoryIdentifier,
ViewMode,
- Read upRead up
- Exclude checks
Rule: ban-comma-operator
Disallows the comma operator to be used.
Read more about the comma operator here.
Rationale
Using the comma operator can create a potential for many non-obvious bugs or lead to misunderstanding of code.
Examples
foo((bar, baz)); // evaluates to 'foo(baz)' because of the extra parens - confusing and not obvious
switch (foo) {
case 1, 2: // equals 'case 2' - probably intended 'case 1: case2:'
return true;
case 3:
return false;
}
let x = (y = 1, z = 2); // x is equal to 2 - this may not be immediately obvious.
Examples
"ban-comma-operator": true
For more information see this page.
Do not use comma operator here because it can be easily misunderstood or lead to unintended bugs. Open
StoryId,
StoryKind,
StoryName,
- Read upRead up
- Exclude checks
Rule: ban-comma-operator
Disallows the comma operator to be used.
Read more about the comma operator here.
Rationale
Using the comma operator can create a potential for many non-obvious bugs or lead to misunderstanding of code.
Examples
foo((bar, baz)); // evaluates to 'foo(baz)' because of the extra parens - confusing and not obvious
switch (foo) {
case 1, 2: // equals 'case 2' - probably intended 'case 1: case2:'
return true;
case 3:
return false;
}
let x = (y = 1, z = 2); // x is equal to 2 - this may not be immediately obvious.
Examples
"ban-comma-operator": true
For more information see this page.
Do not use comma operator here because it can be easily misunderstood or lead to unintended bugs. Open
StoryId,
StoryKind,
- Read upRead up
- Exclude checks
Rule: ban-comma-operator
Disallows the comma operator to be used.
Read more about the comma operator here.
Rationale
Using the comma operator can create a potential for many non-obvious bugs or lead to misunderstanding of code.
Examples
foo((bar, baz)); // evaluates to 'foo(baz)' because of the extra parens - confusing and not obvious
switch (foo) {
case 1, 2: // equals 'case 2' - probably intended 'case 1: case2:'
return true;
case 3:
return false;
}
let x = (y = 1, z = 2); // x is equal to 2 - this may not be immediately obvious.
Examples
"ban-comma-operator": true
For more information see this page.
Missing semicolon Open
Args,
- Read upRead up
- Exclude checks
Rule: semicolon
Enforces consistent semicolon usage at the end of every statement.
Notes
- Has Fix
Config
One of the following arguments must be provided:
-
"always"
enforces semicolons at the end of every statement. -
"never"
disallows semicolons at the end of every statement except for when they are necessary.
The following arguments may be optionally provided:
-
"ignore-interfaces"
skips checking semicolons at the end of interface members. -
"ignore-bound-class-methods"
skips checking semicolons at the end of bound class methods. -
"strict-bound-class-methods"
disables any special handling of bound class methods and treats them as any other assignment. This option overrides"ignore-bound-class-methods"
.
Examples
"semicolon": true,always
"semicolon": true,never
"semicolon": true,always,ignore-interfaces
"semicolon": true,always,ignore-bound-class-methods
Schema
{
"type": "array",
"items": [
{
"type": "string",
"enum": [
"always",
"never"
]
},
{
"type": "string",
"enum": [
"ignore-interfaces"
]
}
],
"additionalItems": false
}
For more information see this page.