DEV Community: Gaurav Nadkarni

A TypeScript Journey: When Type Safety Feels Like a Safety Harness… and Sometimes a 10 kg Stone on Your Feet

Gaurav Nadkarni — Fri, 26 Sep 2025 04:32:13 +0000

Introduction

When I first started writing code, I lived in the world of Java. It was a place where types were everywhere, like street signs you couldn’t ignore. If you tried to drive your program the wrong way, the compiler would pull you over before you even left the garage. It was safe, predictable, and sometimes a little suffocating.

Then I met JavaScript. Suddenly, I was free. No one asked me to declare the type of a variable, no one complained if I changed my mind halfway through a function, and I could write something messy and watch it still run. It felt liberating until the first time I spent an hour debugging only to find that I had misspelled a property name.

That’s when TypeScript walked in. It promised the best of both worlds: the freedom of JavaScript with just enough guardrails to stop me from repeatedly shooting myself in the foot. And to be fair, it often delivered. But along the way, I also learned that type safety can feel like wearing a sturdy safety harness… or like trying to run a marathon with a 10 kg stone tied to your feet.

This article is a reflection on that journey: the wins, the frustrations, the times TypeScript saved me, and the times it got in the way. If you’ve ever wrestled with types, cursed at the compiler, or wondered if you should just stick to plain JavaScript, I think you’ll relate.

My Background Coming from Java and Its Static Types

I started out in Java, where everything had to be neatly defined before you could even think about running your program. You couldn’t just say, “Here’s a variable, I’ll decide what it is later.” No, you had to declare its type, its purpose, and practically its hopes and dreams before the compiler would even let you compile.

At first, I found comfort in that rigidity. The compiler was like a strict but caring teacher. It wouldn’t let you turn in sloppy work. If I tried to pass a string where an integer was expected, I’d be scolded immediately, long before my code could cause trouble in production. There was a kind of safety in knowing the rules of the game were always enforced.

But over time, I also realized that Java’s strong typing could feel like bureaucracy. Sometimes I just wanted to test a simple idea, but I had to fill out all the forms: classes, interfaces and boilerplate before I could even write “Hello, World.” Still, those years shaped how I think about code: predictable, well-structured, and with the comforting knowledge that the compiler had my back.

So when I later wandered into the wild west of JavaScript, you can imagine the shock.

JavaScript and the Need for Typing

Switching from Java to JavaScript felt like moving from a well-ordered office into a lively street market. In JavaScript, you could pick up anything, call it whatever you wanted, and no one would stop you. Want to treat a number like a string? Go ahead. Accidentally return an object when you promised an array? No problem… JavaScript will just smile and keep running. Compared to Java’s form-filling discipline, this was a revelation.

The joy was real. I could prototype faster than ever before. I didn’t have to spend half an hour explaining to the compiler that, yes, this variable really was supposed to be a string. JavaScript trusted me, and in those early days, that trust felt empowering.

My joy was unmeasurable but little did I know that freedom came with hidden costs. The first time I passed a function expecting an object a null value, everything exploded at runtime. The famous “undefined is not a function” error became my constant companion, and debugging started to feel like detective work in a crime scene I accidentally created.

The bigger the codebase got, the harder it became to manage. Without clear types, I’d forget what shape an object was supposed to have or what a function was supposed to return. Reading my own code after a few months felt like reading someone else’s messy notes, vague hints, no guarantees, and a lot of room for misinterpretation.

The more I built, the more I realized that JavaScript’s charm could become chaos without some structure. And that’s when I started to think: maybe what I needed wasn’t a return to Java’s rigidity, but a middle ground, something that let me keep the joy of JavaScript while avoiding the worst of its pitfalls. That’s where TypeScript entered the picture.

When I Found Type Safety to Be a Potent Solution

When I first started using TypeScript, it reminded me a little of Java but without all the extra ceremony. Suddenly, my editor was more than just a place to write code. It actually helped me. It showed me what arguments a function expected, what type of value I would get back, and it warned me when I tried to use something the wrong way.

The best part was how it caught small mistakes early. If I misspelled a property name or passed a number where a string was expected, TypeScript stopped me right away. These were the kind of mistakes that would have taken me hours to notice in plain JavaScript.

I also liked how types worked as documentation. Instead of guessing what an object should look like or digging through old code, I could see it right in front of me. That made it easier for me to come back to my own code later, and it made teamwork smoother too. Everyone could understand the shape of data or the purpose of a function without asking around.

For the first time in JavaScript, I felt a little safer. TypeScript didn’t make me a better programmer overnight, but it did save me from a lot of silly bugs and misunderstandings.

Why TypeScript Felt Potent:

Caught mistakes early: It prevented bugs by warning about wrong types, misspelled properties, or incorrect function usage before running the code.
Made code easier to understand: Types acted as self-documenting guides, showing exactly what objects and functions were supposed to look like.
Improved coding efficiency: IDE features like autocomplete and IntelliSense worked better with types, helping you write code faster and with fewer errors.

Why Types Sometimes Felt Like Tying a 10 kg Stone to Your Feet and Running a Marathon

As much as I appreciated what TypeScript brought to the table, it wasn’t all sunshine and smooth sailing. Sometimes, using types felt heavy, like I had an extra 10 kg strapped to my legs while trying to run.

Simple things could suddenly take longer than expected. Want to quickly pass an object to a function? If the type definitions weren’t perfectly aligned, the compiler would complain. Trying to satisfy it could take more time than writing the actual logic. Generics, union types, and complex type intersections were powerful, sure but they could also make my head spin.

There were moments when I found myself fighting the type system rather than using it. A function that worked perfectly fine in JavaScript suddenly threw red squiggly lines because the type checker didn’t like something subtle I did. I’d spend minutes or sometimes hours tweaking type definitions instead of focusing on the real problem.

It became clear that while types catch many mistakes, they also come with a cost. There’s a balance to strike between type safety and developer speed. Too strict, and you feel weighed down; too loose, and you risk slipping on a bug.

Even so, despite the occasional frustration, I kept coming back to TypeScript because for all the extra work, it still prevented more headaches than it created.

Why TypeScript Can Feel Heavy:

Extra time for simple tasks: Even small changes can require updating type definitions, slowing down development.
Complexity with advanced types: Generics, union types, and intersections can be powerful but sometimes confusing or overcomplicated.
Fighting the compiler: At times, the type system seems to block working code, making you spend more time satisfying the compiler than solving the actual problem.

When Type Safety Didn’t Really Work

Even with all the benefits TypeScript brought, there were times when it couldn’t save me. Type safety can prevent certain mistakes, but it doesn’t make your logic perfect. I’ve had functions that passed all type checks but still produced wrong results because the underlying algorithm was flawed. The compiler happily approved my mistakes, leaving me scratching my head at runtime.

Another frustration came from third-party libraries. Not every library has perfect type definitions. Sometimes the types were missing, incomplete, or outright wrong. That meant I either had to write my own types, ignore errors, or risk subtle bugs sneaking through none of which were particularly fun.

Dynamic data like API responses or user input can also bypass the safety net. You can type everything perfectly on paper, but the real world rarely behaves as expected. JSON structures can change, fields can be missing, and suddenly the carefully typed code crashes anyway.

Type inference, while helpful, isn’t always smart enough. Sometimes TypeScript guesses a type that doesn’t match reality, leading to confusing errors that are tricky to debug. And optional or union types, while designed for flexibility, can add cognitive overhead checking for every possible case can be tedious.

Finally, overconfidence is a hidden danger. Passing the compiler gives a false sense of security. I’ve found myself thinking, “If it compiles, it must be correct” only to realize later that runtime bugs were still lurking.

