1. Set code improvement goals
We had two top goals. One, ensuring the GUI code functions are clear to anyone - experienced programmers who have been here from day one, as well as novices who just joined the team. Two, making the migration easy and the learning curve shorter for js users.
2. Get the whole development team on board
As a team, we deliberated between two options: TypeScript (by Microsoft) and Flow (by Facebook). To decide between them, we demoed each one (I demoed TypeScript, another team member deomed Flow). We researched the differences between then, the team asked questions and at the end we voted. For TypeScript, obviously. This choosing method ensured the whole team was a part of the decision, that all concerns were addressed and that the decision wasn’t being seen as taken lightly. This helped with adapting TS and making it an integral part of our code development.
3. Migrate your js files gradually to ts/tsx
4. Create a temporary compiler for both js and ts/tsx
Configuring webpack was easy, all I had to do was add awesome-typescript-loader to my loaders list:
Mocha uses ts-node to compile typescript files, while webpack uses awesome-typescript-loader. Both act a bit differently since ts-node doesn’t support language features that are not a part of the ECMAScript standard. One of these was module imports. So, one of the most common errors I kept getting in tests was:
TypeError: Cannot read property 'createElement' of undefined, even though at the top of the file I had:
After a lot of tinkering I found that changing the imports to the following style solved the problem:
It’s not pretty but it worked. However, changing the default imports in all the files was a lot of boring work and didn’t feel right. So back to Google. After a lot of research, turns out the solution was a simple flag change in the tsconfig.json file and changing the esModuleInterop property to “true”. Boom, all good.
Babel coverage requires you to have:
While ts-node requires you to have both of them set to true. This was a bit tricky to get right, while the rest was basically the same. My solution was to simply separate the ts and the js coverage into different npm scripts, run them in parallel in another npm script, merge the output into one single coverage file and the report the output.
So it looks like this:
Building to production worked out of the box! Phew!
5. Read A LOT about TypeScript
Read, read and again, read, as much as you can about the TypeScript syntax and compiler. Migrating is a complicated project that can have many unexpected fallouts. The more you read the more you will be able to plan and avoid errors, and also react quicker and smarter to surprising outcomes.
Two recommended reads:
I read a lot and am still reading, and that’s part of what made our migration successful.
The TypeScript migration helped me understand our code much better, which in turn helps me develop smarter and more efficient code with less bugs. But a deeper code understanding has even more advantages. Wider knowledge of your code coverage enables writing better performance tests, gaining more insights from test results and fixing bugs faster.
One more final tip: always run performance tests after commiting code. BlazeMeter enables you to run performance tests as part of your continuous testing process, as well as high-scale load tests before big releases. Request a demo to learn more, or try us out yourself by putting your URL in the box below.