Module bundlers šŸ“¦, declaration files šŸ—‚ļø, test cases šŸ§Ŗ, DP hazard ā˜¢ļø, tsconfig.jsonāš™ļø

By Prajwal Haniya

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.

Original Link


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

  1. The ultimate introductory guide for bundling TypeScript packages
  2. The developerā€™s guide to SSO
  3. A complete explanation of what package.json is
  4. Understanding TypeScriptā€™s ā€œCompilation Processā€ & the anatomy of ā€œtsconfig.jsonā€ file to configure TypeScript Compiler