November 2017 (version 1.8.0-beta)

1.8.0 Update

Time flies! It's already time for 9th release.

We've released a 1.8.0 DeepScan service bringing with new rules (100+ at last!) and stability improvements.

Keep reading for the highlights for this release.

Release Summary

This version includes a number of updates that we hope you will enjoy. The key highlights are:

• New rules - New rules for common pitfalls and React.
• Analysis improvements - Enhanced analysis for typeof comparison
• About security - Effort to be more secure.
• About the pull request check - Changes in the pull request check.

New Rules

Rules for common pitfalls

The following new rules check common pitfalls.

• ARROW_FUNC_RETURN_OBJECT_MISSING - Check whether the object literal is returned properly
• BAD_CONDITIONAL_OPERATOR - Do not use a conditional operator in vague order
• BAD_FINALLY_CONTROL_FLOW - Do not overwrite return or throw statement in the finally block
• BAD_STRING_CASE_COMPARISON - Do not compare the result of toLowerCase() or toUpperCase() with a incompatible case string
• REDUNDANT_COMPOUND_ASSIGN - Do not use compound assign with the same variable as LHS
• UNUSED_LABEL - Remove unused labels

More React rules

The following new rules check React runtime errors or warnings. Check out here for full React specific rules.

• REACT_BAD_DOM_ATTRIBUTE_VALUE - Do not set a value of the wrong type to the React DOM element's attribute
• REACT_INEFFICIENT_PURE_COMPONENT_PROP - Avoid newly created object as React.PureComponent prop
• REACT_MISUSED_CONTROLLED_COMPONENT - Do not use a Form element as both controlled and uncontrolled one

Analysis Improvements

More precise typeof treatment

We have improved precision on handling typeof comparison by considering all possible values of the compared variable.

For example, we now detect a CONSTANT_CONDITION alarm in the following code because the condition at line 10 is always false because config is either null or non-function value by the condition at line 3:

Y.Node.prototype.hide = function(name, config, callback) {
    if (name && Y.Transition) {
        if (typeof config === 'function') {
            callback = config;
            config = null;
        }

        callback = _wrapCallBack(this, this._hide, callback);
        if (typeof name !== 'string' && !name.push) {
            if (typeof config === 'function') { // This condition is always false because 'config' is either 'null' or non-function value at this point.
                callback = config;
                config = name;
            }
            name = Transition.HIDE_TRANSITION;
        }
        this.transition(name, config, callback);
    } else if (name && !Y.Transition) { Y.log('unable to transition hide; missing transition module', 'warn', 'node');
    } else {
        this._hide();
    }
    return this;
};

Alarm filtering on explanatory code

Sometimes, developers check the opposite condition in the else branch of a condition. It is of course unnecessary and thus we detected CONSTANT_CONDITION alarms.

However, the purpose is quite likely to clarify code logic and now we filter-out those alarms to reduce the noise as much as possible.

Let's take an example. !opts.longStackTraces at line 6 is always false but we now filter-out it:

Promise.config = function(opts) {
    opts = Object(opts);
    if ("longStackTraces" in opts) {
        if (opts.longStackTraces) {
            Promise.longStackTraces();
        } else if (!opts.longStackTraces && Promise.hasLongStackTraces()) { // Filter-out alarm on '!opts.longStackTraces'.
            disableLongStackTraces();
        }
    }
}

About Security

We try to keep our mind on the security, especially for user code.

We have updated our documentation for it and worked hard to be more secure. As such an effort to improve security, we changed the way we show a file content in Files view. By fetching a file directly from GitHub, we do not need copies of stored code for viewing the file.

In the longer run, we will completely not require to store a file in our server.

About the Pull Request Check

We are having some trouble in handling the pull requests of organization repositories.

While we are improving it, but in the interim, we will change the pull request check in soft manner. This means the check will be marked as successful even when unresolved issues exist.

Miscellaneous

• In Repositories view, you can filter your results based on the repository name and description.

  

• A webhook added on your GitHub repository is deleted when you delete the DeepScan project.
• In Account Settings > Notifications, you can configure whether you want to receive an announcement email or not.
• Apply ESC key to close modal dialogs.

Bug Fixes

• Disable directives might not work in TypeScript code.
• Analysis for CONSTANT_CONDITION may fail by negation operators inside if condition.
• Analysis fails when a code fragment exceeds some limit.
• Automatic analysis fails when the branch includes a slash in its name.
• When you change a status of an issue, a popup for comment might not display properly.

Thank You

Thank you to the following folks that gave a big help to make DeepScan better:

• Eric Amodio: A false alarm for CONSTANT_CONDITION can occur for object property values after doing await