A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://github.com/typescript-eslint/typescript-eslint/issues/8978 below:

[ban-types] Split into default-less no-restricted-types and more targeted type ban rule(s) · Issue #8978 · typescript-eslint/typescript-eslint · GitHub

Overview

Splitting out of #8700: ban-types has long been a kind of mirror to the core ESLint rule no-restricted-syntax. But, ban-types also comes with some default settings. That means the rule really has two areas of responsibility:

That dual-responsibility has led to the rule being more convoluted to configure than average. It's the only rule of ours right now that has to include an extendDefaults option.

/** * Rules that do funky things with their defaults and require special code * rather than just JSON.stringify-ing their defaults blob */ const SPECIAL_CASE_DEFAULTS = new Map([ ['ban-types', '[{ /* See below for default options */ }]'], ]);

Once #8977 is in, the defaults for ban-types will exclusively target the uppercase aliases of primitive types (Boolean, Number, ...) and the general Function and Object types. I think the v8 breaking changes are a good opportunity to further simplify the rule. Proposal: let's...

This would be a breaking change in that it would change the defaults for ban-types. Note that the stuff linted against by default in ban-types would still be linted against - just by different rule(s).


RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4