Skip to content
This repository has been archived by the owner on Mar 25, 2021. It is now read-only.

Proposal: ban-syntax #2497

Closed
andy-hanson opened this issue Apr 5, 2017 · 3 comments
Closed

Proposal: ban-syntax #2497

andy-hanson opened this issue Apr 5, 2017 · 3 comments

Comments

@andy-hanson
Copy link
Contributor

andy-hanson commented Apr 5, 2017

The only way to use JavaScript and maintain sanity is to ban 90% of it.
That's why there are many current and desired tslint rules that do nothing but ban a particular kind of syntax from appearing. May not always be as simple as banning a SyntaxKind, but it's usually very simple.

Syntax Name
import "foo"; no-import-side-effect
any no-any
namespace no-namespace
x! no-non-null-assertion
/// <reference path=""> no-reference
<<<, ~, etc. no-bitwise
debugger no-debugger
eval no-eval
null no-null-keyword
var no-var-keyword
== / != triple-equals
<T> x no-angle-bracket-type-assertion
constructor(public x) no-parameter-properties
export default no-default-export
class, this, new no-class, no-this, no-new
let, arguments no-let, no-arguments
label: while (true) {} no-label
[,] no-sparse-arrays (#2407)
delete TODO
x in y TODO
for (x in y) TODO
with (x) {} TODO
{ [x: string]: number } TODO
import x = require("y"); TODO
; (empty statement) TODO
new.target TODO
Your most hated feature TODO

My proposal is to deprecate them all and have a single rule ban-syntax rule that is configurable.
It would behave the same as the separate rules, but would help cut down on rule bloat.

@andy-hanson
Copy link
Contributor Author

One problem would be that // tslint:disable ban-syntax isn't as nice as // tslint:disable no-bitwise. ban-types has the same problem.
But I also think the Rules list is getting kind of intimidating.

@IllusionMH
Copy link
Contributor

Other possible downside (or plus side for someone) - using extend in tslint.json: If new rule can be added to tslint:recommend with own configuration - than it will be applied to consumers code.

With single rule list of banned syntaxes will be overridden(if I remember it correctly) and changes to recommended config won't have any effect.

@JoshuaKGoldberg
Copy link
Contributor

💀 It's time! 💀

TSLint is being deprecated and no longer accepting pull requests for new rules. See #4534. 😱

If you'd like to see this rule implemented, you have two choices:

👋 It was a pleasure open sourcing with you!

If you believe this message was posted here in error, please comment so we can re-open the issue!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants