Repro.zip

➡️ Run:

npm i
npm test

❌ You get:

> xo

  a.ts:1:7
  ✖  1:7  a is assigned a value but never used.                                                                                                                                                                    @typescript-eslint/no-unused-vars

  b.ts:undefined:undefined
  ✖  0:0  Parsing error: "parserOptions.project" has been set for @typescript-eslint/parser.
The file does not match your project config: b.ts.
The file must be included in at least one of the projects provided.  

  2 errors

Ok, I guess, tsconfig.json is:

{
	"include": [
		"a.ts"
	]
}

➡️ Change it to include the missing file:

{
	"include": [
		"a.ts",
		"b.ts"
	]
}

➡️ Run:

npm test

❌ Same result as above. It's still complaining that b.ts isn't included but it's included. Crazy.

➡️ Run:

trash node_modules # or # rm -rf node_modules
npm i
npm test

✅ It works.

I also included .eslintrc with which you can verify that eslint isn't doing this. Replace test in package.json with eslint *.ts

a while ago, the xo style guide has been added to @eslint/create-config. In the PR we tried to switch to use the package eslint-config-xo-typescript when users choose typescript + xo.

the problem is: @typescript-eslint/parser was not listed in its peer dependencies. Surely, it's not an issue for npm v7+ users - it's listed in @typescript-eslint/eslint-plugin's peerdeps and will be auto installed. But it won't work for yarn/pnpm/... users.

related discussion: eslint/create-config#33

Background
I like your position on not using null (in favor of undefined).

This library does two things:

1. Adds a @typescript-eslint/ban-types rule that disables the use of the null type.
2. Turns off the unicorn/no-null rule in favor of @typescript-eslint/ban-types.

For a little more background, we were led to your xo and xo-typescript configurations by using npm init @eslint/config from ESLint's Getting Started (and we love it). I stumbled on the rule of disallowing the null type by accident, read your discussion, and fully bought in.

Problem
The problem is, that @typescript-eslint/ban-types will not match value usages, by design. However, the unicorn/no-null rule specifically disallows the use of the null literal:

// will yell
const param: null = null;

// will not yell
const param = null;

Since we want to use type inference as much as possible, the current @typescript-eslint/ban-types rule in this library probably won't catch much for us - we need the value checks.

Suggestion

1. Don't disable the unicorn/no-null rule since it complements the @typescript-eslint/ban-types rule (one checks literals, one checks types).
2. Make this behavior the default when using npm init @eslint/config (maybe include eslint-plugin-unicorn?) - I realize this would be a separate PR in a separate repo.

For (1), we currently have the following config in the meantime (reduced to only show the important bits):

module.exports = {
  extends: [
    'plugin:unicorn/recommended',
    'xo',
    'xo-typescript'
  ],
  rules: {
    'unicorn/no-null': 'error',
  },
};

For (2), you will probably tell us to just use XO directly instead of juggling the extends ourselves.

WDYT?

I'm getting the below error:

Error: /home/s/c/github.com/sindresorhus/pageres/node_modules/eslint-config-xo-typescript/index.js:
        Configuration for rule "@typescript-eslint/no-empty-interface" is invalid:
        Value [{"allowSingleExtends":true}] should NOT have more than 0 items.

no-empty-interface

See https://github.com/typescript-eslint/typescript-eslint/tree/master/packages/eslint-plugin-tslint

I'm put this on hold until typescript-eslint/typescript-eslint#101 is resolved.

Using the latest version of @typescript-eslint (5.45.0), and error is being raised in the configuration of @typescript-eslint/member-ordering.

