mark Theme UI as written in TypeScript in DefinitelyTyped

[hasparus]

Theme UI 0.3 had its types in DefinitelyTyped. Theme UI 0.6 is written in TypeScript and bundles its types.

We need to follow the "Removing a package" instruction to mark Theme UI as rewritten to TS which will cause a publish of stub definitions with a warning telling people they don't need @types/theme-ui when they install it.

[flo-sch]

Even theme-ui v0.4 was partially converted, not sure if it's worth going that deep into the versions though? 🤷‍♂️

Any other packages in Definitely Typed that referenced the deleted package should be updated to reference the bundled types. You can get this list by looking at the errors from npm run test-all. To fix the errors, add a package.json with "dependencies": { "": "x.y.z" }. For example:

Do we already know of any other package referencing theme-ui types?

[hasparus]

Do we already know of any other package referencing theme-ui types?

It seems we're clear on this front.

DefinitelyTyped on  master 
⇝  grep -nr "from 'theme-ui'" .
./types/theme-ui/index.d.ts:327:     * import { jsx } from 'theme-ui'
./types/theme-ui/theme-ui-tests.tsx:2:import { Flex, jsx, css, InitializeColorMode, ColorMode, Styled, SxStyleProp, Theme, useThemeUI } from 'theme-ui';
./types/theme-ui__components/theme-ui__components-tests.tsx:2:import { jsx } from 'theme-ui';
./types/theme-ui__components/index.d.ts:12:import { SxStyleProp } from 'theme-ui';

[flo-sch]

I have never removed a package from DT, do we need specific permissions to run the npm run not-needed ...?

Otherwise I can submit a PR perhaps

[hasparus]

do we need specific permissions to run the npm run not-needed ...?

I don't think so, but I'm not 100% sure.

[flo-sch]

I'll figure it out :)

[flo-sch]

Perhaps theme-ui__components 🤔?

Or should we also remove that one now? (is it too early?)
(Even though the components package has not been converted to TS yet, it provides its own typings)

[hasparus]

(Even though the components package has not been converted to TS yet, it provides its own typings)

We can defo treat it like written in TypeScript — we maintain these types and some day we're gonna merge them with the implementation.

[flo-sch]

Yeah, I had the same thing in mind :)