Fix some TS things

[emmatown]

Some misc fixes to things:

• The unitless thing shouldn't be as const, the keys aren't what you want from the types.
• Running tsc on CI
• The native package isn't part of the root TS project since @types/react-native conflicts with DOM types
  • If we convert the native package, that'll need it's own TS config (but only the native package, no other packages should need their own TS configs)
• The type tests aren't part of the root TS config, tbh I kinda think we should just remove DTSLint and use @ts-expect-error for when we expect errors and probably just a function like <T>(t: T) => void to assert types (i know that's not really correct but it's probably good enough for our cases)

[changeset-bot]

⚠️ No Changeset found

Latest commit: 0652f74

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 0652f74:

Sandbox	Source
Emotion	Configuration

[codecov]

Codecov Report

Merging #2559 (0652f74) into ts-migration (4c56bcb) will not change coverage.
The diff coverage is 100.00%.

Impacted Files	Coverage Δ
packages/unitless/src/index.ts	100.00% <100.00%> (ø)

[Andarist]

what the second one is doing here? 🤔

[emmatown]

Not all of the type tests are in a test directory, maybe the first one is unnecessary, idk how TS's globs work

[Andarist]

The type tests aren't part of the root TS config, tbh I kinda think we should just remove DTSLint and use @ts-expect-error for when we expect errors and probably just a function like (t: T) => void to assert types (i know that's not really correct but it's probably good enough for our cases)

The main reason I see to stick with dtslint is to test types against multiple TS versions - and to test them against next version. Since some of our types are a little bit more advanced the latter seems especially nice.

I'm using the strategy that you have mentioned in other repos but mostly because I was too lazy to set up dtslint - since that is already done here, what's the cost of keeping it around?

[emmatown]

since that is already done here, what's the cost of keeping it around?

If we can easily upgrade, sure I guess