In short, TypeScript is powerful, but it’s not a silver bullet. It helps a lot, but careful thinking, thorough testing, and realistic expectations are still essential.

When I Choose JavaScript Over TypeScript

Even after all my experiences with TypeScript, there are definitely times when I still reach for plain JavaScript. Sometimes, the speed and simplicity of JS just make more sense.

For quick prototypes or one-off scripts, the overhead of setting up types can feel unnecessary. If I just want to test an idea, hack together a small tool, or experiment with a library, TypeScript can slow me down more than it helps. JavaScript lets me move fast, make changes on the fly, and see results immediately.

There are also situations where the project is short-lived or the code won’t be maintained long-term. Spending extra time defining types for a small script or a hacky solution doesn’t make sense. In these cases, the flexibility and minimal setup of JavaScript outweigh the safety net TypeScript provides.

Finally, working solo sometimes means I know my own code well enough that type safety feels redundant. I can read my code quickly, keep track of variable shapes, and spot mistakes without the compiler holding my hand. TypeScript is amazing, but it’s not always necessary when the context doesn’t call for it.

In short, I reach for JavaScript when speed, simplicity, and flexibility matter more than strict safety.

When I Choose TypeScript

Even though there are times I prefer plain JavaScript, there are plenty of situations where TypeScript is my go-to. The main factor is usually scale. When a project is large or expected to last a long time, the safety and structure that TypeScript provides become invaluable.

TypeScript shines in team projects. Types act like a shared language that reduces confusion and miscommunication. When someone else writes a function or module, I can understand exactly what inputs it expects and what outputs it provides, without needing to read through pages of code or ask too many questions.

I also choose TypeScript when working with APIs or external data sources. Having explicit types helps catch unexpected changes or missing fields in responses, which can save hours of debugging later.

And then there’s maintainability. Returning to code after weeks or months is always easier with TypeScript. Types serve as reminders of how things are structured, making it simpler to add features or refactor without breaking unrelated parts of the code.

In short, TypeScript becomes my tool of choice whenever clarity, reliability, and collaboration matter more than raw speed. It’s not just about preventing bugs, it’s about building confidence in the code that I and others will rely on.

My Takeaway

TypeScript has been a fascinating journey for me. Coming from Java, I was used to strict types and compile-time safety, and JavaScript initially felt like a breath of fresh air. That freedom was exhilarating but it came with hidden costs, from runtime errors to messy, hard-to-maintain code.

TypeScript offered a middle ground. It caught many of the mistakes that would have haunted me in plain JavaScript, improved readability, and made teamwork much smoother. At the same time, it’s not without friction. Sometimes the type system feels heavy, overly strict, or just plain confusing. And of course, it can’t protect you from logic errors or unpredictable runtime data.

For me, the choice between JavaScript and TypeScript is all about context. I reach for JavaScript when speed, flexibility, or small-scale projects matter. I choose TypeScript when clarity, maintainability, and collaboration are priorities.

At the end of the day, types are a tool, not a guarantee. They guide you, catch mistakes early, and save time but they don’t replace careful thinking, testing, or judgment. And yes, sometimes they feel like a little extra weight but a safer, more confident weight.

Thank you for reading! If you enjoyed this article or have your own experiences with JavaScript and TypeScript, I’d love to hear from you! Share your thoughts in the comments, or reach out to me on X (@gauravnadkarni) or via email (nadkarnigaurav@gmail.com).

Building an Extendable Data Migration Utility in Java Using the Strategy Pattern

Gaurav Nadkarni — Tue, 23 Sep 2025 04:36:52 +0000

How I applied the Strategy Pattern to handle multiple source systems and keep the utility scalable

Introduction

While working on a Java-based utility, I encountered a challenge: moving data between different systems that each had their own export formats. Our target system was Jira Cloud, which accepted data in a specific JSON format through its APIs.

The complication came from the source systems. One example was GitHub, where I needed to export issues in JSON. Other systems exported their data in entirely different formats. The requirement was clear: I needed a flexible solution that could:

Support multiple source systems, each with different data formats
Transform the extracted data into a unified format compatible with Jira
Be easily extendable to support new platforms in the future

The load step (pushing data to Jira) was straightforward. The real complexity lay in the extract and transform steps. That’s where the Strategy Pattern turned out to be the right approach.

Why the Strategy Pattern?

The Strategy Pattern allows you to encapsulate different algorithms (or logics) into separate classes and make them interchangeable at runtime.

For our use case, the “algorithms” were the extraction and transformation processes, which varied depending on the source system. Using the Strategy Pattern gave us two key benefits:

Flexibility: I could easily switch between different extraction and transformation strategies at runtime based on the source system.
Extensibility: Adding support for a new platform meant just implementing a new strategy without changing the existing code.

Defining the Strategy Interfaces

I broke the problem into two main steps: Extract and Transform.

Extract Strategy

public interface ExtractStrategy { 
  String extractData();
}

Transform Strategy

public interface TransformStrategy {
  String transformData(String rawData);
}

Implementing Strategies for GitHub

Let’s take GitHub as an example.

// Extract strategy for GitHub
public class GitHubExtractStrategy implements ExtractStrategy {
    @Override
    public String extractData() {
        // Simulating extraction from GitHub
        return "{ \"title\": \"Issue 101\", \"body\": \"Sample issue description\" }";
    }
}

// Transform strategy for GitHub data
public class GitHubTransformStrategy implements TransformStrategy {
    @Override
    public String transformData(String rawData) {
        // Convert GitHub issue JSON into Jira-compatible JSON
        return "{ \"fields\": { \"summary\": \"Issue 101\", \"description\": \"Sample issue description\" } }";
    }
}

Similarly, if another system like ServiceNow was introduced later, I could create ServiceNowExtractStrategy and ServiceNowTransformStrategy without changing existing code.

Context to Tie Strategies Together

I used a Context class to apply the strategies dynamically:

public class DataProcessor {
    private ExtractStrategy extractStrategy;
    private TransformStrategy transformStrategy;

    public DataProcessor(ExtractStrategy extractStrategy, TransformStrategy transformStrategy) {
        this.extractStrategy = extractStrategy;
        this.transformStrategy = transformStrategy;
    }

    public void process() {
        String rawData = extractStrategy.extractData();
        String transformedData = transformStrategy.transformData(rawData);

        // Load step (pushing to Jira)
        System.out.println("Loading to Jira: " + transformedData);
    }
}

Using the Strategies at Runtime

The client code simply decides which strategies to use:

public class Main {
    public static void main(String[] args) {
        // GitHub strategies
        ExtractStrategy extractStrategy = new GitHubExtractStrategy();
        TransformStrategy transformStrategy = new GitHubTransformStrategy();

        DataProcessor processor = new DataProcessor(extractStrategy, transformStrategy);
        processor.process();

        // In future, just plug in new strategies for other platforms
    }
}

Outcome and Takeaways

With this design, I achieved the following:

Each source system’s extraction and transformation logic stayed isolated.
The utility was easy to extend and supporting a new system was just a matter of writing a new strategy.
The load step remained independent of extraction and transformation.

The Strategy Pattern fit naturally into the Extract-Transform-Load (ETL) process, letting us build a scalable and maintainable migration utility.

Handling Different Data Formats

While strategies in our utility were tied to platforms, I noticed that data formats (JSON, CSV, XML) played an important role inside each strategy.

For example:

GitHub APIs exported JSON.
Some other platforms exported CSV.
Others used XML.

Instead of making data formats their own strategies, I treated them as implementation details within platform-specific strategies. This way, the decision of which format to parse remained encapsulated in each platform strategy, keeping the overall design clean and platform-centric.

