EmberData's native types don't compile with glint about data HOT 9 CLOSED

ok I pulled this down and confirmed a suspicion: the problem here is that neither the project's tsconfig nor the @tsconfig/ember base specifies skipLibCheck: true, which it ought to.

There's no way for libraries to avoid shipping errors in types to consumers (literally), so skipLibCheck should always be used.

cc @NullVoxPopuli / @wagenet / @gitKrystan

from data.

haven't had time to poke through the project you posted; however, this seems almost certainly to be a config issue. We use glint within EmberData itself already, and use it at work with EmberData's native types.

from data.

skipLibCheck: true, which it ought to.

idk, it falls back to any when library code goes wrong, which hides problems 🙈

I would decline PRs to @tsconfig/ember for this change, as I think it's not something library authors should ever enable, and something appdevs could enable, knowing the risks.

from data.

@NullVoxPopuli then the default for Ember apps will be that typechecking fails 🤷🏻‍♂️

its literally impossible to not ship broken types. tsc strips @ts-expect-error and @ts-ignore-error from dts files, and it creates dts files for untyped code that are horribly broken when you generate the types for what code actually is typed.

from data.

also its just literally never a good idea to have skipLibCheck: false, tbh its shocking typescript hasn't removed the feature. Setting it to false tanks your performance, doesn't work with monorepos, and leaves you highly susceptible to semver drift breaking builds while offering no improved type safety or checks.

from data.

why is a library shipping with expect/ignore error tho? or trying to? I feel like there is some context I don't understand where there are broken types somewhere in the dep graph, and a library is trying to paper over the problem with those directives?

My main concern is silent fallback to any from libraries and libraries' internal types (some deep library types are wrong). as long as that doesn't happen, I'm happy with whatever the config ends up being.

from data.

My main concern is silent fallback to any from libraries and libraries' internal types (some deep library types are wrong). as long as that doesn't happen, I'm happy with whatever the config ends up being.

this is both something no app can ever fix and will happen anyway regardless, so its not worth it even yelling at you by default. tsc by-default produces any or types that resolve to any for tons of types. Especially if you use jsdoc, it prefers jsdoc to actual type information and creates non-existent symbols for non-existent types.

from data.

why is a library shipping with expect/ignore error tho?

also because good libraries care about shipping correct-for-consumer types, which means they have to use ts-expect-error in order to produce the correct type.

from data.

you probably want to cast to unknown as TheTypeYouReallyWant as ts-expect-error has never worked for libraries -- just not an option 😅

from data.