Comments (7)
This would probably be better as a part of no-unsafe-call
. Eg ban all calls of a Function
typed value, just like it bans all calls of an any
typed values
from typescript-eslint.
The problem with doing that is that it requires type info to handle the typeof usage.
no-uppercase-wrapper-types
will be pure syntactic.
no-unsafe-call
is already type-aware.
So it makes sense (IMO) to split the checks as we don't want to gate a Function
ban behind type-info.
from typescript-eslint.
I think I'm ok with that, too. After a little experimentation i think that's safe as far as passing the narrowed function, too, since
declare const looselyTypedFunction: Function;
// TS error, not assignable.
const strictlyTypedFunction: () => void = looselyTypedFunction;
// ditto for passing as a parameter to functions
declare function callsWithAConcreteCallSignature(f: () => void): void;
// TS error
callsWithAConcreteCallSignature(looselyTypedFunction)
So I think Function
is only unsafe when directly called, which would get caught with no-unsafe-call
from typescript-eslint.
I guess the downside is just that I could see wanting no-unsafe-call
disabled but still wanting the sneaky Function
call safety
from typescript-eslint.
💡🧠 completely different direction: what if we instead made a rule like no-unsafe-function-type
as a part of #9102? It could be aimed at catching any case where the unsafe Function
type creeps in:
: Function
type annotationstypeof
type narrowing on anunknown
Function
is already different from the other types banned in #9102's current new no-uppercase-wrapper-types
in that it's not a class wrapper around a primitive. And thanks to this issue we can see there's this second difference around typeof
narrowing too. That makes me suspect we should have a dedicated rule for the Function
type rather than piecemeal it across multiple other somewhat-related rules (no-uppercase-wrapper-types
, no-unsafe-call
).
from typescript-eslint.
So is our conclusion to build this as a part of no-unsafe-call
instead? Should this be an option or just enabled by default?
from typescript-eslint.
My hot take would be to just put both the existing behavior of no-unsafe-call
and the Function safety under separate options in order to accomodate #9108 (comment). I don't feel strongly though
from typescript-eslint.
Related Issues (20)
- Bug: no-magic-numbers Doesn't apply ignore to type definitions HOT 5
- Enhancement: [prefer-nullish-coalescing] Ignore env vars HOT 1
- Enhancement: [no-useless-template-literals] Delete in v8
- Bug: Missing `src/util` import in `@typescript-eslint/eslint-plugin@rc-v8` with skipLibCheck: false HOT 1
- Enhancement: [prefer-literal-enum-member] Allow nested bitwise when using the `allowBitwiseExpressions` option HOT 5
- Enhancement: [no-non-null-assertion] Optionally exempt contexts where null would immediately throw at runtime HOT 12
- Bug: incorrect peer dependency "eslint@^8.56.0" HOT 2
- Bug: [explicit-function-return-type] false invalid case when using allowTypedFunctionExpressions option HOT 5
- Enhancement: [await-thenable] Should check chained method calls HOT 2
- Bug: @typescript-eslint/no-unused-vars false positive when using "using" declaration statement HOT 7
- 🐛 Bug: RuleTester updates reverted in v8 branch HOT 2
- Bug: [prefer-nullish-coalescing] should consider the difference between null and undefined with strict equality HOT 2
- Bug: 8.0.0.alpha24 shared configuration with type checking fail to start HOT 1
- Bug: `no-floating-promises` should not fire on `Promise.resolve()` HOT 2
- Rule proposal: Prevent unnecessary `| undefined` for optional parameters HOT 3
- Bug(typescript-estree): Project services not working with (tsconfig) extends, project references, and extraFileExtensions HOT 4
- Bug: [no-unnecessary-type-assertion] Conflict with TS for variables used before assignment HOT 5
- Docs: Move PR-specific testing advice from Contributing > Local Development to Pull Requests
- Rule proposal: Consider bringing back no-duplicate-imports HOT 1
- Website: Rules sidebar missing from "tombstone" pages HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from typescript-eslint.