sindresorhus/tslint-xo

TSLint shareable config for XO

Deprecated as TSLint is deprecated.

---

tslint-xo

TSLint shareable config for XO

Install

$ npm install --save-dev tslint-xo

Usage

Add the following to your TSLint config:

{
	"extends": "tslint-xo"
}

Or this if you want 2-space indentation instead of tabs:

{
	"extends": "tslint-xo/space"
}

Related

• xo - JavaScript linter

Maintainers

• Sindre Sorhus
• Sam Verschueren

License

MIT

tslint-xo's Issues

Add support to Definite Assignment Assertions

TS 2.7+ requires property initialization and a way to suppress this requirement, due the property is initialized out of the constructor, is using the Definite Assignment Assertions, but to do that I need to disable the semicolon and whitespace rules each time I need to do that

I would like to use the Definite Assignment Assertions without any problem.

More info here:
https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-7.html#definite-assignment-assertions

Should we disable `early-exit`?

I'm not sure about the early-exit rule to be honest. Most of the time, it enforces me to rewrite my if-statements. I just want to discuss if other people experienced the same issues, maybe it's just me having to get used to the rule :).

For instance. This piece of code fails

for (const x of xs) {
	if (so) {
		simple;
	} else {
		lots;
		of;
		code;
	}
}

It enforces you to rewrite it to

for (const x of xs) {
	if (so) {
		simple;
		continue;
	}

	lots;
	of;
	code;
}

Which I feel to be less readable. For my own use case, I came across the following block.

ngOnChanges() {
	if (this.meal && this.meal.name) {
		this.exists = true;

		const value = this.meal;
		this.form.patchValue(value);
	}
}

This is wrong, because it prefers an early exit.

ngOnChanges() {
	if (!this.meal || !this.meal.name) {
		return;
	}

	this.exists = true;

	const value = this.meal;
	this.form.patchValue(value);
}

I can see the benefit of early exits in some use cases, but not always.

Want to have some other opinions on this one.

// @kevva

Inconsistent typedef rules

#13 introduced multiple inconsistencies for me (examples seen below). It is not possible to create code that has no lint errors. (Or maybe I am doing something wrong?)

As @sindresorhus already pointed out variable-declaration was annoying this clearly has been used and I am not sure why the problems I am pointing out were not found / removed? Do I miss something obvious?

As a fix I would remove the typedef requirement for the ones I pointed out below. Or maybe there is a better solution?

Because of this I checked the other typedef requirements and think they are still useful:

• call-signature
• arrow-call-signature
• property-declaration
• member-variable-declaration

Examples

arrow-parameter

import test, {ExecutionContext} from 'ava';

test('1', t => {
	t.pass();
});

test('2', (t: ExecutionContext) => {
	t.pass();
});

error messages:

ERROR: 3:11   typedef                         expected arrow-parameter: 't' to have a typedef
ERROR: 7:13   no-unnecessary-type-annotation  type annotation is redundant

parameter

function meh(foo: string = 'bar', bar = 'foo'): string {
	return foo + bar;
}

error messages:

ERROR: 1:19   no-inferrable-types             Type string trivially inferred from a string literal, remove type annotation
ERROR: 1:35   typedef                         expected parameter: 'bar' to have a typedef

object-destructuring

const testObj = {paramA: 'test', paramB: 15};

function caseA(): string {
	const {paramA, paramB} = testObj;
	return paramA + String(paramB);
}

function caseB(): string {
	const {paramA, paramB}: {paramA: string; paramB: number; } = testObj;
	return paramA + String(paramB);
}

error messages:

ERROR: 4:8    typedef                         expected object-destructuring: '{paramA, paramB}' to have a typedef
ERROR: 9:24   no-unnecessary-type-annotation  type annotation is redundant

array-destructuring

const testArr = [1, 2, 3];

function caseA(): number {
	const [first, second, third] = testArr;
	return first + second + third;
}

function caseB(): number {
	const [first, second, third]: number[] = testArr;
	return first + second + third;
}

error messages:

ERROR: 4:8    typedef                         expected array-destructuring: '[first, second, third]' to have a typedef
ERROR: 9:30   no-unnecessary-type-annotation  type annotation is redundant

Disable `completed-docs` rule

I added the completed-docs rule for Ow to make sure that every validator is documented properly. But I don't believe it's a mainstream rule. So maybe it would be better to remove it here and add it as a custom role for Ow only.

Import should be named '.' but found 'm'

I get an error when I import a default export, for instance in my tests.

import m from '..';

[tslint] Misnamed import. Import should be named '.' but found 'm' (import-name)