Oops! Something went wrong! :(

ESLint: 8.28.0

Error: .eslintrc.js#overrides[1] » eslint-config-xo-typescript/space » /<censored>/node_modules/eslint-config-xo-typescript/index.js:
	Configuration for rule "@typescript-eslint/member-ordering" is invalid:
	Value ["signature","public-static-field","public-static-method","protected-static-field","protected-static-method","private-static-field","private-static-method","static-field","static-method","public-decorated-field","public-instance-field","public-abstract-field","public-field","protected-decorated-field","protected-instance-field","protected-abstract-field","protected-field","private-decorated-field","private-instance-field","private-abstract-field","private-field","instance-field","abstract-field","decorated-field","field","public-constructor","protected-constructor","private-constructor","constructor","public-decorated-method","public-instance-method","public-abstract-method","public-method","protected-decorated-method","protected-instance-method","protected-abstract-method","protected-method","private-decorated-method","private-instance-method","private-abstract-method","private-method","instance-method","abstract-method","decorated-method","method"] should be string.
	Value ["signature","public-static-field","public-static-method","protected-static-field","protected-static-method","private-static-field","private-static-method","static-field","static-method","public-decorated-field","public-instance-field","public-abstract-field","public-field","protected-decorated-field","protected-instance-field","protected-abstract-field","protected-field","private-decorated-field","private-instance-field","private-abstract-field","private-field","instance-field","abstract-field","decorated-field","field","public-constructor","protected-constructor","private-constructor","constructor","public-decorated-method","public-instance-method","public-abstract-method","public-method","protected-decorated-method","protected-instance-method","protected-abstract-method","protected-method","private-decorated-method","private-instance-method","private-abstract-method","private-method","instance-method","abstract-method","decorated-method","method"] should be equal to one of the allowed values.
	Value "private-abstract-field" should be equal to one of the allowed values.
	Value "private-abstract-field" should be array.
	Value "private-abstract-field" should match exactly one schema in oneOf.
	Value ["signature","public-static-field","public-static-method","protected-static-field","protected-static-method","private-static-field","private-static-method","static-field","static-method","public-decorated-field","public-instance-field","public-abstract-field","public-field","protected-decorated-field","protected-instance-field","protected-abstract-field","protected-field","private-decorated-field","private-instance-field","private-abstract-field","private-field","instance-field","abstract-field","decorated-field","field","public-constructor","protected-constructor","private-constructor","constructor","public-decorated-method","public-instance-method","public-abstract-method","public-method","protected-decorated-method","protected-instance-method","protected-abstract-method","protected-method","private-decorated-method","private-instance-method","private-abstract-method","private-method","instance-method","abstract-method","decorated-method","method"] should be object.
	Value ["signature","public-static-field","public-static-method","protected-static-field","protected-static-method","private-static-field","private-static-method","static-field","static-method","public-decorated-field","public-instance-field","public-abstract-field","public-field","protected-decorated-field","protected-instance-field","protected-abstract-field","protected-field","private-decorated-field","private-instance-field","private-abstract-field","private-field","instance-field","abstract-field","decorated-field","field","public-constructor","protected-constructor","private-constructor","constructor","public-decorated-method","public-instance-method","public-abstract-method","public-method","protected-decorated-method","protected-instance-method","protected-abstract-method","protected-method","private-decorated-method","private-instance-method","private-abstract-method","private-method","instance-method","abstract-method","decorated-method","method"] should match exactly one schema in oneOf.

The configuration (below) includes two values that are invalid - private-abstract-field and private-abstract-method. Removing these two entries from the array fixes the issue.

Removing these two entries from the array fixes the issue.

It seems that the config allows types named "TSomething":

but I'm getting this error:

  274:3   error    Type Parameter name `TMethod` must match one of the following formats: StrictPascalCase                                                      @typescript-eslint/naming-convention
  275:3   error    Type Parameter name `TPublicMethod` must match one of the following formats: StrictPascalCase                                                @typescript-eslint/naming-convention
  278:3   error    Type Parameter name `TType` must match one of the following formats: StrictPascalCase                                                        @typescript-eslint/naming-convention
  279:3   error    Type Parameter name `TMethod` must match one of the following formats: StrictPascalCase                                                      @typescript-eslint/naming-convention
  280:3   error    Type Parameter name `TPublicMethod` must match one of the following formats: StrictPascalCase                                                @typescript-eslint/naming-convention

See run https://github.com/pixiebrix/webext-messenger/actions/runs/1300974580 for pixiebrix/webext-messenger#35.

The rule has been improved:

• typescript-eslint/typescript-eslint#5050

I had disabled it until now because the autofix duplicated module imports between regular import value and import type Type. They just added an option to avoid that and instead mark each type independently:

import {value, type Type} from 'lib'

Just a heads up, the no-extraneous-class rule currently does not seem to work.
See typescript-eslint/typescript-eslint#170

Workaround:

"rules": {
  "@typescript-eslint/no-extraneous-class": "off"
}

Related:

• #57

This rule’s autofix breaks code like declaration merging, it's not safe nor it is particularly useful other than enforcing a specific style.

Also:

• https://twitter.com/drosenwasser/status/1319205169918144513

The rule option ignoreRhs should be enabled. This is an error I had which is gone with the option enabled:

interface Foo {
	bar?: string[];
}

const obj: Foo = {};
const alwaysArray = obj.bar || [];

With message 6:32 Unnecessary conditional, value is always truthy. which marks the array on the right side as unnecessary condition as [] is always true. Which is exactly what I want in this case.

Documentation: https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/no-unnecessary-condition.md

I think we should set all @typescript-eslint/no-unused-expressions options to true.

{
  '@typescript-eslint/no-unused-expressions': [
    'error',
    {
      allowShortCircuit: true,
      allowTernary: true,
      allowTaggedTemplates: true
    }
  ]
}

Should this configuration enforce Microsoft's eslint-plugin-tsdoc plugin?

This ESLint plugin provides a rule for validating that TypeScript doc comments conform to the TSDoc specification.

// `import/no-duplicates` will warning.
import type { SomeType } from './foo.ts'
import { some } from './foo.ts'

Or wait it's fix.
import-js/eslint-plugin-import#2843

Currently @typescript-eslint/naming-convention rule reports "react function component is not strictCamelCase."

How about add overrides for .tsx (react file extension) ?

Maybe can override it in the following way or copy all configuration for @typescript-eslint/naming-convention

overrides: [
  {
    files: ['**/*.tsx'],
    rules: {
      // ...
      '@typescript-eslint/naming-convention': [
        'error',
        {
          selector: 'function',
          format: ['PascalCase', 'camelCase'],
        },
      ],
    },
  },
]

Using the latest version of @typescript-eslint (6.0.0), an error is being thrown due to an incorrect configuration for @typescript-eslint/restrict-plus-operands.

Oops! Something went wrong! :(

ESLint: 8.44.0

Error: .eslintrc.cjs#overrides[1] » eslint-config-xo-typescript/space » /Users/jamescarr/Git/jamesacarr/home/node_modules/eslint-config-xo-typescript/index.js:
	Configuration for rule "@typescript-eslint/no-restricted-imports" is invalid:
	Value ["error","domain","freelist","smalloc","punycode","sys","querystring","colors"] should be string.
	Value ["error","domain","freelist","smalloc","punycode","sys","querystring","colors"] should be object.
	Value ["error","domain","freelist","smalloc","punycode","sys","querystring","colors"] should match some schema in anyOf.
	Value ["error","domain","freelist","smalloc","punycode","sys","querystring","colors"] should be object.
	Value [["error","domain","freelist","smalloc","punycode","sys","querystring","colors"]] should match some schema in anyOf.

    at ConfigValidator.validateRuleOptions (/Users/jamescarr/Git/jamesacarr/home/node_modules/@eslint/eslintrc/dist/eslintrc.cjs:2039:23)
    at /Users/jamescarr/Git/jamesacarr/home/node_modules/@eslint/eslintrc/dist/eslintrc.cjs:2094:18
    at Array.forEach (<anonymous>)
    at ConfigValidator.validateRules (/Users/jamescarr/Git/jamesacarr/home/node_modules/@eslint/eslintrc/dist/eslintrc.cjs:2091:34)
    at ConfigValidator.validateConfigArray (/Users/jamescarr/Git/jamesacarr/home/node_modules/@eslint/eslintrc/dist/eslintrc.cjs:2217:18)
    at CascadingConfigArrayFactory._finalizeConfigArray (/Users/jamescarr/Git/jamesacarr/home/node_modules/@eslint/eslintrc/dist/eslintrc.cjs:3974:23)
    at CascadingConfigArrayFactory.getConfigArrayForFile (/Users/jamescarr/Git/jamesacarr/home/node_modules/@eslint/eslintrc/dist/eslintrc.cjs:3780:21)
    at FileEnumerator._iterateFilesRecursive (/Users/jamescarr/Git/jamesacarr/home/node_modules/eslint/lib/cli-engine/file-enumerator.js:450:49)
    at _iterateFilesRecursive.next (<anonymous>)
    at FileEnumerator.iterateFiles (/Users/jamescarr/Git/jamesacarr/home/node_modules/eslint/lib/cli-engine/file-enumerator.js:299:49)

From what I can tell, it looks like the options have been changed for this rule, swapping out checkCompoundAssignments for skipCompoundAssignments. The new default is skipCompoundAssignments: false, so it should be possible to simply remove the option and get everything working again.

It was introduced in commit b0477ec, but it seems like outdated.

Related: typescript-eslint/typescript-eslint#85

JSDoc types are duplicate in TypeScript:

https://github.com/bfred-it/webext-options-sync/blob/93eafd4b6607090dca7cc9482a147c88748d340c/index.d.ts#L87-L90 (from https://github.com/bfred-it/webext-options-sync/pull/15/files)

Ideally it would support TSDoc but disabling types would be a step forward.

Settings: https://github.com/gajus/eslint-plugin-jsdoc#eslint-plugin-jsdoc-rules-check-types

Current no-unused-vars rule forces to use _ parameter name to identify it as unused. It clashes with jQuery and forces a dev to destroy parameter name, even if it's temporary unused. The existing convention is to start the parameter with an underscore, like _foo, i.e. it should be ^_, not ^_$. The convention is followed by TS itself and other tools.

It's a great default ruleset in other respects.

{
	"name": "my-awesome-project",
	"eslintConfig": {
		"extends": [
			"xo",
			"xo-typescript"
		]
	}
}

I haven't tested fully, but it seems that this is not enough to enable the configuration on TS/TSX files. I had to call eslint src --ext ts to have the errors show up. This was not required when I was extending plugin:@typescript-eslint/* directly

Please upgrade peer dependency of @typescript-eslint/eslint-plugin to 5.45.0 minimum.

typescript-eslint/typescript-eslint#6077 fixes an issue with satisfies keyword incorrectly interferes with @typescript-eslint/consistent-type-imports rule. We use satisfies keyword in our codebase heavily, but the peer dependency of xo makes it impossible to use @typescript-eslint/consistent-type-imports rule and forcing us to disable the rule.

const listener = (_event: ElectronEvent, arg: {emoji: string; dataUrl: string}): void => {
};

xo-typescript wants this to be formatted

dataUrl: string;}

but Prettier wants this to be formatted

dataUrl: string}

