Building @olism/bd-geo

While working on applications that need location information in Bangladesh, I kept running into the same problem: geographic data was useful everywhere, but there was no reason for every application to maintain its own copy.

Divisions, districts, upazilas, unions, and other location relationships are essentially shared data. Once multiple applications need them, keeping that data inside individual repositories becomes repetitive and makes updates harder to manage.

That led me to build @olism/bd-geo, a reusable developer package focused on Bangladesh geographic data.

The problem

Location looks simple at first.

A form might only need a division and district selector, but the application eventually needs to answer questions such as:

• Which districts belong to a division?
• Which upazilas belong to a district?
• How can an application find a location by its identifier?
• How should geographic relationships be represented?
• How can the same dataset be reused across multiple TypeScript applications?

The obvious solution is to put a JSON file inside each project.

The problem is that this solution does not scale well from a maintenance perspective. Every project ends up carrying its own copy of the data, and improvements made in one project do not automatically become available to another.

Extracting the problem into a package

Instead of treating geographic data as application-specific code, I decided to turn it into a reusable package.

The idea is straightforward:

Application
     |
     v
@olism/bd-geo
     |
     v
Bangladesh geographic dataset

The consuming application should not need to understand how the underlying dataset is organized. It should be able to import the package and work with the data through a predictable API.

TypeScript first

Because most of my current backend and full-stack work is TypeScript-based, I wanted the package to provide a good developer experience for TypeScript applications.

Types are especially useful for a data package because they make the structure of the returned data explicit.

Instead of passing around unstructured objects, the application can understand what a geographic entity represents and what relationships it has.

That makes the package easier to use in backend APIs, frontend forms, validation layers, and other developer tooling.

Why this matters in Bhalobasha

One of the projects where this becomes particularly useful is Bhalobasha, my Bangladesh-focused rental platform.

A rental application naturally needs location information. A property listing may need to be associated with a division, district, or more specific geographic area.

Rather than embedding the entire geographic dataset directly into Bhalobasha, the location concern can be separated:

Bhalobasha
   |
   +-- Rental domain
   |
   +-- Users
   |
   +-- Listings
   |
   +-- Bids
   |
   +-- Favorites
   |
   └-- @olism/bd-geo

This separation keeps the rental application's domain focused on rental functionality while the geographic package focuses on geographic data.

Package design is also engineering

Building an npm package is different from writing a feature inside a single application.

Inside an application, you control the entire environment. With a reusable package, you have to think more carefully about what the consumer sees.

That means considering:

• Public exports
• Type definitions
• Package structure
• Naming
• Versioning
• Compatibility
• Developer experience
• Documentation
• Data consistency

The API becomes a contract between the package and every application consuming it.

Keeping data separate from application logic

One principle I wanted to follow was keeping the geographic dataset independent from the business logic of any particular application.

A rental application should not need to know why a district exists or how the geographic dataset was originally assembled. It should simply consume a reliable representation of the data.

That makes the same package useful for other types of applications:

• E-commerce platforms
• Delivery applications
• Classified marketplaces
• Address forms
• CRM systems
• Analytics dashboards
• Government-related applications
• Location-based services

What I learned

The most interesting part of this project was not writing a large amount of code. It was recognizing that a repeated problem could become a reusable piece of infrastructure.

There is a tendency to think that useful engineering projects need to be large applications. I think small, focused developer tools can be valuable as well when they solve a problem cleanly.

For me, @olism/bd-geo is also part of a broader goal: building reusable software instead of repeatedly solving the same problem inside individual projects.

What's next

The package can evolve independently from the applications that consume it. Improvements to the dataset, API, documentation, and developer experience can benefit every project using it.

That is the main reason I chose to make it a package rather than another folder inside an application repository.

A small piece of shared infrastructure is often more useful than another copy of the same code.