Function addStoriesFromExports
has 54 lines of code (exceeds 25 allowed). Consider refactoring. Open
addStoriesFromExports(fileName: Path, fileExports: ModuleExports) {
// if the export haven't changed since last time we added them, this is a no-op
if (this.csfExports[fileName] === fileExports) {
return;
}
Function getStoryIndex
has 38 lines of code (exceeds 25 allowed). Consider refactoring. Open
getStoryIndex(store: StoryStore<TFramework>) {
const fileNameOrder = Object.keys(this.csfExports);
const storySortParameter = this.projectAnnotations.parameters?.options?.storySort;
const storyEntries = Object.entries(this.stories);
Identical blocks of code found in 2 locations. Consider refactoring. Open
export interface GetStorybookKind<TFramework extends AnyFramework> {
kind: string;
fileName: string;
stories: GetStorybookStory<TFramework>[];
}
- 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 46.
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
Identifier 'componentId' is never reassigned; use 'const' instead of 'let'. Open
let { id: componentId, title } = defaultExport || {};
- Read upRead up
- Exclude checks
Rule: prefer-const
Requires that variable declarations use const
instead of let
and var
if possible.
If a variable is only assigned to once when it is declared, it should be declared using 'const'
Notes
- Has Fix
Config
An optional object containing the property "destructuring" with two possible values:
- "any" (default) - If any variable in destructuring can be const, this rule warns for those variables.
- "all" - Only warns if all variables in destructuring can be const.
Examples
"prefer-const": true
"prefer-const": true,[object Object]
Schema
{
"type": "object",
"properties": {
"destructuring": {
"type": "string",
"enum": [
"all",
"any"
]
}
}
}
For more information see this page.
Type assertion on object literals is forbidden, use a type annotation instead. Open
}, {} as StoryIndex['stories']);
- Read upRead up
- Exclude checks
Rule: no-object-literal-type-assertion
Forbids an object literal to appear in a type assertion expression.
Casting to any
or to unknown
is still allowed.
Rationale
Always prefer const x: T = { ... };
to const x = { ... } as T;
.
The type assertion in the latter case is either unnecessary or hides an error.
The compiler will warn for excess properties with this syntax, but not missing required fields.
For example: const x: { foo: number } = {}
will fail to compile, but
const x = {} as { foo: number }
will succeed.
Additionally, the const assertion const x = { foo: 1 } as const
,
introduced in TypeScript 3.4, is considered beneficial and is ignored by this rule.
Notes
- TypeScript Only
Config
One option may be configured:
-
allow-arguments
allows type assertions to be used on object literals inside call expressions.
Examples
"no-object-literal-type-assertion": true
"no-object-literal-type-assertion": true,[object Object]
Schema
{
"type": "object",
"properties": {
"allow-arguments": {
"type": "boolean"
}
},
"additionalProperties": false
}
For more information see this page.