The story of migrating 70,000 lines of JavaScript code to TypeScript

Introduction

In the project I’m working on, I’ve experienced migrating over 70,000 lines of code from JavaScript to TypeScript.
We will share the preparations and procedures for the transition, and what we felt when we actually tried

Project Outline

• Full stack web application
• Frontend: JavaScript + React
• 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.

• Since I was used to developing JavaScript, I had a strong image that TypeScript type definition = troublesome.
• I thought that “speed is life”, and I thought that using TypeScript would reduce development efficiency.
• At the beginning of the project, I was the only development member, so I felt that JavaScript was sufficient.
• 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
• 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.

Advance preparation

Identify requirements from source and screen

Since the behavior should not change from that of JavaScript, we have identified the functional requirements from the existing source and the actual screen.
It was useful later to make a note of detailed specifications that were not written in the original requirements.

Rescheduling

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.

Ideally, there will be no JavaScript code, so almost all JavaScript files will be migrated.
Rescheduled according to the number of files and lines of code.

Migration procedure

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.

Gradually transition

Setting with tsconfig allowJs:true, JavaScript and TypeScript are compatible.
I gradually moved from the common part source to TypeScript.
As a specific procedure,

1. Change the extension to ts / tsx
   • Tsx if you use React components, ts otherwise
2. Give molds as needed
   • If you use tslint, the error part turns red
   • Do not define more types than necessary because of type inference
3. 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.

In the case of JavaScript, it is necessary to think about the type for the object that was ambiguous, so it was necessary to
reconsider the specifications when creating it.
I felt that the program became more sophisticated as I moved to TypeScript.

Test

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.

Refactoring

Finally asarrow anywill continue to lose because of the cause of the bug.
Ideally strict:true, 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.
• TypeORM
  • TypeScript OR mapper
  • You can get data from DB without writing SQL
  • Can be implemented type-safer than writing SQL directly
• routing-controllers
  • 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
  • Concepts that decorator, class-based, and JavaScript don’t have come out
• The type definition was not prepared in the library you are using
  • I had to create my own type definition file (d.ts)

Conclusion

By migrating 70,000 lines of JavaScript code, development has become overwhelmingly advanced.
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.

Digression

In another case, I was frustrated trying to migrate a project written in Javascript + Vue to TypeScript.
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.

Conclusion

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.
Why not consider migrating to TypeScript before your JavaScript project grows too large?

Author: tonio0720 from quiita.