Related to the rule @typescript-eslint/naming-convention.

I regularly use global constants with UPPER_CASE style for constants that wont change in runtime. Not sure how to exactly specify that in the rules but I first wanted to suggest something like that here before checking on how that could be done.

Something like these:

const DIRECTORY = './events'
const DEFAULT_OPTIONS: Options = {
  …
}

If thats something that is not liked here: How would you propose to write constants like this instead?

tsconfig 0.9.0 introduced noPropertyAccessFromIndexSignature which requires refactoring from foo.bar to foo['bar']. xo then errors on @typescript-eslint/dot-notation as foo['bar'] can be written as foo.bar.

The relevant tracking issue: typescript-eslint/typescript-eslint#3104
(I already saw your thumbs up on the issue)

As a temporary fix xo might disable this rule (changing it only to warn would end up in xo --fix which "fixes" it which is annoying then).
Re enable when the mentioned issue is fixed.
The alternative is to wait with the tsconfig 0.9 upgrade. (While writing this issue I think this might be the easiest way to handle this)

The @typescript-eslint/eslint-plugin provides a recommended config which turn off some Eslint rules that conflicts or doesn't work well with TypeScript.

For example in a types.d.ts file with the following code:

type MyType = {};

export {MyType};

the rules rule no-undef is incorrectly triggered.

