@@ -26,7 +26,7 @@ module.exports = {
26
26
} ,
27
27
28
28
plugins : [
29
- 'typescript' ,
29
+ '@ typescript-eslint ' ,
30
30
] ,
31
31
32
32
parserOptions : {
@@ -49,93 +49,100 @@ module.exports = {
49
49
50
50
// Require that member overloads be consecutive
51
51
// Grouping overloaded members together can improve readability of the code.
52
- 'typescript/adjacent-overload-signatures' : 'warn' ,
52
+ '@ typescript-eslint /adjacent-overload-signatures' : 'warn' ,
53
53
54
54
// Require PascalCased class and interface names
55
55
// This rule aims to make it easy to differentiate classes from regular variables at a glance.
56
- 'typescript/class-name-casing' : 'warn' ,
56
+ '@ typescript-eslint /class-name-casing' : 'warn' ,
57
57
58
58
// Require explicit return types on functions and class methods
59
59
// Explicit types for function return values makes it clear to any calling code what type is
60
60
// returned. This ensures that the return value is assigned to a variable of the correct type;
61
61
// or in the case where there is no return value, that the calling code doesn't try to use the
62
62
// undefined value when it shouldn't.
63
- 'typescript/explicit-function-return-type' : [ 'warn' , {
63
+ '@ typescript-eslint /explicit-function-return-type' : [ 'warn' , {
64
64
allowExpressions : true ,
65
65
} ] ,
66
66
67
67
// Require explicit accessibility modifiers on class properties and methods
68
68
// This rule aims to make code more readable and explicit about who can use which properties.
69
- 'typescript/explicit-member-accessibility' : 'warn' ,
69
+ '@ typescript-eslint /explicit-member-accessibility' : 'warn' ,
70
70
71
71
// Require that interface names be prefixed with I
72
72
// It can be hard to differentiate between classes and interfaces. Prefixing interfaces with "I"
73
73
// can help telling them apart at a glance.
74
- 'typescript/interface-name-prefix' : [ 'warn' , 'always' ] ,
74
+ '@ typescript-eslint /interface-name-prefix' : [ 'warn' , 'always' ] ,
75
75
76
76
// Require a specific member delimiter style for interfaces and type literals
77
77
// This rule aims to standardise the way interface and type literal members are delimited.
78
- 'typescript/member-delimiter-style' : [ 'warn' , {
79
- delimiter : 'none' ,
78
+ '@typescript-eslint/member-delimiter-style' : [ 'warn' , {
79
+ multiline : {
80
+ delimiter : 'none' ,
81
+ requireLast : false
82
+ } ,
83
+ singleline : {
84
+ delimiter : 'comma' ,
85
+ requireLast : false
86
+ } ,
80
87
} ] ,
81
88
82
89
// Require a consistent member declaration order
83
90
// A consistent ordering of fields, methods and constructors can make interfaces, type literals,
84
91
// classes and class expressions easier to read, navigate and edit.
85
- 'typescript/member-ordering' : 'warn' ,
92
+ '@ typescript-eslint /member-ordering' : 'warn' ,
86
93
87
94
// Enforces the use of `as Type` assertions instead of `<Type>` assertions
88
95
// This rule aims to standardise the use of type assertion style across the codebase.
89
- 'typescript/no-angle-bracket-type-assertion' : 'warn' ,
96
+ '@ typescript-eslint /no-angle-bracket-type-assertion' : 'warn' ,
90
97
91
98
// Disallow generic Array constructors
92
99
// Use of the Array constructor to construct a new array is generally discouraged in favor of
93
100
// array literal notation because of the single-argument pitfall and because the Array global
94
101
// may be redefined.
95
- 'typescript/no-array-constructor' : 'error' ,
102
+ '@ typescript-eslint /no-array-constructor' : 'error' ,
96
103
97
104
// Disallow the declaration of empty interfaces
98
105
// An empty interface is equivalent to its supertype. If the interface does not implement a
99
106
// supertype, then the interface is equivalent to an empty object ({}). In both cases it can be
100
107
// omitted.
101
- 'typescript/no-empty-interface' : 'warn' ,
108
+ '@ typescript-eslint /no-empty-interface' : 'warn' ,
102
109
103
110
// Disallows explicit type declarations for variables or parameters initialized to a number,
104
111
// string, or boolean
105
112
// This rule disallows explicit type declarations on parameters, variables and properties where
106
113
// the type can be easily inferred from its value.
107
- 'typescript/no-explicit-any' : 'warn' ,
114
+ '@ typescript-eslint /no-explicit-any' : 'warn' ,
108
115
109
116
110
117
// Disallow the use of custom TypeScript modules and namespaces
111
118
// Custom TypeScript modules (module foo {}) and namespaces (namespace foo {}) are considered
112
119
// outdated ways to organize TypeScript code. ES2015 module syntax is now preferred
113
120
// (import/export).
114
- 'typescript/no-namespace' : 'error' ,
121
+ '@ typescript-eslint /no-namespace' : 'error' ,
115
122
116
123
// Disallow non-null assertions using the ! postfix operator
117
124
// Using non-null assertions cancels the benefits of the strict null-checking mode.
118
- 'typescript/no-non-null-assertion' : 'warn' ,
125
+ '@ typescript-eslint /no-non-null-assertion' : 'warn' ,
119
126
120
127
// Disallow the use of parameter properties in class constructors
121
128
// This rule disallows the use of parameter properties in constructors, forcing the user to
122
129
// explicitly declare all properties in the class.
123
- 'typescript/no-parameter-properties' : 'warn' ,
130
+ '@ typescript-eslint /no-parameter-properties' : 'warn' ,
124
131
125
132
// Disallow /// <reference path="" /> comments
126
133
// Triple-slash reference directive comments should not be used anymore. Use import instead.
127
- 'typescript/no-triple-slash-reference' : 'error' ,
134
+ '@ typescript-eslint /no-triple-slash-reference' : 'error' ,
128
135
129
136
// Prevent TypeScript-specific constructs from being erroneously flagged as unused
130
137
// This rule only has an effect when the no-unused-vars core rule is enabled. It ensures that
131
138
// TypeScript-specific constructs, such as implemented interfaces, are not erroneously flagged
132
139
// as unused.
133
- 'typescript/no-unused-vars' : 'error' ,
140
+ '@ typescript-eslint /no-unused-vars' : 'error' ,
134
141
135
142
// Disallow the use of variables before they are defined
136
143
// This rule will warn when it encounters a reference to an identifier that has not yet been
137
144
// declared.
138
- 'typescript/no-use-before-define' : [ 'error' , {
145
+ '@ typescript-eslint /no-use-before-define' : [ 'error' , {
139
146
functions : false ,
140
147
classes : false ,
141
148
typedefs : false ,
@@ -144,18 +151,18 @@ module.exports = {
144
151
// Disallows the use of require statements except in import statements
145
152
// In other words, the use of forms such as var foo = require("foo") are banned. Instead use ES6
146
153
// style imports or import foo = require("foo") imports.
147
- 'typescript/no-var-requires' : 'error' ,
154
+ '@ typescript-eslint /no-var-requires' : 'error' ,
148
155
149
156
// Require the use of the namespace keyword instead of the module keyword to declare custom
150
157
// TypeScript modules
151
158
// In an effort to prevent further confusion between custom TypeScript modules and the new
152
159
// ES2015 modules, starting with TypeScript v1.5 the keyword namespace is now the preferred way
153
160
// to declare custom TypeScript modules.
154
- 'typescript/prefer-namespace-keyword' : 'warn' ,
161
+ '@ typescript-eslint /prefer-namespace-keyword' : 'warn' ,
155
162
156
163
// Require consistent spacing around type annotations
157
164
// This rule aims to enforce specific spacing patterns around type annotations and function
158
165
// types in type literals.
159
- 'typescript/type-annotation-spacing' : 'warn' ,
166
+ '@ typescript-eslint /type-annotation-spacing' : 'warn' ,
160
167
} ,
161
168
}
0 commit comments