MarshallOfSound/Google-Play-Music-Desktop-Player-UNOFFICIAL-

View on GitHub
src/main/features/core/websocketAPI.js

Summary

Maintainability
C
1 day
Test Coverage

Function handleWSMessage has a Cognitive Complexity of 32 (exceeds 5 allowed). Consider refactoring.
Open

const handleWSMessage = (ws) =>
  (data) => {
    try {
      const command = JSON.parse(data);
      if (command.type === 'disconnect') {
Severity: Minor
Found in src/main/features/core/websocketAPI.js - About 4 hrs 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

File websocketAPI.js has 287 lines of code (exceeds 250 allowed). Consider refactoring.
Open

import { app } from 'electron';
import fs from 'fs';
import os from 'os';
import path from 'path';
import uuid from 'uuid';
Severity: Minor
Found in src/main/features/core/websocketAPI.js - About 2 hrs to fix

    Function enableAPI has 61 lines of code (exceeds 25 allowed). Consider refactoring.
    Open

    const enableAPI = () => {
      let portOpen = true;
      if (process.platform === 'win32') {
        const testResult = spawnSync(
          'netsh',
    Severity: Major
    Found in src/main/features/core/websocketAPI.js - About 2 hrs to fix

      Function handleWSMessage has 56 lines of code (exceeds 25 allowed). Consider refactoring.
      Open

        (data) => {
          try {
            const command = JSON.parse(data);
            if (command.type === 'disconnect') {
              connectClientShouldReconnect = false;
      Severity: Major
      Found in src/main/features/core/websocketAPI.js - About 2 hrs to fix

        Unexpected console statement.
        Open

              console.log(err);

        disallow the use of console (no-console)

        In JavaScript that is designed to be executed in the browser, it's considered a best practice to avoid using methods on console. Such messages are considered to be for debugging purposes and therefore not suitable to ship to the client. In general, calls using console should be stripped before being pushed to production.

        console.log("Made it here.");
        console.error("That shouldn't have happened.");

        Rule Details

        This rule disallows calls to methods of the console object.

        Examples of incorrect code for this rule:

        /*eslint no-console: "error"*/
        
        console.log("Log a debug level message.");
        console.warn("Log a warn level message.");
        console.error("Log an error level message.");

        Examples of correct code for this rule:

        /*eslint no-console: "error"*/
        
        // custom console
        Console.log("Hello world!");

        Options

        This rule has an object option for exceptions:

        • "allow" has an array of strings which are allowed methods of the console object

        Examples of additional correct code for this rule with a sample { "allow": ["warn", "error"] } option:

        /*eslint no-console: ["error", { allow: ["warn", "error"] }] */
        
        console.warn("Log a warn level message.");
        console.error("Log an error level message.");

        When Not To Use It

        If you're using Node.js, however, console is used to output information to the user and so is not strictly used for debugging purposes. If you are developing for Node.js then you most likely do not want this rule enabled.

        Related Rules

        Unexpected parentheses around single function argument having a body with no curly braces
        Open

        const handleWSMessage = (ws) =>

        Require parens in arrow function arguments (arrow-parens)

        Arrow functions can omit parentheses when they have exactly one parameter. In all other cases the parameter(s) must be wrapped in parentheses. This rule enforces the consistent use of parentheses in arrow functions.

        Rule Details

        This rule enforces parentheses around arrow function parameters regardless of arity. For example:

        /*eslint-env es6*/
        
        // Bad
        a => {}
        
        // Good
        (a) => {}

        Following this style will help you find arrow functions (=>) which may be mistakenly included in a condition when a comparison such as >= was the intent.

        /*eslint-env es6*/
        
        // Bad
        if (a => 2) {
        }
        
        // Good
        if (a >= 2) {
        }

        The rule can also be configured to discourage the use of parens when they are not required:

        /*eslint-env es6*/
        
        // Bad
        (a) => {}
        
        // Good
        a => {}

        Options

        This rule has a string option and an object one.

        String options are:

        • "always" (default) requires parens around arguments in all cases.
        • "as-needed" allows omitting parens when there is only one argument.

        Object properties for variants of the "as-needed" option:

        • "requireForBlockBody": true modifies the as-needed rule in order to require parens if the function body is in an instructions block (surrounded by braces).

        always

        Examples of incorrect code for this rule with the default "always" option:

        /*eslint arrow-parens: ["error", "always"]*/
        /*eslint-env es6*/
        
        a => {};
        a => a;
        a => {'\n'};
        a.then(foo => {});
        a.then(foo => a);
        a(foo => { if (true) {} });

        Examples of correct code for this rule with the default "always" option:

        /*eslint arrow-parens: ["error", "always"]*/
        /*eslint-env es6*/
        
        () => {};
        (a) => {};
        (a) => a;
        (a) => {'\n'}
        a.then((foo) => {});
        a.then((foo) => { if (true) {} });

        If Statements

        One of benefits of this option is that it prevents the incorrect use of arrow functions in conditionals:

        /*eslint-env es6*/
        
        var a = 1;
        var b = 2;
        // ...
        if (a => b) {
         console.log('bigger');
        } else {
         console.log('smaller');
        }
        // outputs 'bigger', not smaller as expected

        The contents of the if statement is an arrow function, not a comparison.

        If the arrow function is intentional, it should be wrapped in parens to remove ambiguity.

        /*eslint-env es6*/
        
        var a = 1;
        var b = 0;
        // ...
        if ((a) => b) {
         console.log('truthy value returned');
        } else {
         console.log('falsey value returned');
        }
        // outputs 'truthy value returned'

        The following is another example of this behavior:

        /*eslint-env es6*/
        
        var a = 1, b = 2, c = 3, d = 4;
        var f = a => b ? c: d;
        // f = ?

        f is an arrow function which takes a as an argument and returns the result of b ? c: d.

        This should be rewritten like so:

        /*eslint-env es6*/
        
        var a = 1, b = 2, c = 3, d = 4;
        var f = (a) => b ? c: d;

        as-needed

        Examples of incorrect code for this rule with the "as-needed" option:

        /*eslint arrow-parens: ["error", "as-needed"]*/
        /*eslint-env es6*/
        
        (a) => {};
        (a) => a;
        (a) => {'\n'};
        a.then((foo) => {});
        a.then((foo) => a);
        a((foo) => { if (true) {} });

        Examples of correct code for this rule with the "as-needed" option:

        /*eslint arrow-parens: ["error", "as-needed"]*/
        /*eslint-env es6*/
        
        () => {};
        a => {};
        a => a;
        a => {'\n'};
        a.then(foo => {});
        a.then(foo => { if (true) {} });
        (a, b, c) => a;
        (a = 10) => a;
        ([a, b]) => a;
        ({a, b}) => a;

        requireForBlockBody

        Examples of incorrect code for the { "requireForBlockBody": true } option:

        /*eslint arrow-parens: [2, "as-needed", { "requireForBlockBody": true }]*/
        /*eslint-env es6*/
        
        (a) => a;
        a => {};
        a => {'\n'};
        a.map((x) => x * x);
        a.map(x => {
          return x * x;
        });
        a.then(foo => {});

        Examples of correct code for the { "requireForBlockBody": true } option:

        /*eslint arrow-parens: [2, "as-needed", { "requireForBlockBody": true }]*/
        /*eslint-env es6*/
        
        (a) => {};
        (a) => {'\n'};
        a => ({});
        () => {};
        a => a;
        a.then((foo) => {});
        a.then((foo) => { if (true) {} });
        a((foo) => { if (true) {} });
        (a, b, c) => a;
        (a = 10) => a;
        ([a, b]) => a;
        ({a, b}) => a;

        Further Reading

        There are no issues that match your filters.

        Category
        Status