buzinas / tslint-eslint-rules Goto Github PK

The following causes a linting error when no-ex-assign is set to true (line 4, column 12):

class MyClass {}

interface IMyInterface {
    myVar: MyClass;
}

The following causes a linting error if no-constant-condition is true:

if (!myVar) {
}

Removing the negation removes the linting error:

if (myVar) {
}

Find the first recommended ESLint rule that is missing in TSLint.

We should have a CHANGELOG.md file to add all the release notes.

Also, we should have some commit conventions for better readability of our change history.

We must create a Github release everytime I release a new npm package.

error (no-ex-assign) bootstrap.ts[34, 22]: invalid typeof comparison value

The line in question:

export function bootstrapComponents(): void {
    "use strict";

    bootstrap((aurelia: Aurelia) => { // this is line 34
        aurelia.use
            .defaultBindingLanguage()
            .defaultResources()
            .developmentLogging();

        aurelia.start().then(()  => aurelia.enhance({}, document.body));
    });
}

For one, the rule shouldn't apply here. Also, the error message doesn't match the rule description.

In #1 we've checked all the recommended ESLint rules, now it's time to check all the others.

According to palantir/tslint#790, we can safely upgrade our dependency to the next TSLint stable version.

The README seems like it could use a little bit of updating in that regard. An example is ESLint's strict is use-strict in TSLint. Glancing through the rules, there's about 6 or so of these.

We must lint our project, so we have a well-defined style-guide.

• Create tslint.json file
• Configure all the rules we'll be using (including our owns)
• Create a build step for linting in Gulp
• Test if everything is working OK
• Fix all the linting errors

We're gonna need this for our projects, and tslint can also benefits from this (palantir/tslint#1044).

We must improve our tests in a way to see how many TSLint failures we have.

1- improve README to handle all the ESLint recommended rules
2- create missing issues for all the recommended rules

We must have the ability to debug Mocha right inside VSCode, so it's easier to catch why testings are failing.

Also, we should improve our build process to include sourcemaps, so we'll be able to debug our TypeScript source, instead of the transpiled Javascript code.

Update README according to the Atom's linter-tslint new version.

My pull request (AtomLinter/linter-tslint#37) was merged.

Based on the rule/option http://eslint.org/docs/rules/no-redeclare

{
  "no-redeclare": [
    2,
    {
      "builtinGlobals": true
    }
  ]
}

I believe the no-ex-assign rule has the wrong failure string: Incorrect string

The following triggers a linting error when the no-unexpected-multiline rule is true:

var a, b, c;
if (a === 4
    && (b === 3 || c === 8)) {
}

Similarly, a multi-line property access triggers this error:

var a;
a
.something();

These examples don't trigger linting errors when tested on the eslint.org demo page.

1. Install npm dependencies
2. Create the project structure
3. Develop the first ESLint => TSLint rule
4. Create tests for the rule decribed in 3
5. Update version to 0.1.0

1. Check all the recommended ESLint rules
2. Update README.md file according to 1.
3. Mark all the recommended rules that are missing in TSLint.

We're gonna need this to our projects, and tslint can also benefits from this (palantir/tslint#1045.).

There are many functions with the same name, we should rename them.

According to eslint.org's documentation on the no-control-regex rule (http://eslint.org/docs/rules/no-control-regex), the following should throw a linting error when no-control-regex is true:

var pattern1 = /\\x1f/;

However, no error is thrown. The second example in the documentation does cause a linting error, as expected:

var pattern2 = new RegExp("\x1f");

• NPM package
• Travis CI
• NPM downloads

palantir/tslint#1016 (comment)
With the extends feature, custom rules could be published as tslint-config-X too. Rules directory will be merged.:

// tslint-eslint-rules -> tslint-config-eslint
// main: tslint.json
{
  "rulesDirectory": "./<local rule relative path>",
  "rules": {
    // Can add default rules value here, and
    // disable conflicting core rules if needed.
  } 
}

😄