fbredius/storybook

View on GitHub
lib/store/src/StoryStore.ts

Summary

Maintainability
A
2 hrs
Test Coverage

File StoryStore.ts has 253 lines of code (exceeds 250 allowed). Consider refactoring.
Open

import memoize from 'memoizerific';
import {
  Parameters,
  StoryId,
  StoryContextForLoaders,
Severity: Minor
Found in lib/store/src/StoryStore.ts - About 2 hrs to fix

    Unnecessary semicolon
    Open

      };
    Severity: Minor
    Found in lib/store/src/StoryStore.ts by tslint

    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.

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

            const context = {
              ...this.getStoryContext(story),
              viewMode: 'story',
            } as StoryContext<TFramework>;
    Severity: Minor
    Found in lib/store/src/StoryStore.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 Parameters
    Severity: Minor
    Found in lib/store/src/StoryStore.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.

    'Object.assign' returns the first argument. Prefer object spread if you want a new object.
    Open

                return Object.assign(storyAcc, { [key]: value.slice().sort() });
    Severity: Minor
    Found in lib/store/src/StoryStore.ts by tslint

    Rule: prefer-object-spread

    Enforces the use of the ES2018 object spread operator over Object.assign() where appropriate.

    Rationale

    Object spread allows for better type checking and inference.

    Notes
    • Has Fix

    Config

    Not configurable.

    Examples
    "prefer-object-spread": true

    For more information see this page.

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

          }, {} as Record<Path, CSFFile<TFramework>>)
    Severity: Minor
    Found in lib/store/src/StoryStore.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 Record<string, any>);
    Severity: Minor
    Found in lib/store/src/StoryStore.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.

    'Object.assign' returns the first argument. Prefer object spread if you want a new object.
    Open

              return Object.assign(storyAcc, { [key]: value });
    Severity: Minor
    Found in lib/store/src/StoryStore.ts by tslint

    Rule: prefer-object-spread

    Enforces the use of the ES2018 object spread operator over Object.assign() where appropriate.

    Rationale

    Object spread allows for better type checking and inference.

    Notes
    • Has Fix

    Config

    Not configurable.

    Examples
    "prefer-object-spread": true

    For more information see this page.

    There are no issues that match your filters.

    Category
    Status