Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use unknown instead of any #123

Open
sindresorhus opened this issue Jan 28, 2019 · 4 comments
Open

Use unknown instead of any #123

sindresorhus opened this issue Jan 28, 2019 · 4 comments

Comments

@sindresorhus
Copy link

unknown is the type-safe version of any and should be preferred.

https://stackoverflow.com/questions/51439843/typescript-3-0-unknown-vs-any

@MarshallOfSound
Copy link
Member

I believe unknown will break existing code and force people to do a whole bunch of if checks or any casting to access known properties.

E.g. remote.getGlobal() is currently typed as any, in an ideal world it would be typed

getGlobal<T>(name: string): T;

or even better

getGlobal<K extends keyof NodeJS.Global>(name: K): NodeJS.Global[K]

I've had vague discussions with @BinaryMuse about writing docs / types in typescript as the source of truth so we can be better with types which would solve this (we would type things correctly instead of using the docs parser). But I don't think we can just replace all any usages with unknown.

On a case-by-case basis we could probably make some things unknown in the current docs files. Do you have any specific examples on which APIs should probably be unknown to enforce better type safety?

cc @felixrieseberg @bpasero @BinaryMuse You folks may have opinions here

@sindresorhus
Copy link
Author

I believe unknown will break existing code and force people to do a whole bunch of if checks or any casting to access known properties.

That's kind of the point. You shouldn't just access properties without asserting the type first. That completely loses the point of types, and can result in runtime errors that are not caught at compile-time.

getGlobal(name: K): NodeJS.Global[K]

👍

I've had vague discussions with @BinaryMuse about writing docs / types in typescript as the source of truth so we can be better with types which would solve this (we would type things correctly instead of using the docs parser). But I don't think we can just replace all any usages with unknown.

👍 Much better to generate docs from TS source than the current weird setup of generating types from docs. I guess you mean this: electron/electron#16441?

On a case-by-case basis we could probably make some things unknown in the current docs files. Do you have any specific examples on which APIs should probably be unknown to enforce better type safety?

I can find specific examples where it would be the most beneficial, but honestly, all of it should be unknown instead of any.

@MarshallOfSound
Copy link
Member

I guess you mean this: electron/electron#16441?

That PR actually depends on our current TS generation tech. Although a step towards a hopeful TS future it won't change how we generate docs / typings.

I can find specific examples where it would be the most beneficial, but honestly, all of it should be unknown instead of any.

I'm on board with unknown for literally unknown types, my issue is that at the moment a lot of our any types could be typed if we could write some fun TS types but we can't so they aren't. So for now I don't want to blanket say everything should be unknown.

Better docs / types is something I'm always interested in and will keep unknown in mind in any spikes in the future for better typings / docs 😄

@bpasero
Copy link
Contributor

bpasero commented Jan 28, 2019

One thing I like to use is object over any if I know an object is returned with any kind of properties.

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

No branches or pull requests

3 participants