chore: no unnecessary condition

[UncleBill]

MF-0000

2/2 remove no unnecessary condition

[guanbinrui]

Should we use eslint autofix this?

[UncleBill]

Should we use eslint autofix this?

Some conditions could fail at runtime.

[Jack-Works]

Should we use eslint autofix this?

Some conditions could fail at runtime.

this means the type information is incorrect, IMO we should fix the type and start to use eslint.

[UncleBill]

Should we use eslint autofix this?

Some conditions could fail at runtime.

this means the type information is incorrect, IMO we should fix the type and start to use eslint.

External APIs are not 100 percents promising.

[Jack-Works]

External APIs are not 100 percents promising.

Can you give an example? Does that type come from npm? In that case, I agree it's hard to fix, but if that case isn't much, we can case-by-case ignore those and apply auto-fix for the rest.

[UncleBill]

External APIs are not 100 percents promising.

Can you give an example? Does that type come from npm? In that case, I agree it's hard to fix, but if that case isn't much, we can case-by-case ignore those and apply auto-fix for the rest.

There used to be a few. Might not from npm packages but some external APIs which are unpredictable and sometimes unstable. That's why runtime could fail by chance.

[UncleBill]

There comes a live issue https://mask.atlassian.net/browse/MF-6056

[Jack-Works]

There comes a live issue mask.atlassian.net/browse/MF-6056

I think we should stop casting types in our code like this:

const data = await fetchJSON<ApiType>(url)

but like this:

import { } from 'zod'
const _data = await fetchJSON(url) // _data is type unknown
const data = object({
   // ...
}).safeParse()

[Jack-Works]

I think you can merge this if you think this PR is ready, but I still hope we can enable the eslint rule to enforce it.