@@ -141,6 +141,39 @@ function addBar(foos, foo) {
141141}
142142` ` `
143143
144+ ### Avoid ` any` whenever possible
145+
146+ Since TypeScript 3.0 and the introduction of the
147+ [` unknown` type](https://mariusschulz.com/blog/the-unknown-type-in-typescript) there are rarely any
148+ reasons to use ` any` as a type. Nearly all places of former ` ` usage can be replace by either a
149+ generic or ` unknown` (in cases the type is really not known).
150+
151+ You should always prefer using those mechanisms over using ` any` , since they are stricter typed and
152+ less likely to introduce bugs in the future due to insufficient types.
153+
154+ If you’re not having ` any` in your plugin or are starting a new plugin, you should enable the
155+ [` @typescript- eslint/ no- explicit- any` ](https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/no-explicit-any.md)
156+ linting rule for your plugin via the [` .eslintrc .js ` ](https://github.com/elastic/kibana/blob/master/.eslintrc.js) config.
157+
158+ ### Avoid non-null assertions
159+
160+ You should try avoiding non-null assertions (` ! .` ) wherever possible. By using them you tell
161+ TypeScript, that something is not null even though by it’s type it could be. Usage of non-null
162+ assertions is most often a side-effect of you actually checked that the variable is not ` null `
163+ but TypeScript doesn’t correctly carry on that information till the usage of the variable.
164+
165+ In most cases it’s possible to replace the non-null assertion by structuring your code/checks slightly different
166+ or using [user defined type guards](https://www.typescriptlang.org/docs/handbook/advanced-types.html#user-defined-type-guards)
167+ to properly tell TypeScript what type a variable has.
168+
169+ Using non-null assertion increases the risk for future bugs. In case the condition under which we assumed that the
170+ variable can’t be null has changed (potentially even due to changes in compeltely different files), the non-null
171+ assertion would now wrongly disable proper type checking for us.
172+
173+ If you’re not using non-null assertions in your plugin or are starting a new plugin, consider enabling the
174+ [` @typescript- eslint/ no- non- null - assertion` ](https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/no-non-null-assertion.md)
175+ linting rule for you plugin in the [` .eslintrc .js ` ](https://github.com/elastic/kibana/blob/master/.eslintrc.js) config.
176+
144177### Return/throw early from functions
145178
146179To avoid deep nesting of if-statements, always return a function's value as early
0 commit comments