gund/ngx-router-meta

View on GitHub

Showing 10 of 10 total issues

Similar blocks of code found in 2 locations. Consider refactoring.
Open

  provideContext(ctx: MetaContext | Observable<MetaContext>) {
    this.metaContext$$.next(isObservable(ctx) ? ctx : of(ctx));
  }
projects/ngx-router-meta/src/lib/router-meta-context.service.ts on lines 98..100

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 59.

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

Further Reading

Similar blocks of code found in 2 locations. Consider refactoring.
Open

  provideDefaultContext(ctx: MetaContext | Observable<MetaContext>) {
    this.metaDefaultContext$$.next(isObservable(ctx) ? ctx : of(ctx));
  }
projects/ngx-router-meta/src/lib/router-meta-context.service.ts on lines 110..112

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 59.

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

Further Reading

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

  private updateAllMeta(data: Data, ctx: ProcessedMetaContext = {}) {
    const { _templates_: defaultTemplates, ...defaultAllMeta } =
      this.defaultMeta;

    if (!isDataWithMeta(data)) {
Severity: Minor
Found in projects/ngx-router-meta/src/lib/router-meta.service.ts - About 1 hr to fix

    Function _templateStr has a Cognitive Complexity of 10 (exceeds 5 allowed). Consider refactoring.
    Open

      _templateStr(
        str?: string,
        data?: ProcessedMetaContext,
        extras?: {
          name?: string;
    Severity: Minor
    Found in projects/ngx-router-meta/src/lib/router-meta-context.service.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

    marked Regular Expression Denial of Service
    Open

        "marked": {
          "version": "4.0.17",
          "resolved": "https://registry.npmjs.org/marked/-/marked-4.0.17.tgz",
          "integrity": "sha512-Wfk0ATOK5iPxM4ptrORkFemqroz0ZDxp5MWfYA7H/F+wO17NRWV5Ypxi6p3g2Xmw2bKeiYOl6oVnLHKxBA0VhA==",
          "dev": true
    Severity: Minor
    Found in package-lock.json by nodesecurity

    Regular Expression Denial of Service

    Overview:

    The marked module is vulnerable to a regular expression denial of service. Based on the information published in the public issue, 1k characters can block for around 6 seconds.

    Recommendation:

    Consider another markdown parser until the issue can be addressed.

    Array type using 'Array<t>' is forbidden. Use 'T[]' instead.</t>
    Open

    export type InferArray<A> = A extends Array<infer T> ? T : never;

    Rule: array-type

    Requires using either 'T[]' or 'Array<t>' for arrays.</t>

    Notes
    • TypeScript Only
    • Has Fix

    Config

    One of the following arguments must be provided:

    • "array" enforces use of T[] for all types T.
    • "generic" enforces use of Array<T> for all types T.
    • "array-simple" enforces use of T[] if T is a simple type (primitive or type reference).
    Examples
    "array-type": true,array
    "array-type": true,generic
    "array-type": true,array-simple
    Schema
    {
      "type": "string",
      "enum": [
        "array",
        "generic",
        "array-simple"
      ]
    }

    For more information see this page.

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

              startWith({} as R),

    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 templates = {
          ...defaultTemplates,
          ..._templates_,
        } as RouteMetaTemplates;

    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 ProcessedMetaContext);

    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 ProcessedMetaContext,

    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.

    Severity
    Category
    Status
    Source
    Language