Techletter #77 | June 15, 2024
Why do you need module bundlers?
A few days back, I got into a scenario because of which I didnāt have any choice other than to learn about module bundlers.
I started using Rollup. I was just blown away by seeing how wonderfully it worked.
It took me two days to understand the solution to my problem, which was to use a module bundler.
Let me tell you when you are going to need it. For the last two years, I have ignored module bundlers. I have written webpack config, but I didnāt know why it was used or what value it added. But, I understand it now better. Without module bundlers, you may not be able to write a complex TypeScript or JavaScript package. Why? Because, you will end up in a scenario, where the module resolution just wonāt work. You may scratch your head for a few days and will land up here.
Yes, TypeScript wonāt help us either, because it just compiles to JavaScript. Now, you are left with JS code that wonāt work in a package. To make it work, you need to bundle everything into one single file (which you as an individual, if done, may take months or years), module bundlers do it in a second or two. So use it.
Why do we need declaration files in TypeScript?
We need declaration files to provide type information for existing JavaScript modules or libraries.
The declaration files, typically with a .d.ts
extension contains type definitions that describe the shape of a module, including its classes, functions, and interfaces. This information is used by the TypeScript compiler to perform type-checking and provide features like auto-completion and error warnings.
Writing test cases
Recently I have started writing test cases for one of my packages that I am building using TypeScript. Test-driven development is important when creating something that is not allowed to break. Of course, there is a chance that it may fail because of several reasons that you havenāt considered in your test case. But, such cases will be drastically reduced.
I am personally using jest. AI makes it a lot easier to write simple unit test cases. Just try writing it, you will feel more confident about your code, because, you have proof that it works.
Dual package hazard
When an application is using a package that provides both CommonJS and ES module sources, there is a risk of certain bugs if both versions of the package get loaded. This potential comes from the fact that the pkgInstance
created by const pkgInstance = require('pkg')
is not the same as the pkgInstance
created by import pkgInstance from 'pkg'
(or an alternative main path like 'pkg/module'
). This is the ādual package hazard,ā where two versions of the same package can be loaded within the same runtime environment.
Structure of tsconfig.json
The tsconfig.json
file is a standard JSON file, however, it supports JSON5 specifications so you can use comments, single quotes, and more.
It contains some root-level options and some compiler options. The root-level options are options that are outside of the compilerOptions
object.
The root-level options control how the project is presented to the TypeScript compiler, such as which TypeScript files to consider for the compilation.
The compiler options contain settings for the TypeScript compiler such as where to output the compiled JavaScript files in the project directory.
Articles that I read this week
- The ultimate introductory guide for bundling TypeScript packages
- The developerās guide to SSO
- A complete explanation of what package.json is
- Understanding TypeScriptās āCompilation Processā & the anatomy of ātsconfig.jsonā file to configure TypeScript Compiler