- 1 Introduction
- 2 Why didn’t you adopt TypeScript in the first place?
- 3 Why did you decide to move to TypeScript?
- 4 Advance preparation
- 5 Migration procedure
- 6 The good thing about TypeScript that I felt after trying it
- 7 What I should have done
- 8 What was adopted at the time of TypeScript migration
- 9 It was hard
- 10 Conclusion
- 11 Digression
- 12 Conclusion
We will share the preparations and procedures for the transition, and what we felt when we actually tried
- Full stack web application
- Backend: Node.js + Express.js + GraphQL
Why didn’t you adopt TypeScript in the first place?
When selecting the technology in advance, there was a discussion about whether to use TypeScript.
At that time, I decided not to use it for the following reasons.
- I thought that “speed is life”, and I thought that using TypeScript would reduce development efficiency.
- At that time, I didn’t expect the project to have that much source.
Why did you decide to move to TypeScript?
As development progressed and I wrote 70,000 lines of code, I decided to move to TypeScript for the following reasons.
- There were too many bugs in the development stage
- In particular, there were many errors related to undefined/null (Cannot read property ○○ of undefined).
- There were many simple type errors
- As the source bloated, I couldn’t keep up with what was going on.
- React component
propsand function arguments are not clearly defined
- I can put anything in the object type
- React component
- Other members will join the place where I was developing alone
- The source was so disturbed that it was difficult for other members to catch up.
- On the contrary, it was difficult to read the sources written by other members.
Identify requirements from source and screen
It was useful later to make a note of detailed specifications that were not written in the original requirements.
First, we had to see how much code we were migrating.
I think there are many ways to do this, but I used VS Code Counter, an extension of VS Code.
Just run it and Markdown will output the number of files and lines of code for each language source.
Rescheduled according to the number of files and lines of code.
When you’re ready, it’s time to move to TypeScript. There seems to be a TS migration tool called
ts-migrate, but I was scared and couldn’t use it.
Create a project on a zero basis
Since the source is managed on GitHub, I started by separating the branch. I’m using Create React App for
this React app, so
npx create-react-app my-app --template typescript
I created a TypeScript-based project from scratch and moved only the files.
Regarding the base part, it was easier to proceed from scratch than to modify it.
Setting with tsconfig
I gradually moved from the common part source to TypeScript.
As a specific procedure,
- Change the extension to ts / tsx
- Tsx if you use React components, ts otherwise
- Give molds as needed
- If you use tslint, the error part turns red
- Do not define more types than necessary because of type inference
- If you can’t help it, make it a
anymold for the time being and refactor it later.
anyAllow as a first-aid only if the type is difficult to define
as any‘s easy to cause bugs, so you need to refactor it later.
reconsider the specifications when creating it.
I felt that the program became more sophisticated as I moved to TypeScript.
After the development was finished, I tested it while comparing it with the screen before the migration.
The behavior may have changed slightly in small areas, so meticulous testing is required.
anywill continue to lose because of the cause of the bug.
allowJs:falseit works with tsconfig.
As you can see in this article,
be aware that depending on how you write it, it can break the type safety of TypeScript.
The good thing about TypeScript that I felt after trying it
- Development efficiency has improved considerably
- Powerful input completion (no spelling mistakes)
- Type checked while typing
- You can check the variable type by mouse over
- You can check the type of function arguments and return values
- Bugs can be prevented
- Static type checking at compile time
- You can write the source beautifully
- Type definition can be treated as a simple document
- Type ambiguity is eliminated, making it reasonably easy for anyone to see
- Easy to catch up with new development members (he said it was easy to understand)
What I should have done
- Systematization of automated testing by Jest
- Static type checking alone can’t prevent all bugs, so I should have implemented unit testing with Jest.
- I didn’t have enough time to implement it
- TypeScript study session
- Some members were confused by the TypeScript-specific writing style.
- Holding a TypeScript study session may have improved overall development efficiency
What was adopted at the time of TypeScript migration
- GraphQL Code Generator
- A tool for generating TypeScript type definitions from GraphQL schema
- React + Apollo will generate a type-safe function
- Thanks to this tool, TypeScript, and GraphQL go great together.
- TypeScript OR mapper
- You can get data from DB without writing SQL
- Can be implemented type-safer than writing SQL directly
- A library that allows you to write Express controllers based on TypeScript classes
- You can also validate and sanitize
- AWS CodeBuild
- By using TypeScript, it took longer to build, so I changed it to build in the cloud
- CodePipeLine automates a series of steps to reduce deployment mistakes
It was hard
- It took a long time anyway
- If the source before migration is rough, you can not write the type definition neatly
- In some cases, it needed to be remade
- Learning TypeScript was hard
- The first one spits out an incomprehensible error
- It was hard to find out how to make it the best practice
- Difficult to understand tsconfig settings and each item
- The type definition was not prepared in the library you are using
- I had to create my own type definition file (d.ts)
The migration itself was hard, but I like writing code so it was a lot of fun.
I think there are various ways of thinking about “should TypeScript be adopted”, but
if it is used for a certain period of time, I think that there is no loss in adopting TypeScript from the beginning.
Vue had a habit of writing originally, and even with TypeScript, type inference did not work
well, so I had the impression that it was not compatible with TypeScript compared to React.
It seems that TypeScript is fully supported in Vue 3.x, so I’m looking forward to it.
I’ve written a lot of things I’m thinking about, but as a person who loves TypeScript, I’d be happy if I could convey its charm as much as possible.
If you have the image that “TypeScript is troublesome”, I would like you to try TypeScript once.
Author: tonio0720 from quiita.
Discussion about this post