Wrap-up:

This is how I used the Strategy Pattern in a real-world scenario. It not only solved the immediate problem of handling GitHub and other systems but also gave us a foundation to support future integrations with minimal changes.

Thank you for reading! I’d love to hear your thoughts or questions in the comments. If you are passionate about building global-ready products, let’s connect on X (@gauravnadkarni) or reach out to me via email (nadkarnigaurav@gmail.com).

How to Ghost Your Data: Implementing Soft Deletes in Prisma

Gaurav Nadkarni — Thu, 18 Sep 2025 06:37:30 +0000

Learn how to implement soft deletes in Prisma, avoid common pitfalls, and keep those ghost records under control.

Introduction

It was just another regular day at the office. I was staring at a database schema, plotting out a shiny new feature, when my phone buzzed. One of the guys from the support team was on the line.

Apparently, a customer had accidentally deleted a few records through the application UI and now wanted to know the answer to the million-dollar question: “Can you get them back?”

The answer, of course, was the soul-crushing, developer-standard “No.”

So, the poor customer had to recreate those records from scratch. And me? I couldn’t stop thinking, there had to be a better way.

Sure, the obvious answer was to restore from a backup. But let’s be real: digging through backups just to fish out a single record is like searching for a specific grain of rice in a bag slow, tedious, and way too much effort for what should be a simple fix.

And that’s when it hit me: maybe what I needed wasn’t a backup. Maybe what I needed was soft deletes, a way to delete data without actually, you know, deleting it.

For the examples in this article, let’s imagine a simple setup with User and Post tables you know, the classic “social media app that everyone builds to learn something new.” I’ll use this example to explain how to implement soft deletes in the sections ahead. And don’t worry, you won’t be left piecing things together from scattered snippets of code. I’ve provided the full codebase in a GitHub repo (linked at the end of the article).

This article is for anyone who wants to understand what soft deletes are, why they matter, and how they can be configured with Prisma without losing your database sanity.

Why Soft Deletes Are the Chill Way to Delete

What is soft deletion, after all?
Simply put, it’s a way to mark a record as deleted in your database without actually removing it. Think of it like putting something in the “trash” on your computer, it’s out of sight for the user, but still sitting safely in the database, waiting to be restored (or permanently purged later).

Here’s how it works: the record stays in the database, but your application filters it out during queries so that users never see it. We’ll get into the “how” a bit later, but first, let’s talk about why soft deletes can save your bacon:

Oops moments from users: Someone accidentally deletes their data, and you can swoop in like a hero to restore it.
Audit trails: Track when a record was marked as deleted, which can save hours of debugging or help with compliance checks.
Safe relationship changes: No more scary errors because a dependent record suddenly vanished relationships stay intact.
With soft deletes, you can pretend the data is gone while secretly keeping it around like a responsible digital hoarder.

Sketching Your Data’s Retirement Plan

Now that we know what soft deletes are, let’s talk about how they actually work, from the frontend all the way to the database.

At its core, soft deletion is simply about, marking a record in the database as “deleted” instead of truly removing it. To do this, we add a special column, let’s call it our “soft deletion identifier” which could be a boolean, text, or datetime column. This column acts like a little flag to tell us, “Hey, this record is technically gone, but we’re keeping it around just in case.”

Here’s what the flow usually looks like:

Add the “soft deletion identifier” column to the tables you want to soft delete.
Update your database queries to ignore records where the “soft deletion identifier” is set.
User creates a record → the “soft deletion identifier” column is set to false or null (depending on your column type).
User sees the record in the app like normal.
Later, the user deletes the record → the “soft deletion identifier” column is updated (to true, the current timestamp, or maybe even the ID of the user who deleted it).
On the next query, your app skips over those flagged records to the user, it’s as if the record is gone, even though it’s still there, quietly existing in your database.
This simple mechanism is the foundation for everything else we’ll build in the upcoming sections, from Prisma client extension to relationship handling.

Here’s the bare-minimum schema.prisma with only the fields you need for User, and Post including the deleted_at column which is the “soft deletion identifier” column.

model User {
 id String @id @default(uuid())
 email String @unique
 name String
 posts Post[]
 comments Comment[]
 deleted_at DateTime? @db.Timestamptz
}

model Post {
 id String @id @default(uuid())
 title String
 content String?
 author User @relation(fields: [authorId], references: [id])
 authorId String
 deleted_at DateTime? @db.Timestamptz
}

Extending the Prisma Client: Teaching It New Tricks

Now that we’ve updated our database and know the high-level plan, it’s time to bring Prisma into the picture. Remember the deleted_at column we added earlier? Prisma doesn’t magically know what this column means. To Prisma, it’s just another field.

That’s where Prisma extensions come in. With client.$extends, we can hook into lifecycle methods, preprocess queries, and even add our own custom methods. Here’s the core idea of the softDelete extension:

Intercept queries before they run (findUnique, findFirst, findMany, etc.) and automatically filter out records where deleted_at is set.
Post-process results so the deleted_at field is stripped out unless explicitly requested.
Add new helper methods (restore, hardDelete, etc.) so developers can safely control deletion behavior when needed.

This means soft deletes become the default behavior across the app. Developers don’t have to sprinkle deleted_at: null conditions everywhere. Prisma just takes care of it behind the scenes.

const softDeleteExtension = Prisma.defineExtension((client) =>
 client.$extends({
 name: “softDeleteExtension”,
 query: { $allModels: { /* overrides */ } },
 model: { $allModels: { /* custom methods */ } },
 })
);

Inside query.$allModels, we intercept Prisma's built-in methods like findUnique, findFirst, and findMany. For example, here's how we handle findMany:

async findMany({ args, query }) {
  let queryArgs = args;// Only include non-deleted records by default
  queryArgs.where = { …queryArgs.where, deleted_at: null };

  const records = await query(queryArgs);

  // Remove deleted_at unless explicitly requested
 return records.map(({ deleted_at, …rest }) => rest);
}

This way, any query automatically ignores soft-deleted records unless you explicitly opt in.

While working with Prisma’s $extends, I picked up a few important points, some of them the hard way:

The query key in $extends lets you override Prisma’s built-in query functions like findFirst, update, or create. This means you can tweak the arguments before they hit the database or even massage the results after they come back.
The model key is where you can add custom methods (like restore or hardDelete) directly to your Prisma client. Super handy when soft delete logic becomes a first-class citizen in your app.
Both query and model objects have a $allModels key, which is a catch-all way to override Prisma’s default implementation across every model.
You can still target specific models (like user or post) to add/override methods for just that model. At runtime, Prisma checks if a model-specific method exists. If it does, that one gets called first and if you call the provided query function inside it, Prisma falls back to the $allModels implementation.

Think of it like inheritance in OOP: model-specific overrides win, but the generic $allModels safety net is always there if you want to enforce cross-model rules.

Soft Deleting Records: Because Delete Buttons Need Therapy

Normally, prisma.post.delete({ where: { id } }) would wipe the record from the DB. With our extension, the delete call is overridden to mark it as deleted instead of removing it:

async delete({ args, query, model }) {
  // If hard delete requested, bypass soft delete
  const hardDeleteRecords = shouldHardDeleteRecords(args);
  if (hardDeleteRecords) {
     const { hardDelete, ...rest } = args;
     return query(rest);
   }

   args.where = { ...args.where, deleted_at: null };
   return (client as any)[model].update({
      where: { ...args.where },
      data: { deleted_at: new Date() },
   });
}

Now your “Delete” button is safe by default. And if you ever want to truly purge data, the extension exposes a hardDelete method:

async hardDelete(where: Record<string, unknown>) {
    return (this as any).delete({
        hardDelete: true,
        where,
    });
}