I think this config is the right place to disable those rules. We could even just include plugin:@typescript-eslint/eslint-recommended here.

What do you think @sindresorhus ?

enumMembers should not be in strictCamelCase.

TypeScript documentation doesn't make a specific recommendation of enum member naming, although they exclusively use StrictPascalCase and UPPER_CASE (both of which are reasonable).

https://github.com/alexgorbatchev/eslint-import-resolver-typescript

Leaving this rule enabled in for example .tsx files causes this error:
'React' was used before it was defined.

Typically this is resolved by using replacing this rule with @typescript-eslint/no-use-before-define as can be seen here.

Why does this config not do that? I was kinda bummed because i thought i could use xo with my TypeScript + React project out of the box ^^'

I upgrade this config to 0.3.0 and it shows Definition for rule typescript/generic-type-naming was not found.

I tested with these versions.

• typescript: 3.1.6
• typescript-eslint-parser: 21.0.1
• eslint-plugin-typescript: 0.12.0

> eslint .


Oops! Something went wrong! :(

ESLint: 8.26.0

Error: .eslintrc.js » eslint-config-xo-typescript/space » /path-to-project/node_modules/.pnpm/[email protected]_fnpynoozaw6u3kufovyuuncmou/node_modules/eslint-config-xo-typescript/index.js:
        Configuration for rule "@typescript-eslint/consistent-type-imports" is invalid:
        Value {"fixStyle":"inline-type-imports"} should NOT have additional properties.

Versions:

• eslint: 8.26.0
• eslint-config-xo: 0.43.1
• eslint-config-xo-typescript: 0.55.0

Reference: typescript-eslint/typescript-eslint#1220

From: https://devblogs.microsoft.com/typescript/announcing-typescript-3-9-beta/#breaking-changes

Specifically, in previous versions, the code

foo?.bar!.baz

was interpreted to be equivalent to the following JavaScript.

(foo?.bar).baz

In the above code the parentheses stop the “short-circuiting” behavior of optional chaining, so if foo is undefined, accessing baz will cause a runtime error.

@typescript-eslint/no-non-null-asserted-optional-chain made sense in that case but TS 3.9 will change the behavior to this:

foo?.bar.baz

which just evaluates to undefined when foo is undefined.

So foo?.bar!.baz becomes perfectly reasonable to catch an undefined foo but ignore an undefined foo.bar

Hello,

I think that the regex below can be improved to ignore all "exotic" keys:

vite: {
  server: {
    proxy: { '/api': { target: 'http://localhost:3003', ws: true } },
    //        ^^^^ Object Literal Property name `/api` must match one of the following formats: strictCamelCase
  },
},

I've experienced some issue when I was using xo with react package, I've used configuration from eslint-config-xo-react but it seems eslint-config-xo-typescript have a little issue with configuration.

It's line 306 at index.js

ui: Error: BaseConfig » eslint-config-xo-typescript:
ui:     Configuration for rule "@typescript-eslint/no-floating-promises" is invalid:
ui:     Value {"ignoreVoid":true,"ignoreIIFE":true} should NOT have additional properties.
ui:     at validateRuleOptions (/Users/jay/GitHub/humantic/node_modules/eslint/lib/shared/config-validator.js:132:19)
ui:     at /Users/jay/GitHub/humantic/node_modules/eslint/lib/shared/config-validator.js:187:9
ui:     at Array.forEach (<anonymous>)
ui:     at validateRules (/Users/jay/GitHub/humantic/node_modules/eslint/lib/shared/config-validator.js:184:30)
ui:     at validateConfigArray (/Users/jay/GitHub/humantic/node_modules/eslint/lib/shared/config-validator.js:312:9)
ui:     at CascadingConfigArrayFactory._finalizeConfigArray (/Users/jay/GitHub/humantic/node_modules/eslint/lib/cli-engine/cascading-config-array-factory.js:464:13)
ui:     at CascadingConfigArrayFactory.getConfigArrayForFile (/Users/jay/GitHub/humantic/node_modules/eslint/lib/cli-engine/cascading-config-array-factory.js:275:21)
ui:     at CLIEngine.isPathIgnored (/Users/jay/GitHub/humantic/node_modules/eslint/lib/cli-engine/cli-engine.js:953:18)
ui:     at /Users/jay/GitHub/humantic/node_modules/xo/index.js:48:32
ui:     at Array.filter (<anonymous>)
ui: error Command failed with exit code 1.
ui: info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

I saw your comment and the corresponding discussion thread about this rule.

Well, it seems like it is ready to go! We get tremendous value by enabling it with the following config:

'@typescript-eslint/strict-boolean-expressions': [
    'error',
    {
      allowString: false,
      allowNumber: false,
      allowNullableObject: false,
    },
  ],

I know you have a TODO comment to reconsider enabling it in 2023 - just want to call out that I think we are there!

OK so here is the bad news: the auto-fixing conflicts with other enabled rules (eqeqeq, no-eq-null). I think all three of those rules are super valuable, and I opened a discussion to hopefully bottom out and align on the triple equals / undefined preference. But that might be a good reason not to enable this rule for now - there is no good way to auto-fix.

FWIW we will still be enabling it in our repository, and then be forced to go manually fix all the places that auto-fix themselves to != null to instead be !== undefined (or !== null where appropriate).

Using the latest version of @typescript-eslint (6.0.0) and eslint (8.44.0), an error is being thrown due to an incorrect configuration for @typescript-eslint/no-restricted-imports.

Oops! Something went wrong! :(

ESLint: 8.44.0

Error: .eslintrc.cjs#overrides[1] » eslint-config-xo-typescript/space » /Users/jamescarr/Git/jamesacarr/home/node_modules/eslint-config-xo-typescript/index.js:
	Configuration for rule "@typescript-eslint/no-restricted-imports" is invalid:
	Value ["error","domain","freelist","smalloc","punycode","sys","querystring","colors"] should be string.
	Value ["error","domain","freelist","smalloc","punycode","sys","querystring","colors"] should be object.
	Value ["error","domain","freelist","smalloc","punycode","sys","querystring","colors"] should match some schema in anyOf.
	Value ["error","domain","freelist","smalloc","punycode","sys","querystring","colors"] should be object.
	Value [["error","domain","freelist","smalloc","punycode","sys","querystring","colors"]] should match some schema in anyOf.

    at ConfigValidator.validateRuleOptions (/Users/jamescarr/Git/jamesacarr/home/node_modules/@eslint/eslintrc/dist/eslintrc.cjs:2039:23)
    at /Users/jamescarr/Git/jamesacarr/home/node_modules/@eslint/eslintrc/dist/eslintrc.cjs:2094:18
    at Array.forEach (<anonymous>)
    at ConfigValidator.validateRules (/Users/jamescarr/Git/jamesacarr/home/node_modules/@eslint/eslintrc/dist/eslintrc.cjs:2091:34)
    at ConfigValidator.validateConfigArray (/Users/jamescarr/Git/jamesacarr/home/node_modules/@eslint/eslintrc/dist/eslintrc.cjs:2217:18)
    at CascadingConfigArrayFactory._finalizeConfigArray (/Users/jamescarr/Git/jamesacarr/home/node_modules/@eslint/eslintrc/dist/eslintrc.cjs:3974:23)
    at CascadingConfigArrayFactory.getConfigArrayForFile (/Users/jamescarr/Git/jamesacarr/home/node_modules/@eslint/eslintrc/dist/eslintrc.cjs:3780:21)
    at FileEnumerator._iterateFilesRecursive (/Users/jamescarr/Git/jamesacarr/home/node_modules/eslint/lib/cli-engine/file-enumerator.js:450:49)
    at _iterateFilesRecursive.next (<anonymous>)
    at FileEnumerator.iterateFiles (/Users/jamescarr/Git/jamesacarr/home/node_modules/eslint/lib/cli-engine/file-enumerator.js:299:49)

From what I can tell, it looks like the format for the options have changed for this rule. It should be possible to change the rule to one of the following, to get it working again:

'@typescript-eslint/no-restricted-imports': [
	'error',
	'error',
	'domain',
	'freelist',
	'smalloc',
	'punycode',
	'sys',
	'querystring',
	'colors'
]

OR

'@typescript-eslint/no-restricted-imports': [
	'error',
	{
		paths: [
			'error',
			'domain',
			'freelist',
			'smalloc',
			'punycode',
			'sys',
			'querystring',
			'colors'
		],
	},
],

import/namespace
This rule is prone to false positives, especially when using TypeScript (seems to handle enums poorly).

The rule should be disabled since the TypeScript compiler already enforces valid imports & references at compile time.

The preview in Visual Studio Code automatically uses readonly T[] over ReadonlyArray<T>.
When looking on Previews of functions and parameters I get familiar with this style of writing parameters. The current rules want me to write a different style.

I havnt looked into Visual Studio Codes Preview Logic or why they do it that way. I only want to start a discussion about it.

These two following methods are accepting the same parameter but the preview of these is the same. The first one produces this xo error:
Array type using T[] is forbidden for non-simple types. Use Array<T> instead. @typescript-eslint/array-type

export function foo(something: readonly Readonly<Something>[]): number {
  return something.length
}

export function bar(something: ReadonlyArray<Readonly<Something>>): number {
  return something.length
}

What are other opinions about changing the rule array-type towards simple arrays?

2a6857d introduces a problem:
Either way I fix the rule, the other denies the code:

const results = await Promise.all(
	queries.map(await o => search(o))
);

Errors:

• Functions that return promises must be async. @typescript-eslint/promise-function-async
• Async arrow function has no await expression. @typescript-eslint/require-await

I personally prefer to have the async at the arrow function as it directly shows 'this returns a promise, it has to be dealt with'.

By enabling XO prettier and using this plugin, you get duplicated errors with rules @typescript-eslint/indent and @typescript-eslint/semi. There should be auto compatibility as they are both integrated within XO.

Hi,

The example in the README doesn't quite cause xo to fire for me. I find that I actually need to specify the extensions, something like:

{
	"name": "my-awesome-project",
	"xo": {
		"extends": "xo-typescript",
		"extensions": ["ts"]
	}
}

Is this expected behavior?

I think import/named should be turn off in this config, because:

• TS can detect this type of error.
• eslint-plugin-import can not detect enum from *.d.ts.

It's been about 3 years since @typescript-eslint/consistent-type-definitions was added to this config as a disabled rule.

Can we re-enable it?

The rule has an automated fixer which should make adoption easy.
I'm not sure there are any situations where you'd even need to manually make the change.

I'll also mention that it may be worth revisiting the decision to prefer type over interface. Historically there were performance concerns from using type instead of interface, but I'm not sure if those are still relevant now.

https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/no-explicit-any.md

Using xo with eslint-config-xo-typescript and @typescript-eslint/eslint-plugin without eslint, I came up with an issue. The default spacing rule set by eslint-config-xo-typescript is tab indentation. If I am going to specify space: true in xo config, I get the following error:

src/index.ts:2:1
✖  2:1  Expected indentation of 1 tab but found 2 spaces.  @typescript-eslint/indent

Here is the xo configuration object:

"xo": {
  "space": true,
  "semicolon": false,
  "ignores": [
    "lib/"
  ],
  "extends": "xo-typescript",
  "extensions": [
    "ts"
  ]
},

It seems that "space": true, is override by eslint-config-xo-typescript. Is there any fix to this?

Currently, the ESlint configuration will mark constant properties on classes as errors. For example:

class FNV {
    private static readonly PRIME = 16777619;
    private static readonly OFFSET = 2166136261;

    // ...
}

Will be considered an error, as they are expected to follow the camel case convention used for other mutable or instance-specific values, despite being an immutable constant.

Unless this is intentional, maybe it could make sense to add a rule to force attributes tagged with static readonly to follow the same UPPER_CASE format as the rest of the constants.

As one example of many (one per file within test/):

test/math/probability.ts
✖    0:0    Parsing error: If "parserOptions.project" has been set for @typescript-eslint/parser, …/test/math/probability.ts must be included in at least one of the projects provided.

So far, the only issue I've run into with v2 is the array-type rule, which needs to be changed to an object instead of a string. Might be more discrepancies though.

    "@typescript-eslint/array-type": [
      "error",
      {
        "default": "array-simple"
      }
    ],

https://github.com/typescript-eslint/typescript-eslint/releases/tag/v2.0.0

HTTP headers and other common words (ex. POST or GET) should be added to an ignorelist so the camelcase validator doesn't trigger for them.