fbredius/storybook

View on GitHub
lib/core-server/src/utils/StoryIndexGenerator.ts

Summary

Maintainability
A
1 hr
Test Coverage

Function getIndex has 30 lines of code (exceeds 25 allowed). Consider refactoring.
Open

  async getIndex() {
    if (this.lastIndex) return this.lastIndex;

    // Extract any entries that are currently missing
    // Pull out each file's stories into a list of stories, to be composed and sorted
Severity: Minor
Found in lib/core-server/src/utils/StoryIndexGenerator.ts - About 1 hr to fix

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

            const pathToSubIndex = {} as SpecifierStoriesCache;

    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

        const fileStories = {} as StoryIndex['stories'];

    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<StoryId, V2CompatIndexEntry>);

    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<ComponentTitle, number>);

    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 StoryIndex['stories']);

    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