//call to hard delete method
await prisma.post.hardDelete({ id: "123" });

Restoring Soft Deleted Records: Your Data’s Resurrection Button

One of the best parts about soft deletes is the ability to undo mistakes. If a record was deleted by accident, you can bring it back with the custom restore method:

async restore(where: Record<string, unknown>) {
  return (this as any).update({
    where,
    data: { deleted_at: null as unknown as Date }, // resurrect the record
  });
}
async findFirstWithDeleted(
    where?: Record<string, unknown>,
    include?: Record<string, unknown>
) {
    return (this as any).findFirst({
      includeDeleted: true,
      where,
      include,
  });
},

So, if a user deletes a post by mistake:

`await prisma.post.restore({ id: "123" });`

And just like that the post is back in the app.

You can also query deleted records when needed (say, in an admin dashboard) using the custom helper:

await prisma.post.findFirstWithDeleted({ id: "123" })

Handling Relationships: The Awkward Family Drama

Now comes the trickiest part: “relationships”. If soft deletes were a family, this is where the awkward drama begins.

Take a simple example: you have user records and post records. A user can create posts. Easy enough. But what happens when you delete a user? You also need to delete (or soft delete) their posts. So far, manageable.

But wait, the complexity ramps up with “soft deletes”. When you soft delete a user, you also have to soft delete all the posts connected to that user, and when you restore the user, guess what? Yup, you need to restore their posts too.

Now here’s where things get awkward. Imagine a post was manually deleted by the user before the user account itself was soft deleted. When you restore the user later, do you also restore that post? You probably shouldn’t but unless you’re keeping track of how it was deleted, you don’t have a way to tell the difference. Suddenly, you’re not just restoring posts… you’re resurrecting ones that were meant to stay buried. Zombie posts, anyone? 🧟‍♂️

And it doesn’t stop there. If you try to restore a post, but the author (user) is also soft deleted, do you restore the user too? This cascade effect gets complicated really fast, especially as your data model grows more complex (think User → Post → Comment → Like → Tag).

Here’s a simplified code example of how we handle this using Prisma transactions:

async delete({ args, query, model }) {
  const hardDeleteRecords = shouldHardDeleteRecords(args);

  return client.$transaction(async (tx) => {
    const user = await (tx as any).user.findFirst({
      where: args.where,
    });

    if (!user) {
      return user;
    }

    if (hardDeleteRecords) {
      await (tx as any).post.deleteMany({
        where: { authorId: user.id },
      });

      return (tx as any).user.delete({
        where: { id: user.id },
      });
    }

    const updatedUser = await (tx as any).user.update({
      where: { id: user.id },
      data: { deleted_at: new Date() },
    });

    await (tx as any).post.updateMany({
      where: {
        authorId: user.id,
        deleted_at: null,
      },
      data: { deleted_at: new Date() },
    });

    return updatedUser;
  });
}

Here, we use Prisma’s transaction object to make sure that when a user is deleted (hard or soft), their connected posts are handled at the same time.

Transactions: Where My Brain Nearly Filed for Bankruptcy

If there’s one place that really tripped me up while working with soft deletes in Prisma, it was transactions. A few things I wish someone had told me before I spent hours questioning my career choices:

The Prisma client object and the transaction object are two different beasts. Don’t confuse them.
Inside a transaction, the transaction object won’t have the extended methods you lovingly added with $extends. It’s bare-bones.
Types can get very messy here. Honestly, the safest route is to keep your complex logic (like hard deletes or restore flows) fully contained inside the transaction block.
Whatever you do, don’t use the global client object inside a transaction block. If you do, those queries will run outside the transaction… which kind of defeats the whole point. So yeah, think of transactions in Prisma as a special sandbox. Once you’re in, you have to play by its rules.

Guarding Against Chaos: No `deleted_at` Updates on Create/Update

We just saw how relationships can complicate soft deletes and turn them into a bit of a balancing act. But there’s another landmine you need to avoid: accidentally messing with your soft delete identifier column (deleted_at).

Think of deleted_at as a big red button. If you (or worse, your teammate) set a value there by mistake, the record is instantly marked as deleted, even though you never meant to. Not fun.

That’s why it’s critical to keep this column completely off-limits during “create” and “update” operations. The rule of thumb: never touch deleted_at directly in your app code. It should only be managed through your Prisma extension - your safe wrapper that knows when and how to set it.

By keeping that guardrail in place, you reduce the risk of random “why did my user disappear?” mysteries in production.

Unique Constraints: Can Two Ghosts Share the Same Email?

Here’s another fun wrinkle: unique constraints.

Take the classic case of a user model with an email field that has a unique constraint. In a hard delete world, once a user is gone, that email (or username) is free to use again. But with soft deletes, the old record is still hanging around in the database, just marked as invisible.

So what happens if someone tries to sign up with the same email? Boom 💥, you hit a constraint violation. The database doesn’t care that the record is “soft deleted”. It still sees it as existing.

This creates an awkward situation where ghost records can block new, legitimate ones.

Possible ways to handle this:

Partial unique indexes (if your database supports them): Create a unique index that only applies to records where deleted_at IS NULL. That way, soft-deleted rows won’t interfere.
Archival tweaks: Instead of keeping the same email intact, you could append something to it during soft delete (e.g., user@example.com → user+deleted123@example.com). This frees up the original email for reuse.
Application-level checks: Add logic in your Prisma extension or service layer to filter out soft-deleted records when enforcing uniqueness.

Each option has trade-offs. Archival tweaks are simple but messy, partial indexes are clean but database-dependent, and app-level checks give flexibility but add complexity.

Performance Tips: Because Nobody Likes a Slow Ghost Hunt

Soft deletes sound simple in theory: just add a deleted_at field and filter it out in queries. Easy, right? Well… not quite.

Once your database starts growing, those “invisible” rows still sit there, quietly bloating your tables. Every time you query WHERE deleted_at IS NULL, the database has to scan through all the rows including the ghosts. And that’s where performance can take a hit.

Why indexing deleted_at matters?
By adding an index on the deleted_at column, you give your database a fast way to separate the living from the dead. Instead of scanning every row, the database can jump straight to the subset you care about: those that aren’t soft deleted.

In real-world terms, this means:

Faster queries: when fetching active users, posts, or any entity.
Consistent performance as your database grows.
Less load on your database server, which translates into lower costs in the long run.

Add this to the schema.prisma file in the required model

@@index([deleted_at])

Now when Prisma runs queries like:

