Convert to TypeScript
See original GitHub issueBased on the discussions around #121 and the test we just merged in #662, we are going to convert theme-ui to TypeScript! 🎉 The plan is to go package-by-package and gradually move all .js
files to .ts
files.
As you can see there is a fair amount of packages to convert, so we would love your help! 💪
Here is how to convert a package (take a look at #662 for an example):
- Add the
--tsconfig tsconfig.json
option to the “prepare” and “watch” commands in thepackage.json
and copy thetsconfig.json
from the core package. - Add
"types": "dist/index.d.ts"
and"source": "src/index.ts"
to thepackage.json
- Go file-by-file, rename them from
.js
to.ts
and fix all type errors andany
types in the generated typedef (dist/index.d.ts
). - Submit a PR and tag me as a reviewer!
To avoid duplicate work please comment which package you want to work on (as long as nobody else is also working on it) so we can mark it as taken.
Packages that still need to be converted:
- chrome (#909)
- color (#672)
- color-modes (claimed)
- components (https://github.com/system-ui/theme-ui/pull/692)
- core (#662)
- css (#672)
- custom-properties (#671)
- editor (#900)
- match-media (#696)
- mdx (#703)
- preset-base (#675)
- preset-bootstrap (#694)
- preset-bulma (#694)
- preset-dark (#694)
- preset-deep (#694)
- preset-funk (#694)
- preset-future (#694)
- preset-polaris (#694)
- preset-roboto (#694)
- preset-swiss (#694)
- preset-system (#694)
- preset-tailwind (#694)
- preset-tosh (#694)
- presets (#694)
- prism (#805)
- sidenav (#917)
- style-guide
- tachyons (https://github.com/system-ui/theme-ui/pull/691)
- tailwind (https://github.com/system-ui/theme-ui/pull/686)
- theme-provider (#708)
- theme-ui (#724)
- typography (#890)
These packages will be handled separately (see #950)
gatsby-plugin-theme-ui(#705)gatsby-theme-code-recipes(#709)gatsby-theme-style-guidegatsby-theme-ui-blog(#711)gatsby-theme-ui-layout(#710)
Issue Analytics
- State:
- Created 4 years ago
- Reactions:46
- Comments:72 (55 by maintainers)
Top Results From Across the Web
Documentation - Migrating from JavaScript - TypeScript
Converting a JavaScript codebase over to TypeScript is, while somewhat tedious, usually not challenging. In this tutorial, we're going to look at how...
Read more >Converting JavaScript to TypeScript - TutorialsTeacher
Converting Existing JavaScript to TypeScript · Add tsconfig.json file to project · Integrate with a build tool · Change all .js files to...
Read more >Online Javascript to Typescript Converter Tool - JavaInUse
Online tool to convert a javascript file to typescript. Complex javascript files can be converted to typescript file using this tool.
Read more >Converting a Javascript project to Typescript - Medium
Converting a Javascript project to Typescript. An extensive methodology. Photo by Emile Perron on Unsplash. Introduction.
Read more >How to Migrate Application From JavaScript to TypeScript
TypeScript is a superset of JavaScript, so valid JavaScript code is a valid TypeScript code. Incremental migration, converting the whole project step by...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@MarcStdt 0.4.0 is not released yet (you can use
next
tag or 0.4.0-rc.X versions), but the conversion already happened, and the release should happen in the nearest future.@hasparus @mxstbr – my understanding is that Gatsby’s current TS support does NOT work for plugins and themes yet, and as you stated, we do not want to break compatibility with earlier Gatsby versions. I think how we want to handle TS versions of Gatsby plugins is probably worth a bigger discussion, and I think we should move that to a new, separate issue. I’d suggest keeping the in-flight PRs for those packages open, but cut a 0.4 release without those, and addressing those for v0.5. Does that sound reasonable to everyone?