Sign upLogin

fbredius/storybook

View on GitHub
Star
app/angular/src/server/framework-preset-angular-cli.ts

Summary

Maintainability
A
3 hrs
Test Coverage

Function webpackFinal has 51 lines of code (exceeds 25 allowed). Consider refactoring.
Open

export async function webpackFinal(baseConfig: webpack.Configuration, options: PresetOptions) {
  if (!moduleIsAvailable('@angular-devkit/build-angular')) {
    logger.info('=> Using base config because "@angular-devkit/build-angular" is not installed');
    return baseConfig;
  }
Severity: Major
Found in app/angular/src/server/framework-preset-angular-cli.ts - About 2 hrs to fix

    Function getLegacyDefaultBuildOptions has 40 lines of code (exceeds 25 allowed). Consider refactoring.
    Open

    async function getLegacyDefaultBuildOptions(options: PresetOptions) {
  if (options.angularBrowserTarget !== undefined) {
    // Not use legacy way with builder (`angularBrowserTarget` is defined or null with builder and undefined without)
    return {};
  }
    Severity: Minor
    Found in app/angular/src/server/framework-preset-angular-cli.ts - About 1 hr to fix

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

          const browserTarget = {
      configuration: undefined,
      project: getDefaultProjectName(workspaceConfig),
      target: 'build',
    } as Target;
      Severity: Minor
      Found in app/angular/src/server/framework-preset-angular-cli.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