Sign upLogin

fbredius/storybook

View on GitHub
Star
lib/store/src/csf/prepareStory.ts

Summary

Maintainability
B
6 hrs
Test Coverage

Function prepareStory has 122 lines of code (exceeds 25 allowed). Consider refactoring.
Open

export function prepareStory<TFramework extends AnyFramework>(
  storyAnnotations: NormalizedStoryAnnotations<TFramework>,
  componentAnnotations: NormalizedComponentAnnotations<TFramework>,
  projectAnnotations: NormalizedProjectAnnotations<TFramework>
): Story<TFramework> {
Severity: Major
Found in lib/store/src/csf/prepareStory.ts - About 4 hrs to fix

    Function prepareStory has a Cognitive Complexity of 13 (exceeds 5 allowed). Consider refactoring.
    Open

    export function prepareStory<TFramework extends AnyFramework>(
  storyAnnotations: NormalizedStoryAnnotations<TFramework>,
  componentAnnotations: NormalizedComponentAnnotations<TFramework>,
  projectAnnotations: NormalizedProjectAnnotations<TFramework>
): Story<TFramework> {
    Severity: Minor
    Found in lib/store/src/csf/prepareStory.ts - About 1 hr to fix

    Cognitive Complexity

    Cognitive Complexity is a measure of how difficult a unit of code is to intuitively understand. Unlike Cyclomatic Complexity, which determines how difficult your code will be to test, Cognitive Complexity tells you how difficult your code will be to read and comprehend.

    A method's cognitive complexity is based on a few simple rules:

    • Code is not considered more complex when it uses shorthand that the language provides for collapsing multiple statements into one
    • Code is considered more complex for each "break in the linear flow of the code"
    • Code is considered more complex when "flow breaking structures are nested"

    Further reading

    block is empty
    Open

      () => {},
    Severity: Minor
    Found in lib/store/src/csf/prepareStory.ts by tslint

    Rule: no-empty

    Disallows empty blocks.

    Blocks with a comment inside are not considered empty.

    Rationale

    Empty blocks are often indicators of missing code.

    Config

    If allow-empty-catch is specified, then catch blocks are allowed to be empty. If allow-empty-functions is specified, then function definitions are allowed to be empty.

    Examples
    "no-empty": true
    "no-empty": true,allow-empty-catch
    "no-empty": true,allow-empty-functions
    "no-empty": true,allow-empty-catch,allow-empty-functions
    Schema
    {
  "type": "array",
  "items": {
    "anyOf": [
      {
        "type": "string",
        "enum": [
          "allow-empty-catch"
        ]
      },
      {
        "type": "string",
        "enum": [
          "allow-empty-functions"
        ]
      }
    ]
  }
}

    For more information see this page.

    Type assertion on object literals is forbidden, use a type annotation instead.
    Open

      const passedArgs: Args = {
    ...projectAnnotations.args,
    ...componentAnnotations.args,
    ...storyAnnotations.args,
  } as Args;
    Severity: Minor
    Found in lib/store/src/csf/prepareStory.ts by tslint

    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.

    Type assertion on object literals is forbidden, use a type annotation instead.
    Open

        }, {} as Args);
    Severity: Minor
    Found in lib/store/src/csf/prepareStory.ts by tslint

    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.

    There are no issues that match your filters.

    Category
    Status