Lesson learned. Adventure time with TypeScript.
Front-end technologies are moving fast and the number of libraries just enormous, thousands of people support them until new trends come on the stage and everything gets migrated to another tech stack since it’s faster, flexible, probably easier maintainable. Last but not least every day there are fewer and fewer people who support old tools.
I heard about TypeScript(TS) back in 2015, but I haven’t even thought to give it a try. That time I had internship which was dedicated to vanilla JavaScript so I stuck with it. Then, not sure, but probably TS was just a hype which has gone. However, in 2018, more and more people were bringing that topic back again. At the beginning of 2019 I decided to try it out.
There was only one question in my mind:
What steps should I follow to configure my projects?
My journey began from surfing the Internet in an effort to find helpful guides and simple examples of how to deal with this modern technology and create something useful. I was always eager to learn and at this particular point of time I was skimming through a huge amount of resources like a crazy. After several hours, I managed to collect the necessary information and came up with the following steps to smooth the migration and the setup process.
Spoiler: looking into this question, I’ve done a quite newbie mistake that cost me some extra hours spending on the project re-configuration. We will come back to this a bit later.
Note: by the way, if you are tempted to check out the final webpack config first, it's placed right at the end of this article.
Steps:
1. create tsconfig.json file and set strict rules
Note: see all available options in the official docs.
2. create tslint.js and with official TSLint docs add desirable rules
3. update existed webpack.config.js file, like so
Note: we are going to skip the comparison between “awesome-typescript-loader” and other loaders, it’s not that crucial right now, so just pick one, we will get back to it soon.
4. I would highly encourage you to keep your fingers crossed and praying run your project
Why? Whenever a webpack config is changed you never know does it still work or not. With acute pain in my heart and head, I remember every migration from old webpack versions to new ones and all those changes that kept me busy for quite a long time.
5. combine dependable files and replace their format js/jsx by tsx/ts.
6. in every file apply a type to each piece of code: variables, functions and so on. It’s better to start from common files of the app
Note: (in case of the project migration) from the beginning, many errors will occur and ts-compiler will madly throw them. My personal advice is to keep calm, read them accurately and continue setting proper types.
7. repeat until the end
8. be happy
Time to learn one lesson.
Previously I told about a mistake that I did, remember? It’s time to open the chamber of this secret.
When I was busy exploring rules for my TSLint config I was getting results for ESLint as well. The question was — Is it just irrelevant information or it makes sense somehow to what I am currently on? With this question in mind and my curiosity I ended up reading news about TSLint deprecation (Dec 2019) that just came out of the blue, now ESLint should be used instead.
Hm, it’s getting interesting…
Burning the midnight oil using trial and error approach and reading through several guides I’ve migrated to ESLint. However, during the search for the solution, my attention was caught by one of GitHub threads comment, which stated something like:
“…with babel 7 you don’t need ‘ts-loader’ anymore…”
Waaat?? How hell does Babel handle TypeScript code?
Well, before we nail it down I advise you to take a deep breath, close your eyes and think for a moment about something peaceful, then count from 10 to 0 and gently open your eyes.
Ready?
…
…
…
…
…
Are you sure?
…
…
…
…
All right, it simply removes it.
Don’t worry folks I found an explanation in this article, so I encourage you to look into it. For those of you who are extremely lazy here are the highlights:
… it strips out all the TypeScript, turns it into “regular” JavaScript, and continues on its merry way. It makes compilation quite fast, you are able to fast prototype on TS without type check, but what’s the point in writing TypeScript in this case? Now code can be checked once before build. TS compiler throws errors, if they are and then they should be fixed, that is all.
After a short reflection, we should consider following changes in our webpack.config.js
Congratulations! We returned to ground zero and we got rid of almost everything we added before. With minor changes, the config looks simpler and now you don’t have to worry about which loader to use, it’s only one loader and it’s just amazing!
Let’s recap the whole article. To create a good setup you have to follow all defined steps at the beginning of this article, but use the final webpack config version above. Moreover, you don’t need step 2 anymore, just update your ESLint file by implementing changes according to the migration guide.
Finally, besides a proper project configuration, I learned one life lesson to understand which, you should take a look at this gif
Lesson: if you in a rush to get more details about something new for you, never ever forget to configure your search to skip a lot of outdated information and see only results, which you really need. Several hours can be saved with just 3 clicks away. In my case, the first setup was already outdated before I even finished it.
I hope this article helped you to sort out your problem with TypeScript or with a search engine configuration or even both.
