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

[feat] skipLibCheck like tsconfig#compilerOptions for typings from modules #100

Open
JounQin opened this issue Aug 30, 2021 · 12 comments
Open
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@JounQin
Copy link
Contributor

JounQin commented Aug 30, 2021

Version(if relevant): 1.0.0

Environment(if relevant):

Code(if relevant):

import { workerData } from 'work_threads' // `workerData` is `any`
import type { StoreValue } from 'antd/lib/form/interface' // `StoreValue` is `any`

Expected:

Actual:

@plantain-00 plantain-00 added enhancement New feature or request Investigating help wanted Extra attention is needed and removed Investigating labels Aug 30, 2021
@plantain-00
Copy link
Owner

I can't find a way to get whether an identifier's type(ts.Type) is from lib.

for example:

function foo(value: StoreValue) {
}

@JounQin
Copy link
Contributor Author

JounQin commented Aug 30, 2021

Hmm... Interesting, how does TypeScript itself implement skipLibCheck? 🤣

@plantain-00
Copy link
Owner

Typescript's skipLibCheck will ignore type error from lib files, type-coverage already do this.

for example, it will not report:

node_modules/antd/lib/form/interface.d.ts:1:1 StoreValue

Your case is more like:

import { Select } from 'antd'
const a: typeof Select = 1 // even though skipLibCheck is set, typescript will still report the error.

Maybe best solution is improve the lib's types.

@plantain-00 plantain-00 added question Further information is requested and removed enhancement New feature or request labels Aug 30, 2021
@JounQin
Copy link
Contributor Author

JounQin commented Aug 31, 2021

@plantain-00 I'm not using like that.

https://github.com/rx-ts/synckit/blob/main/src/index.ts#L6

src/index.ts:6:3: workerData
src/index.ts:113:41: message
src/index.ts:137:8: workerData
522 / 525 99.42%

Besides, the ignoreAsAssertion seems not working at https://github.com/rx-ts/synckit/blob/main/src/index.ts#L113

@plantain-00
Copy link
Owner

src/index.ts:113:41: message comes from !.message, it's ignoreNonNullAssertion

@JounQin
Copy link
Contributor Author

JounQin commented Aug 31, 2021

src/index.ts:113:41: message comes from !.message, it's ignoreNonNullAssertion

Ah, OK, thanks. So it would be better to show the detail reason.

@JounQin
Copy link
Contributor Author

JounQin commented Aug 31, 2021

src/index.ts:113:41: message comes from !.message, it's ignoreNonNullAssertion

@plantain-00 Hmmm... Actually, I've already enabled ignoreNonNullAssertion at https://github.com/rx-ts/synckit/blob/main/package.json#L111

@plantain-00
Copy link
Owner

the message is any, not ignoreNonNullAssertion and ignoreAsAssertion

@JounQin
Copy link
Contributor Author

JounQin commented Aug 31, 2021

@plantain-00

I was expecting ignoreAsAssertion would ignore any as T.

@plantain-00
Copy link
Owner

From ast's perspective, ignoreAsAssertion checks TypeAssertionExpression, any checks type of Identifier and ThisKeyword, It's important for them to keep single responsibility principle.

@JounQin
Copy link
Contributor Author

JounQin commented Aug 31, 2021

Is there any chance to add a new option to ignore such usage? A lot of many any could be imported from 3rd-party packages or JSON.parse.

@plantain-00
Copy link
Owner

Sure, PR is welcome.
Like I commented before, I can't find a way to get whether an identifier's type(ts.Type) is from lib.

@plantain-00 plantain-00 added enhancement New feature or request and removed question Further information is requested labels Aug 31, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants