ajafff/tslint-consistent-codestyle

Collection of awesome rules to extend TSLint

tslint-consistent-codestyle's Issues

An in-range update of tsutils is breaking the build 🚨

Version 2.17.1 of tsutils was just published.

Branch	Build failing 🚨
Dependency	tsutils
Current Version	2.17.0
Type	dependency

This version is covered by your current version range and after updating it in your project the build failed.

tsutils is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details

• ❌ ci/circleci Your tests failed on CircleCI Details

---

Release Notes

v2.17.1

Bugfixes:

• getControlFlowEnd and endsControlFlow (#22)
  • ThrowStatements inside try are filtered out if there is a catch clause
  • TryStatements with catch only end control flow if try AND catch definitely end control flow

Commits

The new version differs by 2 commits.

• 6623960 v2.17.1
• 5253c45 getControlFlowEnd: fix handling of try statement

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

no-unused: exempt global augmentation

declare global { // should not produce an error
}

ext-curly: skip LabeledStatement

if (foo) { // shouldn't complain about braces here
  label: while (true) {
  }
}

Error when running rules recursively over directory

Using tslint 5.2.0 and tslint-consistency-codestyle 1.2.0 and the attached tslint.json file (which uses just the example "naming-convention" rule found here: https://www.npmjs.com/package/tslint-consistent-codestyle).

Running the following:
tslint -c tslint.json 'src/**/*.ts'

Generates this error:

Am I missing some arguments?

tslint.json.txt

new rule 'const-parameters'

Similar to tslint's no-parameter-reassignment, but allows users to declare which parameter should be considered const:

function fn(/**@const*/ foo, bar) {
    foo++; // error
    bar++; // no error
}

Recognise /**@const*/ and /**@constant*/

Ref: microsoft/TypeScript#18497

Improve docs

The docs could really use some love.

• rephrase stuff
• add code samples
• add config examples
• create a documentation page for each rule (instead of dumping everything in README)
• rewrite naming-convention docs

no rules seem to apply?

Please excuse if I've just done something silly...

I have the following tslint.json:

{
    "defaultSeverity": "error",
    "extends": "tslint:recommended",
    "naming-convention": [
        true,
        { "type": "default", "format": "camelCase", "leadingUnderscore": "forbid", "trailingUnderscore": "forbid" },
        { "type": "variable", "modifiers": ["global"], "format": "UPPER_CASE" },
        { "type": "variable", "modifiers": ["private", "protected" ], "format": "camelCase", "leadingUnderscore": "require", "trailingUnderscore": "forbid" },
        { "type": "parameter", "leadingUnderscore": "forbid", "trailingUnderscore": "forbid", "final": true },
        { "type": "member", "modifiers": ["private", "protected"], "leadingUnderscore": "require" },
        { "type": "type", "format": "PascalCase" },
        { "type": "interface", "prefix": "I" },
        { "type": "genericTypeParameter", "prefix": "T" },
        { "type": "enumMember", "format": "PascalCase" }
    ],
    "jsRules": {},
    "rules": {
        "no-console": false,
        "trailing-comma": false,
        "no-unused-expression": false,
        "no-empty": false,
        "ordered-imports": false,
        "one-variable-per-declaration": false,
        "no-consecutive-blank-lines": true,
        "no-bitwise": false
    },
    "rulesDirectory": [ "tslint-consistent-codestyle" ]
}

which I would expect should allow the following class declaration:

class Foo {
  private _field: number = 0;
  public get property(): number {
    return this._field;
  }
}

(in fact, this was the whole reason to install tslint-consistent-codestyle). Yet ./node_modules/.bin/tslint -p . fails when run in the project folder, complaining about _field (variable name must be in lowerCamelCase, PascalCase or UPPER_CASE)

I'd appreciate any pointers on what I'm doing wrong here (:

prefer-const-enums: why are exports ignored?

Enums that are exported or available in the global scope are ignored.

In https://github.com/ajafff/tslint-consistent-codestyle/blob/master/docs/prefer-const-enum.md, not sure why this restriction is in place?

no-unused: Allow rest parameters when destructuring object in function argument

Looking at the no-unused doc, I didn't expect to run into this warning. Using 1.5.0, the following is an example of where I see a warning.

"no-unused": [
  true,
  "ignore-parameters"
]

// [tslint] Variable 'props' is unused. (no-unused)
const UsersList: React.SFC<Props> = ({ users, ...props }) => {};

An option to always do early-return

I was wondering if you can add an option to always do early return. Thanks you.

no-var-before-return: allow-destructuring

May be we can have an option to allow destructuring before return?

const { data } = fetchSomething();

return data;

Something like this?

"no-var-before-return": [
  true,
  "allow-destructuring"
]

no-unused: add tests for ConditionalTypes introduced in [email protected]

BUG - no-unused doesn't recognize React imports for JSX

For a React import that needed only for JSX, no-unused throws an error ERROR: src/app.tsx[1, 13]: Import 'React' is unused.

import * as React from 'react';
import * as ReactDom from 'react-dom';

ReactDom.render(<App />, document.getElementById('root'));

As a temporary workaround, we can set ignore-imports to true.

An in-range update of tsutils is breaking the build 🚨

Version 2.27.0 of tsutils was just published.

Branch	Build failing 🚨
Dependency	tsutils
Current Version	2.26.2
Type	dependency

This version is covered by your current version range and after updating it in your project the build failed.

tsutils is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details

• ❌ ci/circleci Your tests failed on CircleCI Details

---

Release Notes

v2.27.0

Features:

• added getIIFE utility

Commits

The new version differs by 5 commits.

• 2c8e48b v2.27.0
• 139f75a add getIIFE utility
• 3fcc6d8 chore(package): update @types/node to version 10.0.3 (#58)
• 66c1b12 fix devDependency version
• a7034ba fix build with [email protected]

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

naming-convention: make property accessors configurable

As requested by @CSchulz, make getter and setter configurable for naming convention.

Ideally this could also include type information, so we could force "is" or "has" as prefix for boolean accessors.

naming-convention: don't flag inherited methods / accessors

When extending a class, namingConventionRule should not complain about the names of overridden or implemented abstract methods and accessors.

naming-convention: allow detecting unused variables / parameters

To suppress compiler warnings for unused parameters and locals, you prefix the name with an underscore.

Many users don't want to allow leading underscores in their variable names globally. Of course you can restrict that to parameters, but that will still allow a leading underscore for used parameters.

The rule should support restricting the leading underscore to only parameters that are really unused.
This could be achieved by either using the type checker or making use of the upcoming functionality in tsutils to track all uses of an identifier.

Naming convention should support exclusions

There are some fixed method names like toJSON which is automatically called by JSON.stringify, which don't follow the rules of CamelCase.

It would be nice to have the possibilty to define some exclusions for naming convention check.

build: build without source maps

Add new tsconfig.prod.json to build and publish without source maps.

prefer-const-enum: allow constants as initializer

Once typescript adds the ability to use literal typed constants as initializer in const enums, prefer-const-enum should try to handle this as well.

no-unused: option to add matcher to ignore

Just a suggestion... similar to no-unused-variable:

"no-unused": [true, {"ignore-pattern": "^_"}]

This allows you to use things like _ for array destructuring in parameters to skip no-unused for them.

no-unnecessary-type-annotation: false positive with array of tuples

let foo: Array<[string, boolean]> = [
  ['a', true],
  ['b', false],
];

An in-range update of tsutils is breaking the build 🚨

Version 2.20.0 of tsutils was just published.

Branch	Build failing 🚨
Dependency	tsutils
Current Version	2.19.1
Type	dependency

This version is covered by your current version range and after updating it in your project the build failed.

tsutils is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details

• ❌ ci/circleci Your tests failed on CircleCI Details

---

Commits

The new version differs by 4 commits.

• 4fe901d v2.20.0
• 7ae4088 Add isThenableType and unionTypeParts
• 7e6d301 Update to [email protected] (#27)
• 67cc64b chore(package): update mocha to version 5.0.0 (#26)

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

An in-range update of tslib is breaking the build 🚨

Version 1.9.1 of tslib was just published.

Branch	Build failing 🚨
Dependency	tslib
Current Version	1.9.0
Type	dependency

This version is covered by your current version range and after updating it in your project the build failed.

tslib is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details

• ❌ ci/circleci Your tests failed on CircleCI Details

---

Release Notes

tslib 1.9.1

Updates __asyncValues to more correctly align with CreateAsyncFromSyncIterator, and updates __asyncDelegator to ensure throw is correctly propagated.

Commits

The new version differs by 2 commits.

• 2c3d5d6 Update version number to '1.9.1'.
• 008541b Fix async generator rejection handling (#51)

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

Filter doesn't seem to be working for parameterProperty type in 1.13.0

Firstly, this ruleset is fantastic and highly configurable, thanks so much for sharing it.

I think I may have found a small issue with the filter in 1.13.0. I can't be sure as I dont know how to check but I think it may be an issue with parsing the string into a regex. But maybe what I am trying to do isnt possible

Steps to reproduce

I have this simple 2D Point class with public properties for the x,y coordinates initialized by a constructor param property:

export class Point implements IPoint {
    constructor(public x: number = 0, public y: number = 0, public Selected: boolean = false) {}
}

I have configured tslint-consistent-codestyle to enforce PascalCase as default, but I want to make an exception to this rule for the properties x and y to enforce camelCase using the filter option.

So in the example above, the Selected property should be PascalCase while x and y should be fine to be camelCase.

My ruleset looks like this:

"naming-convention": [
            true,
            {"type": "default", "format": "PascalCase", "leadingUnderscore": "forbid", "trailingUnderscore": "forbid"},
            {"type": "parameter", "format": "camelCase"},
            {"type": "variable", "format": "camelCase"},
            {"type": "property", "format": "camelCase"},
            {"type": "property", "modifiers": ["public"], "format": "PascalCase"},
            {"type": "parameterProperty", "filter": "^x$", "format": "camelCase"}
]

The last rule {"type": "parameterProperty", "filter": "^x$", "format": "camelCase"} doesn't seem to be having any effect (i.e. Im still getting a tslint problem match for x and y), and in fact I cant seem to get the filter to work for anything including the examples in the docs, is this just me or is the filter not working?

"no-curly" rule ?

I noticed a "no-curly" rule in tslint-consistent-codestyle 1.2.0 module installed from npm which does not exist on this repository :

Could not find `naming-convention` rule after configuration.

I have this output during tslint.

Could not find implementations for the following rules specified in the configuration:
    naming-covention
Try upgrading TSLint and/or ensuring that you have all necessary custom rules installed.
If TSLint was recently upgraded, you may have old rules configured which need to be cleaned up.

In my package.json:

"tslint": "^4.5.1",
"tslint-consistent-codestyle": "^0.2.2",

In tslint.json

{
  "extends": "tslint:recommended",
  "rulesDirectory": [
    "node_modules/tslint-consistent-codestyle/rules"
  ],
  "rules": {
    "naming-convention": [
      true,
      { "type": "member", "format": "camelCase" },
      { "type": "member", "modifiers": "protected", "leadingUnderscore": "require" },
      { "type": "member", "modifiers": "private", "prefix": "__" }
    ],
    ....
}

An in-range update of tsutils is breaking the build 🚨

☝️ Greenkeeper’s updated Terms of Service will come into effect on April 6th, 2018.

Version 2.22.1 of tsutils was just published.

Branch	Build failing 🚨
Dependency	tsutils
Current Version	2.22.0
Type	dependency

This version is covered by your current version range and after updating it in your project the build failed.

tsutils is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details

• ❌ ci/circleci Your tests failed on CircleCI Details

---

Release Notes

v2.22.1

Bugfixes:

• endsControlFlow:
  • handle loops that might not even run a single iteration
  • handle constant boolean conditions in loops and if

Commits

The new version differs by 3 commits.

• fda575a v2.22.1
• b39884f add tests for control flow analysis
• 685fa1d control-flow: IterationStatement body is not guraranteed to be executed

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

Support [email protected]

naming-convention: treat variables initialized with an arrow function as functions

Here's my naming-convention configuration:

"rules": {
    "naming-convention": [ true,
      { "type": "default", "format": "camelCase" },
      { "type": "variable", "modifiers": "export", "format": "UPPER_CASE" },
      { "type": "function", "modifiers": "export", "format": "camelCase" }
    ]
}

As you can see from this, I want exported variables to be upper case, but exported functions to be camel case.

Here's some typical code that I'd write (it's ngrx-style code):

export const ACTION = "submit";
export const getValue = (state: State) => state.value;

This fails linting because getValue is expected to be upper case, but I'd prefer it to be camel case. I could write it like this:

export function getValue(state: State): boolean { return state.value; }

But it's a bit more verbose and (because of other linting rules I use) requires the function to have a type annotation.

Would it be possible to treat variables that are initialized with an arrow function to be treated as functions instead of variables?

I've taken a look at the rule, and it's simple enough to check if a variable is initialized to an arrow function:

if (declaration.initializer && declaration.initializer.kind === ts.SyntaxKind.ArrowFunction) {
    this._checkName(declaration.name, TypeSelector.function, currentModifiers);
} else {
    this._checkName(declaration.name, TypeSelector.variable, currentModifiers);
}

But I'm wondering if maybe it should be an option to make it behave this way so that it doesn't break everyone else's existing configurations.

no-var-before-return: false positive

var foo = {
   fn() {console.log(foo);}
};
return foo;

Bug: `no-else-after-return` does not allow `else if`'s by default like ESLint's `no-else-return` does

Issue type

Bug

Version

v1.10.0

Overview

The no-else-after-return rule seems to, by default, be issuing warnings when else if's are used after return statements.

The documentation for no-else-after-return states that it "Works like no-else-return from eslint", and (at least for the current version of ESLint) the default behaviour of no-else-return allows return statements after else if's.

Current behaviour

When no-else-after-return: true is specified, the following code causes an unnecessary else after return warning to appear for me:

const val = Math.random();

if (val > 0.5) {
  return 1;
} else if (val < 0.5) {
  return -1;
}

return 0;

Expected behaviour

When no-else-after-return: true is specified, the above code should not issue a warning.

If no-else-after-return: [true, { "allowElseIf": false }] was specified, then the above code should issue a warning.

Additional context

I use this rule as part of tslint-config-airbnb, which added no-else-after-return to their ruleset in v5.4.1.

Make no-collapsible-if configurable

Possible options:

• "no-or" to exempt if statements that have a logical OR in their condition
• "complexity": number threshold similar to cyclomatic-complexity

function isExcluded in noUnusedRule.ts: invalid condition

File: ../blob/master/rules/noUnusedRule.ts

172    switch (parent.kind) {
180    case ts.SyntaxKind.BindingElement:
184        if (pattern.kind === ts.SyntaxKind.ObjectBindingPattern &&

The condition in line 184 never true.

Example:

    @Effect()effect  onSetStep = this.action$
        .ofType<SwitchAction>(SwitchAction.TYPE)
        .withLatestFrom(this.stepbarService.stepbar$)
        .map(([_action, stepbar]) => { // the _action-Variable is correctly prefixed but marked by the lint
            return new Action(stepbar.item);
        });

Error in dependencies tsutils

Hi,

We have an error when we install tslint-consistent-codestyle v1.7. The dependency tsutils 2.11.0 doesn't exist.

Can you patch your package.json ?

naming-convention: allow multiple formats

Allow an array of formats to be specified. They are not merged when extending but overridden.

no-var-before-return: add fixer

Should be easy to implement.

Some things to consider:

function f() {
    var a = foo(), b = bar(a, a);
    return b;
}

function f() {
    var a = foo();
    return bar(a, a);
}

function f() {
    var a: {} = "foo"; // move annotation to funtion signature, iff this is the only return
    return a;
}

function f(): {} {
    return "foo";
}

naming-convention: constructorVariable

What do you think of adding a new selector to the naming-convention rule which applies to variables that are containing a construct signature?

With the current selectors I cannot target my redux connected components which has to be written in PascalCase, while keeping non-class containing variables in camelCase.

Current behaviour

Config:

{"type": "variable", "format": ["camelCase"]}

Code:

// connect returns a react component class
const PascalCaseComponent1 = connect(..)(SomeComponent);
const camelCaseComponent2 = connect(..)(SomeComponent);

Result:

PascalCaseComponent1: variable name must be in camelCase

Desired behaviour

Config:

{"type": "variable", "format": ["camelCase"]}
{"type": "constructorVariable", "format": ["PascalCase"]}

Code:

// connect returns a react component class
const PascalCaseComponent1 = connect(..)(SomeComponent);
const camelCaseComponent2 = connect(..)(SomeComponent);

Result:

camelCaseComponent2: variable name must be in PascalCase

no-unused: callback arguments

Question for you (maybe a bug?) regarding no-unused and callback args. If I need to use a callback arg which is somewhere towards the right side of the list of args, but I don't need to use some of the preceding args, should that be an error?

Here's a screenshot of some code I'm working with, using rewriters in winston 2.x.

I don't think I can use placeholders to ignore elements like we could with array destructuring.

no-unused: add option to ignore siblings of object rest

Ref: palantir/tslint#3800

naming-convention: Exempt this parameter of functions

turn off interface must start with I

how can i turn off this rule below ?

      // interface names must start with "I". The following part of the name must be valid PascalCase
      {
        "type": "interfaceq",
        "prefix": "I",
      },

new rule no-unnecessary-variable

You can suppress compiler warnings for unused parameters by prefixing the name with an underscore. tslint allows the same for variables.

But variables are only necessary to keep around when they are used in an object destructuring containing rest. Parameters only need to be specified when they are followed by at least one actually used parameter.

Add a new rule that warns for all identifiers that are not strictly necessary even if they are allowed to exist because of some prefix.

naming-convention camelCase for variables vs real world

Hello,

first of all - thanks for great linter.

I have such variables in my code:
articleID,
addUIPart,
isCKELoaded

and so on,
I would like to keep this rule on but with some excludes, is it possible?

same with methods

An in-range update of tslib is breaking the build 🚨

Version 1.9.0 of tslib was just published.

Branch	Build failing 🚨
Dependency	tslib
Current Version	1.8.1
Type	dependency

This version is covered by your current version range and after updating it in your project the build failed.

tslib is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details

• ❌ ci/circleci Your tests failed on CircleCI Details

---

Release Notes

tslib 1.9.0

This release introduces import helpers that are utilized by TypeScript 2.7's --esModuleInterop flag for interoperability between ECMAScript modules and legacy module formats.

Commits

The new version differs by 4 commits.

• 3d0f4d4 Update version to '1.9.0'.
• c380b8d Merge pull request #43 from Microsoft/import-helpers
• c1cd8e1 Remove erroneous semicolons from import star helper
• b630cee Add import helpers

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

no-unused does not check class members in general?

From the documentation page of the "no-unused" rule, it says:

Does not check private class members.

But considering this snippet:

export class Test {
  private aaaa = 'c';
  bbbb: string;
  public cccc: string;

  constructor(private dddd, public eeee) { }
}

it does not mark any of the members as unused.
Is this intentional or a bug?
If intentional, is this planned as an extension or is there a specific reason to stay with it?

no-unnecessary-type-annotation – infinite loop

Sorry in advance for what might be an unhelpful report. I somehow wrote some code that causes the no-unnecessary-type-annotation rule to get stuck in an infinite loop inside removeSignatureReturn. It is getting passed the string '<A extends Action>(action: A): A', which appears to come from the redux type definitions. The function seems to assume the first char will be (, but in my case it is <. Fixing that localized issue is easy, but I have no idea what broader conditions caused that to happen, or how you'd write a test for it.

no-unnecessary-type-annotation: detect other IIFE style

(function (param: string) {}(''));
// is equal to
(function (param: string) {})('');

Both expressions should be recognized as IFFE, therefore the parameter type annotation is unnecessary.
Currently only one (the latter?) is correctly detected.

no-unused: error on unused catch binding

[email protected] allows omitting the catch binding. Therefore no-unused should no longer treat this kind of declaration special (when using ts@>=2.5.0). If it's unused, you can just remove it.

Also add a flag to restore the old behavior and ignore catch bindings completely.

early-exit: add option for disabling in constructors

To me, it feels unconventional to use return in a constructor and it can potentially override the object reference if a non-primitive type is returned. I like the early-exit rule, but would love be able to enable an option that would disable the rule inside all constructors.