const activeUsers = await prisma.user.findMany({ where: { deleted_at: null } });`

the database doesn’t slog through a swamp of deleted rows. It uses the index to quickly find the living ones.

⚡ Pro tip: If you have composite queries (like filtering by deleted_at and authorId), consider creating a composite index ((authorId, deleted_at)) for even faster lookups.

@@index([authorId, deleted_at])

Counting, Grouping, and Other Math-y Things

Soft deletes aren’t just about hiding rows, they can quietly sabotage your analytics too. Imagine pulling a report of active users and your dashboard proudly says 1,000. Except… 200 of those users are technically “deleted,” just still hanging around in the database like party guests who won’t take the hint. 🎃

By default, Prisma’s count, aggregate, and groupBy queries don’t know about your deleted_at filter. That means they’ll happily include ghost records unless you explicitly tell them not to.

For example, this innocent-looking query will count everyone, living and undead:

const totalUsers = await prisma.user.count();

Result: includes soft-deleted rows too.

To fix it, always add a filter for deleted_at: null:

const totalActiveUsers = await prisma.user.count({
  where: { deleted_at: null },
});

Now your numbers reflect reality (well, database reality at least).

The same applies to aggregations:

const avgPostsPerUser = await prisma.post.aggregate({
  _avg: { id: true },
  where: { deleted_at: null },
});

And groupings:

const postsByAuthor = await prisma.post.groupBy({
  by: ['authorId'],
  _count: { _all: true },
  where: { deleted_at: null },
});

Key takeaway 📝:

Always filter out deleted records in analytical queries.
Or better yet, bake this logic into your Prisma extension so you don’t have to remember it each time (your future self will thank you).

Otherwise, your analytics will be haunted by numbers that don’t match what your users actually see and nothing freaks out a product manager faster than “phantom” users.

Wrap-Up: Congrats, You’re Now a Soft Delete Whisperer

If you’ve made it this far, give yourself a pat on the back (or at least a strong coffee). You’ve survived the rollercoaster of soft deletes, from handling relationships (aka the family drama nobody asked for) to making sure your analytics don’t get haunted by ghost rows.

A few best practices to keep in mind:

Keep deletes consistent: Don’t mix hard and soft deletes without a clear strategy.
Guard your deleted_at column: Only your Prisma extension should touch it. Treat it like the “Do Not Disturb” sign on your database’s hotel door.
Index smartly: Adding an index on deleted_at can save you from painfully slow queries.
Watch your analytics: Remember, ghosts love to sneak into counts and aggregates.

The truth is, soft deletes aren’t magic, they’re just a way of giving your data a comfy afterlife instead of sending it straight to oblivion. But like anything in engineering, the devil’s in the details.

And hey, if your database seems like it needs therapy after all those “not-quite-deletes,” don’t worry, it’s just part of growing up in a world where nothing ever really goes away (except maybe your weekend plans).

Github Code (NextJS project with instructions to setup, execute and see soft deletes in action):
https://github.com/gauravnadkarni/prisma-soft-delete-article-code

Chrome Extension Development - Develop minimal app with TypeScript, React, Tailwind CSS and Webpack

Gaurav Nadkarni — Thu, 26 Dec 2024 09:00:00 +0000

Introduction

In this blog, we will explore how to set up and develop a Chrome extension using TypeScript, React, Tailwind CSS, and Webpack. We will create a minimal extension called "NoteMe" ✍️ to put our understanding to the test. Our extension will include the following features:

Allow users to add multiple notes for a given website
Enable users to view saved notes for a given website
Provide the option to delete notes for a given website
Save notes locally in the browser’s storage
Optionally sync notes with a backend for cloud storage

Refresher

In this blog, we will learn how to build a Chrome extension using modern technologies. This guide assumes that you already have some familiarity with building and uploading an extension to Chrome during local development. If you are new to this or need a detailed walkthrough of the basics, I recommend checking out my previous blog: Link

Extension sneak peek

The extension will include the following components:

Toggle Button: A button to open and close the sidebar.
Sidebar: A versatile panel where users can: Write new notes. View saved notes. Delete saved notes. Sync notes with the backend (provision available in the code, though no backend is connected currently).
Popup: A small window allowing users to reposition the toggle button (used to open/close the sidebar) at prespecified positions on the screen Note: While there’s no backend integration in this implementation, the code includes provisions to connect a backend in the future.

Below are screenshots showcasing how the extension will look upon completion:

Prerequisites

Before diving into this tutorial, ensure you have the following tools installed on your system:

Node.js (v18.16 LTS or later)
NPM (Node Package Manager, bundled with Node.js)
TypeScript
Webpack
VS Code Editor (or any code editor of your choice)

Extension from 40,000 Feet

The figure above provides a high-level overview of the internal workings of this extension. Here are some key points we can derive from the diagram:

The content script interacts directly with the DOM of the parent web page, enabling it to modify the page's content.
Popup, background, and content scripts communicate with each other through Chrome's runtime messaging system.
For tasks related to Chrome storage or backend API calls, content or popup scripts delegate the responsibility to the background worker using the runtime messaging system.
The background script acts as the sole mediator with the app backend and Chrome's storage. It also relays notifications, if any, to other scripts using runtime messaging.
Popup and content scripts exchange information directly through Chrome's runtime messaging system.

Setup of the extension

While Chrome extension projects don’t mandate a specific project structure, they do require a manifest.json file to be located at the root of the build directory. Taking advantage of this flexibility, we’ll define a custom project structure that helps organize different scripts effectively. This structure will enable better code reuse across scripts and minimize duplication, streamlining our development process.

Step 1: Create a basic directory structure for the project

To get started, we’ll set up a foundational directory structure for the project. You can use the following bash script to create the basic structure along with the manifest.json file:

#!/bin/bash

bash_script_absolute_path=$(pwd)
declare public_paths=("public" "public/assets" "public/assets/images")
declare source_paths=("src" "src/lib" "src/scripts" "src/scripts/background" "src/scripts/content" "src/scripts/injected" "src/scripts/popup" "src/styles")
declare public_directory_path="public"
declare manifest_file="manifest.json"
declare project_name="note-me"

create_directory () {
    if [ ! -d "$1" ]; then
        mkdir ${1}
    fi
}

create_file () {
    if [ ! -e "$2/$1" ]; then
        touch $2/$1
    fi
}

create_public_directories () {
    for public_path in "${public_paths[@]}";
    do
        create_directory $public_path
    done
}

create_source_directories () {
    for source_path in "${source_paths[@]}";
    do
        create_directory $source_path
    done
}

execute () {
    echo "creating project struture at "${bash_script_absolute_path}
    create_directory $project_name
    cd $bash_script_absolute_path"/"$project_name
    create_public_directories
    create_source_directories
    create_file $manifest_file $public_directory_path
    echo "done creating project struture at "${bash_script_absolute_path}" with project name "$project_name
}

execute

Ensure that your directory structure resembles the one shown in the screenshot below.

Step 2: The `manifest.json` file located in the `public` directory should be structured as shown below:

{
    "manifest_version": 3,
    "name": "NoteMe",
    "version": "1.0",
    "description": "A Chrome extension built with React and TypeScript using Webpack.",
    "action": {
      "default_popup": "popup.html",
      "default_icon": "app-icon.png"
    },
    "background": {
      "service_worker": "background.js",
      "type": "module"
    },
    "content_scripts": [
      {
        "matches": ["<all_urls>"],
        "js": ["content.js"],
        "run_at": "document_end"
      }
    ],
    "permissions": [
      "storage",
      "activeTab",
      "scripting",
      "webNavigation"
    ],
    "host_permissions": ["<all_urls>"],
    "web_accessible_resources": [
      {
        "resources": ["styles.css", "sidebar-open.png", "sidebar-close.png"],
        "matches": ["<all_urls>"]
      }
    ]
  }

Points to note:

The file extensions are .js because the .ts files will be compiled into .js files, which are required at runtime in the Chrome environment.
The matches field uses <all_urls> as its value, enabling the extension to operate on any webpage loaded in Chrome.
Three image files are referenced: app-icon.png, sidebar-open.png, and sidebar-close.png. You can find these files in the repository linked at the end of this blog.
The manifest.json file must be placed at the root level of the dist directory after the project is built. To ensure this, we need to configure the webpack settings to move it appropriately during the build process.

Step 3: Initialize npm and Install Dependencies

Start by initializing npm in your project using the following command: npm init -y
Add the necessary development dependencies to the devDependencies section of your project. Run the following command: npm i --save-dev @types/chrome @types/react @types/react-dom autoprefixer copy-webpack-plugin css-loader mini-css-extract-plugin postcss postcss-loader style-loader tailwindcss ts-loader typescript webpack webpack-cli webpack-dev-server
Add the runtime dependencies needed for running the project: npm i --save react react-dom

Step 4: Create files referenced in the `manifest.json`

Create following files which are referenced in the manifest.json: backgroun.ts, content.ts and popup.html.

background.ts: Create this file in the src/scripts/background directory
content.ts: Create this file in the src/scripts/content directory
popup.html Create this file in the public directory

Step 5: Update `popup` and `background` Code

Add the following code to the popup.html file in the public directory:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <link rel="stylesheet" href="styles.css" type="text/css" />
    <title>Popup</title>
  </head>
  <body>
    <div id="root"></div>
    <script src="popup.js"></script>
  </body>
</html>

Note:
This file acts as the popup interface that appears when the user clicks on the extension name in the Chrome browser. The styles.css and popup.js files will be generated in subsequent steps, so please follow along.

Add the following code to the background.ts file in the src/scripts/background directory:

import { onAppInstalled, onMessage } from "../../lib/worker";

(() => {
    chrome.runtime.onInstalled.addListener(onAppInstalled);
    chrome.runtime.onMessage.addListener(onMessage)
})();

Note:

The code above installs two listeners:

The function registered by chrome.runtime.onInstalled.addListener executes whenever the extension is installed in the browser. This can be used to initialize Chrome storage or a backend (if applicable) with a predefined state.
The function registered by chrome.runtime.onMessage.addListener executes whenever the background script receives a message from the content or popup scripts.

Additionally, the import statement brings in listeners from the src/lib directory. The core app logic is built in src/lib, enabling reuse across different contexts (e.g., content and background scripts).

Step 6: Walkthrough of the `src/lib` Directory

The src/lib directory houses the core logic of the extension. Below is an overview of its structure and key components:

components Directory: Contains all the React components used in the extension.
lib/components/ContentApp.tsx: Acts as the container component for the content script.
lib/components/NoteMePosition.tsx: Contains the component responsible for the popup script.
helpers.ts: Includes helper functions used throughout the extension.
storage-model.ts: Manages interactions with Chrome's local storage. For details about the structure of the data stored, refer to this file along with types.ts.
types.ts: Defines the custom types used in the extension.
worker.ts: Contains callbacks for background event listeners.

For detailed implementation, please refer to the actual code in the repository.

Step 7: Mounting React Components

In this step, we mount the React components for rendering. These components are mounted in two different scripts:src/scripts/content/content.ts and src/scripts/popup/popup.ts.

Popup Script: Found in src/scripts/popup/popup.ts.

(() => {
  const container = document.createElement("div");
  container.id = "note-me-position-component-root";
  document.body.appendChild(container);
  const root = ReactDOM.createRoot(container);
  root.render(<NoteMePosition buttons={BUTTONS}/>);
})();

Content Script: Found in src/scripts/content/content.ts.

export const mountContentRootComponent = () => {
  const container = document.createElement("div");
  container.id = "note-me-component-root";
  const shadowRoot = container.attachShadow({ mode: "open" });
  document.body.appendChild(container);  

  const styleLink = document.createElement("link");
  styleLink.setAttribute("rel", "stylesheet");
  styleLink.setAttribute("href", chrome.runtime.getURL("styles.css"));
  shadowRoot.appendChild(styleLink);

  const shadowContainer = document.createElement("div");
  shadowRoot.appendChild(shadowContainer);
  const root = ReactDOM.createRoot(shadowContainer);
  root.render(<ContentApp />);
};

key points:

Separate Mounting Scripts: The popup and content scripts operate in different contexts
Popup Script: Runs within the context of the popup.html webpage in which it is loaded.
Content Script: Runs within the context of the main webpage loaded in the browser.
Shadow DOM for Content Script:
- Styles injected by the content script could potentially affect the parent webpage's appearance.
- To prevent this, we use the Shadow DOM to encapsulate the styles, ensuring they remain isolated within the extension.
- This is not necessary for the popup script, as it operates in its own isolated environment (popup.html).

Step 8: Configurations for Compiling and Building

Adding the configurations required for compiling and building the extension

To successfully compile and build the extension, we need to configure the following files:

postcss.config.js
tailwind.config.js
tsconfig.json
webpack.config.js

Key Points:

Default Settings: Wherever possible, default settings are provided to simplify the process and ensure focus remains on the primary goal—building a fully functional extension.
Details in Repository: For the complete configurations and detailed settings of these files, please refer to the code repository.

These configurations handle the TypeScript compilation, Tailwind CSS integration, and the overall Webpack build process for the extension.

Testing the extension

Generate the dist Directory: Run the following command to create the dist directory: npm run build
Upload to Chrome:
- Open Chrome and navigate to chrome://extensions/.
- Enable Developer Mode in the top-right corner.
- Click on Load Unpacked and select the dist directory.
Verify Installation:
- Once loaded, the extension's icon will appear on each page in the bottom-right corner by default.
Functionality Check:
- Position Control: Use the controls in the popup to change the position of the icon.
- Notes Feature: Notes are saved independently for each website and can be deleted for a specific site without affecting others.
Backend Simulation:
- While there is no backend connected currently, the code includes a provision to integrate with one.
- The current implementation mimics a backend connection using setTimeout and promises to simulate asynchronous interactions.

Here are some screenshots captured during the testing of the extension.

Key Takeaways

Here are a few key takeaways from this blog,

We explored how various components of the Chrome environment, such as content scripts, popup scripts, and background workers, communicate with each other using Chrome's runtime messaging system.
We learned how to configure and build a Chrome extension from scratch, including setting up the project structure, installing dependencies, and writing core functionality.
We discovered some good practices, such as:
- Enhancing code reusability across scripts for maintainability and scalability.
- Utilizing Shadow DOM in content scripts to prevent style conflicts with the parent webpage.

Glimpse Ahead

In the future, I plan to work on another blog where we will explore the process of publishing a fully functional Chrome extension to the Chrome Web Store. The goal of that blog will be to:

Develop an extension complex enough to solve a real-world problem.
Demonstrate the step-by-step process of publishing the extension to the Chrome Web Store.

Thank you for taking the time to read this blog! Your interest and support mean so much to me. I’m excited to share more insights as I continue this journey.

Happy coding!

github link: https://github.com/gauravnadkarni/chrome-extension-starter-app

This article was originally published on Medium.

Step Into Chrome Extension Development: Easy Setup with TypeScript and Webpack

Gaurav Nadkarni — Tue, 17 Dec 2024 07:34:46 +0000

As of December 2024, Chrome remains the most popular browser worldwide. Learning to develop extensions for Chrome can open exciting opportunities to explore browser-based development and enhance your understanding of how browsers work under the hood. The Chrome Web Store offers a vast array of extensions that allow users to customize the browser’s default behavior and extend the functionality of various websites.

In this blog, we’ll go through setting up a local development environment for creating Chrome extensions using TypeScript and Webpack. This guide is perfect for anyone looking to grasp the basics of Chrome extension development. By the end, you’ll have a functioning development environment ready to experiment with your first extension. Before diving in, make sure you have a foundational understanding of web technologies, JavaScript, and commonly used tools in the JavaScript ecosystem. Details are listed in the prerequisites section.

Quick Overview of Chrome Extension Components

Before we jump into the setup, let’s briefly understand some key components of a Chrome extension:

Popup : Manages the extension’s user interface but does not have direct access to the DOM of the parent web page.

Content Script: Has direct access to the DOM of the parent web page but runs in a separate execution context. This separation means it cannot directly access JavaScript objects of the parent page.

Injected Script : Shares the same execution context as the parent web page, allowing access to its DOM and JavaScript objects.

Background Script : Operates in an isolated context, with no direct access to the DOM or JavaScript objects of the parent page.

The Popup, Content, and Background scripts operate in the extension’s contexts, whereas the Injected script runs in the context of the parent web page. The parent page refers to the active web page on which the extension performs its functionality. Permissions and access to these pages are defined in the manifest.json file, which we’ll cover later in this blog.

Prerequisites

To follow along with this tutorial, ensure you have the following tools installed:

Node.js (v18.16 LTS)
NPM (Node Package Manager)
TypeScript
Webpack
VS Code Editor (or any code editor of your choice)

Setup

Every Chrome extension requires a file named manifest.json at the root level of the project. This file serves as the configuration blueprint for your extension, containing essential details about the project. While there’s no strict rule about the overall project structure, we’ll begin by creating this file and progressively build the project as outlined in this blog.

Before proceeding, ensure that all prerequisites are installed on your machine.

Follow the steps below to set up your project and its dependencies:

Create a directory for your project and go inside that directory. This will be the root of your project. Everything from here on will be based of the root of your project unless stated otherwise.

mkdir chrome-extension && cd ./chrome-extension

Create a file called as manifest.json

{
 "manifest_version": 3,
 "name": "My First Chrome App",
 "version": "1.0",
 "description": "A Chrome extension built with TypeScript using webpack.",
 "action": {
 "default_popup": "popup.html",
 "default_icon": "icon.png"
 }
}

Most of the content in the manifest.json is self explanatory except action object. The default_icon is the icon of your app that will appear next to your app’s name in Chrome and default_popup specifies the HTML file to display as a popup when the extension’s icon is clicked.

Create a file called as popup.html with the following content,

<html>
 <head>
  <title>First Chrome Extension</title>
 </head>
 <body>
  <h1>This is my app popup</h1>
 </body>
</html>

Include an image file named icon.png in the root directory. This will serve as your app’s icon, displayed in the Chrome toolbar. Make sure the image is in a supported format (e.g., PNG) and appropriately sized.

Quick Test with bare minimum setup

Before diving into more complex functionality, let’s test this basic extension to ensure everything is set up correctly. This initial test will serve as the foundation for our development process and confirm that changes we make later are working as expected.

Open Chrome’s Extension Management : Open Chrome and navigate to the Manage Extensions page by typing chrome://extensions/ in the address bar. This will take you to the Extensions screen.

Enable Developer Mode : Locate the Developer mode toggle at the top right of the screen and switch it on if it’s not already enabled. Enabling this mode allows Chrome to load extensions built locally in addition to those downloaded from the Chrome Web Store.

Load Your Extension : Click the Load unpacked button at the top of the page. Browse to and select the root directory of your project.

Verify Installation : Once loaded, your extension should appear in the list of installed extensions.

Render the Popup : Click on the My First Chrome App icon in the top-right corner of Chrome, just above the Manage Extensions button. This action should render the popup.html file, displaying the content you defined earlier.

If you have managed to get it to work then our first test was successful and we can build on this. If not then please read through the above content carefully to make sure that you have not missed any step along the way.

The next step is to create a package.json file for managing project dependencies. Run the following command:

npm init -y

This command initializes a package.json file with default values. If you’d like to customize it, omit the -y flag and answer the prompts interactively.

A default package.json file will look like this:

{
  "name": "chrome-extension",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}

Now we can install all the required dependencies into the project. You can use the following commands to do so.

npm install -D typescript — To install TypeScript and add it to the devDependencies section of package.json
npm install -D @types/chrome — To install types for Chrome and add it to the devDependencies section of package.json
npm install -D webpack — To install webpack into the project and add it to the devDependencies section of package.json
npm install -D webpack-cli — This is required because we will be doing a hot reload whenever we make a change to the codebase
npm i -D copy-webpack-plugin — This is required to copy any static assets into the output directory or the dist directory
npm i -D path — This is required to resolve the path of the static assets in the webpack configurations later on
npm i -D @babel/core @babel/preset-env babel-loader ts-loader — This is required to compile the code during the webpack build process

For the next test we will have to make this app work with typescript and webpack. We already have the required dependencies installed. Now we will have to create some configuration files and write some code to get this to work.

We are going to create two configuration files, one for TypeScript and other for webpack. Create a file called as tsconfig.json with following content.

{
  "compilerOptions": {
    "target": "ES6",
    "module": "commonjs",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true,
    "outDir": "./dist",
    "rootDir": "./src"
  },
  "include": ["src/**/*"]
}

The above is for TypeScript compiler to correctly identify the locations of .ts files and compile them properly. Per above configurations, the .ts files are expected to be present under the src directory or its sub-directories. and the transpiled .js files will be created in the dist directory.

Now create webpack.config.cjs file which will have the configurations required for building and generating the compiled files along with other static assets ex. images

// [webpack.config.cjs]
const path = require("path");
const webpack = require("webpack");
const CopyWebpackPlugin = require("copy-webpack-plugin");

module.exports = {
  mode: "development", // Use 'production' for production builds
  target: "web",
  devtool: "source-map",
  entry: {
   "popup": path.resolve(
      __dirname,
      "src/scripts/popup.ts"
    ),
  },
  output: {
    filename: "[name].js", // Output file name for each entry
    path: path.resolve(__dirname, "dist"), // Output directory
    clean: true, // Clean the output directory before each build
    libraryTarget: "umd", // Universal Module Definition
  },

  resolve: {
    extensions: [".ts", ".js"], // Resolve .ts and .js extensions
  },

  module: {
    rules: [
      {
        test: /\.ts$/,
        exclude: /node_modules/,
        use: [
          {
            loader: "babel-loader",
            options: {
              presets: ["@babel/preset-env"],
            },
          },
          "ts-loader",
        ],
      },
    ],
  },

  plugins: [
    new CopyWebpackPlugin({
      patterns: [
        {
          from: path.resolve(__dirname, "popup-style.css"), // Source directory
          to: path.resolve(__dirname, "dist"), // Destination directory
        },
        {
          from: path.resolve(__dirname, "content-style.css"), // Source directory
          to: path.resolve(__dirname, "dist"), // Destination directory
        },
     {
          from: path.resolve(__dirname, "icon.png"), // Source directory
          to: path.resolve(__dirname, "dist"), // Destination directory
        },
        {
          from: path.resolve(__dirname, "popup.html"), // Source directory
          to: path.resolve(__dirname, "dist"), // Destination directory
        },
        {
          from: path.resolve(__dirname, "manifest.json"), // Source directory
          to: path.resolve(__dirname, "dist"), // Destination directory
        },
      ],
    }),
  ],
}

Note: CopyWebpackPlugin copies the static assets from the source code to the dist directory.

Now create the required directories using the following command:

mkdir src/scripts -p

Inside the script directory, create a simple Typescript file with the following content,

src/scripts/popup.ts

(() => {
    const message:string = "This is a console statement from the popup script";
    console.log(message)
})();

The above code will print the message to the console whenever the popup is rendered. We also have to include the link of this popup.ts file (which will be compiled to popup.js file) in popup.html. Also, create files called popup-style.css and content-style.css. We can later use these files for styling the popup and other pages. So lets do that,

Include the links to popup-style.css and popup.js in popup.html that we created earlier

popup.html

....
<link href="popup-style.css" rel="stylesheet"/>
....
<script src="popup.js"></script>
....

Create popup-style.css file:

body {
    background-color: #d1bba2;
}

Create content-style.css file:

/* [content-style.css] */
/* just as placeholder */

Now its time to add the webpack related command to the package.json file so that we can build the extension.

{
 ....
 "script": {
  "build": "webpack --watch",
  ....
 }
 ....
}

Run the following command to start the build process:

npm run build

This command watches for changes in your files and rebuilds the project automatically.

Quick Test with bare minimum setup

We can do another test now to check if our webpack related configurations are working as expected. But before you try to test, delete the old extension from the first test where you had uploaded the projects root directory to Chrome. Now this time we will have to upload the dist directory as the compiled code will be in this directory and not the project’s root directory. After you upload the newer version of the extension and render the popup, right click on the popup and open the dev console and check if you can see the console statement from the popup.ts. The statement should be present, if not , please check for any mistakes done in the previous steps.

Enhancing the setup

At this point, we have a basic version of the extension which is functional but there are some components which we have to add so that we can do the local development with ease.

Until now we have seen popup component. Now its time to add the other components. Create three files namely injected.ts,content.ts\ and background.ts in the src/scripts directory with the following content,

src/scripts/injected.ts

(() => {
    const message:string = "This is a console statement from the injected script";
    console.log(message)
})();

injected.[ts|js] is a special file which has access to the Dom as well as the JavaScript object exposed by the parent site. We need to add this file to the host site dynamically using the content script.

Create content.ts file:

src/scripts/content.ts

(() => {
    const message:string = "This is a console statement from the content script";
    console.log(message);

    const script = document.createElement("script");
    script.src = chrome.runtime.getURL('injected.js'); // Load the script from the extension
    document.documentElement.appendChild(script);
    script.onload = function () {
      script.remove(); // Clean up once the script is loaded
 };
})();

Create background.ts file:

src/scripts/background.ts

(() => {
    const message:string = "This is a console statement from the background script";
    console.log(message)
})();

Now we will have to update the webpack.config.cjs file to add these three entries as the entry points.

// [webpack.config.cjs]
.....
{
.....
entry: {
    .......
    "content": path.resolve(
      __dirname,
      "src/scripts/content.ts"
    ),
    "background": path.resolve(
      __dirname,
      "src/scripts/background.ts"
    ),
    "injected": path.resolve(
      __dirname,
      "src/scripts/injected.ts"
    ),
  },
.....
}
......

As a last step, we will have to update the manifest.json file to include all these configurations so that Chrome’s environment can detect them.

// [manifest.json]
...
 "background": {
     "service_worker": "background.js",
     "type": "module"
    },
 "content_scripts": [
    {
  "matches": ["https://*.google.com/*"],
  "css": ["popup-style.css"],
     "run_at": "document_start"
    },{
     "matches": ["https://*.google.com/*"],
     "js": ["content.js"],
     "run_at": "document_end"
    }
  ],
  "permissions": [
        "scripting"
    ],
    "host_permissions": [
     "https://*.google.com/*"
    ],
    "web_accessible_resources": [{
     "resources": ["injected.js"],
     "matches": ["https://*.google.com/*"]
    }]
....

In the manifest.json above we configured the extension to work with google.com meaning this extension will execute its logic only when google.com is loaded in the browser. You can change this to any other website of your choice.

Quick Test with Enhanced setup

We can do the final testing now with the enhanced setup. Before proceeding, please make sure that you reinstall the app in chrome so that you avoid the issues due to mismatch with older version of the code. To see if all the components are working properly, check the different console.log statements. Remember that we have put console.log statements in four different files: injected.ts, background.ts, content.ts and popup.ts. There should be four messages logged in the console. So, here are the steps,

Stop the npm run build command in the terminal if it was running and start it again so that it picks up the new files that we just created
Remove and Install the app again
Open the popup from the extension settings screen, right click on that popup and open the developer console. You should see the messages coming from background script and popup script in this console
Open https://www.google.com in the browser in another tab
Right click on the opened google site and open developer console. You should be able to see the messages coming from content script and injected script

Congratulations on successfully setting up and running your first Chrome extension! If you encounter any issues, please double-check the steps you’ve followed to ensure everything is in place. Additionally, a link to the GitHub repository is provided at the end of this blog for your reference.

Key Takeaways

In this blog, we have learned how to set up a local development environment for Chrome extension development. Here are a few key takeaways:

We explored the main components involved in Chrome extension development.
We learned how to set up a development environment with TypeScript and Webpack.
We also covered how to set up and test the extension in Chrome.

Glimpse Ahead

I’m currently working on another blog where we’ll explore a simple use case for the Chrome extension, showcasing how all the components of the Chrome development environment we discussed in this blog come together to create a functional extension.

Thank you for taking the time to read this blog! Your interest and time are greatly appreciated. I’m excited to share more as I continue this journey. Happy coding!

GitHub link — https://github.com/gauravnadkarni/chrome-extension-starter-ts

This article was originally published on Medium.

DEV Community: Gaurav Nadkarni

A TypeScript Journey: When Type Safety Feels Like a Safety Harness… and Sometimes a 10 kg Stone on Your Feet

Introduction

My Background Coming from Java and Its Static Types

JavaScript and the Need for Typing

When I Found Type Safety to Be a Potent Solution

Why TypeScript Felt Potent:

Why Types Sometimes Felt Like Tying a 10 kg Stone to Your Feet and Running a Marathon

Why TypeScript Can Feel Heavy:

When Type Safety Didn’t Really Work

When I Choose JavaScript Over TypeScript

When I Choose TypeScript

My Takeaway

Building an Extendable Data Migration Utility in Java Using the Strategy Pattern

Introduction

Why the Strategy Pattern?

Defining the Strategy Interfaces

Implementing Strategies for GitHub

Context to Tie Strategies Together

Using the Strategies at Runtime

Outcome and Takeaways

Handling Different Data Formats

Wrap-up:

How to Ghost Your Data: Implementing Soft Deletes in Prisma

Introduction

Why Soft Deletes Are the Chill Way to Delete

Sketching Your Data’s Retirement Plan

Extending the Prisma Client: Teaching It New Tricks

Soft Deleting Records: Because Delete Buttons Need Therapy

Restoring Soft Deleted Records: Your Data’s Resurrection Button

Handling Relationships: The Awkward Family Drama

Transactions: Where My Brain Nearly Filed for Bankruptcy

Guarding Against Chaos: No deleted_at Updates on Create/Update

Unique Constraints: Can Two Ghosts Share the Same Email?

Possible ways to handle this:

Performance Tips: Because Nobody Likes a Slow Ghost Hunt

Counting, Grouping, and Other Math-y Things

Wrap-Up: Congrats, You’re Now a Soft Delete Whisperer

Chrome Extension Development - Develop minimal app with TypeScript, React, Tailwind CSS and Webpack

Introduction

Refresher

Extension sneak peek

Prerequisites

Extension from 40,000 Feet

Setup of the extension

Step 1: Create a basic directory structure for the project

Step 2: The manifest.json file located in the public directory should be structured as shown below:

Step 3: Initialize npm and Install Dependencies

Step 4: Create files referenced in the manifest.json

Step 5: Update popup and background Code

Step 6: Walkthrough of the src/lib Directory

Step 7: Mounting React Components

key points:

Step 8: Configurations for Compiling and Building

Key Points:

Testing the extension

Key Takeaways

Glimpse Ahead

Step Into Chrome Extension Development: Easy Setup with TypeScript and Webpack

Quick Overview of Chrome Extension Components

Prerequisites

Setup

Quick Test with bare minimum setup

Quick Test with bare minimum setup

Enhancing the setup

Quick Test with Enhanced setup

Key Takeaways

Glimpse Ahead

Guarding Against Chaos: No `deleted_at` Updates on Create/Update

Step 2: The `manifest.json` file located in the `public` directory should be structured as shown below:

Step 4: Create files referenced in the `manifest.json`

Step 5: Update `popup` and `background` Code

Step 6: Walkthrough of the `src/lib` Directory