DEV Community: Kaushik Mitra

Docker in the Wild: Use Cases & The Survival Commands

Kaushik Mitra — Thu, 26 Mar 2026 12:47:01 +0000

In my last post, we talked about what Docker is and why it’s more than just a buzzword. But knowing the "why" doesn't help when you're staring at a terminal screen wondering how to actually get a container to do something.

Now, let's look at where Docker lives in the real world and the specific needed for the day to day work.

The "Day-to-Day" Command Handbook 📝

If you’re going to work with Docker, these are the commands you'll find yourself typing over and over again.

1. `docker build -t <name> .`

Before you can run a container, you need an Image. Think of this as the "factory" step. You’re taking your code and your Dockerfile and baking them into a single package.

Pro Tip: Don't forget the . at the end—it tells Docker to look for the Dockerfile in your current folder!

2. `docker run <image>`

This is the "Let there be light" command. It takes that image you just built, pulls any missing pieces from the cloud, and starts the container.

Example: docker run nginx (Starts a web server immediately).

3. `docker run -d <image>`

The -d stands for Detached mode. Without this, your terminal is "stuck" inside the container process—if you close the window, the app dies. With -d, the container runs in the background like a silent ninja. 🥷

4. `docker ps`

Ever wonder, "Wait, is my database actually running?" docker ps is your status report. It shows you every container that is currently active, their IDs, and which ports they are using. Use docker ps -a if you want to see the ones that crashed or stopped, too.

5. `docker exec -it <container_id> bash`

Ever needed to "go inside" the container to check a config file or run a manual database migration? This is how you do it. exec stands for execute, and -it makes it interactive so you can actually type things inside.

Think of it as: SSHing into your container.

6. `docker logs <container_id>`

Is your app crashing? Did the database fail to start? docker logs is your first line of defense. It shows you everything the application has printed to the console (STDOUT).

Handy flag: Use docker logs -f to "follow" the logs in real-time as they happen. It’s like watching a live heart monitor for your code.

7. `docker stop <container_id>`

The polite way to tell a container, "Okay, shift's over. Go home." It gives the processes inside a chance to shut down gracefully.

Pro Tip: If a container is being stubborn and won't close, you can use docker kill, but it’s like pulling the power plug—use it sparingly!

8. `docker rm <container_id>`

Just because you stopped a container doesn't mean it's gone. It’s still sitting on your disk like a parked car. docker rm actually deletes the container instance.

Shortcut: Use docker rm -f $(docker ps -aq) to delete every container on your machine. (Use with caution!)

9. `docker rmi <image_id>`

If a container is a "running car," the Image is the "blueprints." Over time, you’ll end up with dozens of old versions of images taking up gigabytes of space. rmi (Remove Image) deletes those blueprints.

10. `docker system prune`

The Nuclear Option. ☢️
This is the single most useful command for when your Mac/PC screams "Disk Full." It deletes:

All stopped containers.
All networks not used by at least one container.
All "dangling" images (the ones that didn't get a proper name).
All build cache.
Warning: It’s a fresh start. You’ll have to re-download/re-build things next time you need them, but it usually saves me about 20GB of space every month.

Wrapping Up

Docker might seem like magic at first, but it’s really just about packaging your environment so you can stop worrying about "it works on my machine" and start focusing on writing code.

Now that you've mastered the single-container life, things get even more interesting when you have 5 or 10 containers talking to each other.

After firm grisp on manging single container, we can dive into the world of docker compose for using multiple container & networking between them so how can they talk to each other.

Please leave a comment below, if you've liked this article or have any kind of queries or suggestions for me.

Deep Dive into Docker: Is it Magic or Just a Fancy Box?

Kaushik Mitra — Wed, 25 Mar 2026 13:30:51 +0000

Ever heard the phrase, "But it works on my machine!"?

If you’ve been in tech for more than a week, you probably have. This phrase is the bane of every developer's existence. You spend hours setting up your local environment, only for the production server to throw a tantrum because the PHP version is slightly off or a specific library is missing.

This is where Docker enters the chat.

What exactly is a Container?

Think of a container as a literal shipping container.

In software, a Container is a lightweight, standalone package that includes everything needed to run an application: code, runtime, system tools, libraries, and settings.

Why do we even need it?

Before Docker, we used Virtual Machines (VMs) for project deployment and all. But VMs are "heavy." They include an entire guest Operating System. If you want to run three apps, you run three OSs. That’s a lot of RAM going to waste.

Docker is different. It shares the host machine’s OS kernel. It’s fast, starts in seconds, and uses way fewer resources.

The main wins:

Consistency: It works on your laptop, your colleague's Mac, and the AWS EC2 instance exactly the same way.
Isolation: App A needs Node 14, but App B needs Node 18? No problem. They live in their own little bubbles.
Portability: "Build once, run anywhere" isn't just a marketing slogan anymore.

The Catch: It’s not all sunshine and rainbows ⛈️

As much as I love Docker, we have to talk about the "Problem" with it:

Persistent Data: By default, containers are ephemeral. If the container dies, your data dies with it. You have to manage "Volumes" to keep your data safe.
The Learning Curve: Networking between containers can get messy (remember my post on DDEV routing? Yeah, Docker is doing the heavy lifting there).
Security: Since containers share the host kernel, a vulnerability in the kernel could potentially affect all containers.

As a whole Docker is great for Production Deployment and also for Local Development.

This was a short details of docker, in the next article I will share some basic commands that is essential for in the day to day usage of docker.

Please leave a comment below, if you've like this article or have any kind of queries or suggestions for me.

Magic behind DDEV & Lando Routing

Kaushik Mitra — Tue, 28 Oct 2025 11:14:57 +0000

Today we'll discuss how the these docker based local environments for development like ddev or lando works.
These tools makes everything magical, and the end user just needs to setup a project run commands like ddev start or lando start and all the docker containers will spins up and the user will be able to visit the web page by with the url .ddev.site or in case of lando .lndo.site.

😉 Spoiler Alert all these tools uses cheeky DNS mapping & reverse proxy like tool traefik.

This guide is perfect for beginners or intermediate developers looking to understand how containerized local dev environments like DDEV use Traefik for networking.

If you're new to tools like DDEV or Lando and don't know what they are used for, they are local development environment based on Docker. You can easily setup a development environment for Drupal or Wordpress or MERN/MEAN and many other frameworks. As they use Docker containers for installing dependencies local development becomes very easy.

Let's take an example with DDEV.
In DDEV you can setup a Wordpress Project simply with the following commands, considering DDEV is already setup on your system.

cd <project-directory-name>
ddev config --project-type=wordpress --docroot=.
ddev wp core download
ddev wp core install --url=https://<project-directory-name>.ddev.site --title="<Site Name>"
--admin_user=admin --admin_password=admin --admin_email=admin@example.com

Now after setting up the project, ddev start will spin up all the containers & run your site in the URL https://<project-directory-name>.ddev.site

Today we'll discuss how this internal routing of https://<project-directory-name>.ddev.site works to your local site.

This is mainly done in two phases

DNS Mapping

DNS or Domain Name Server mapping is done to assign an IP address to a specific domain. When you type https://google.com on the browser. The browser doesn't know what server to request & how it can serve the html. The domain https://google.com is being resolved to a IP & then the client or the browser requests the server. This is called DNS Mapping.
Now in order the browser to know that accessing a site with the URL https://<project-directory-name>.ddev.site needs to request it's own machine where the project belongs. The URL needs to be resolve to 127.0.0.1.
This custom DNS mapping is created for DDEV & Lando.
You can check this by resolving the URLs *.ddev.site or *.lndo.site

In this simple way, ddev or lando creates custom URL for local Development.

Proxy Server — Enter Traefik

Now that DNS mapping ensures *.ddev.site (or *.lndo.site) resolves to your local machine (127.0.0.1), the next question is: how does your browser’s request for
https://<project-directory-name>.ddev.site actually reach the correct container running your project?

This is where Traefik steps in.

Traefik is a modern reverse proxy and load balancer designed for containerized environments. It automatically discovers running containers and routes incoming HTTP/HTTPS requests to the right service — all without you lifting a finger.

In DDEV (and similarly in Lando), Traefik runs as a global container that listens on ports 80 (HTTP) and 443 (HTTPS). When you run ddev start, your project containers register themselves with Traefik through Docker labels. These labels contain routing information — such as the domain name (.ddev.site) and the internal container port (like 80 or 8080).

Here’s what happens under the hood when you visit https://<project-directory-name>.ddev.site:

Browser Request: Your browser sends a request to https://<project-directory-name>.ddev.site.
DNS Resolution: The *.ddev.site wildcard DNS resolves to 127.0.0.1, pointing to your local machine.
Traefik Intercepts: The request hits Traefik’s HTTPS listener (port 443). Traefik inspects the hostname .ddev.site and checks its internal routing table.
Container Discovery: Traefik, using Docker’s API, has already discovered that a container labeled Host(.ddev.site) exists. It knows this container’s internal IP and port.
Secure Routing: Traefik forwards the request securely to the correct container. It also handles SSL/TLS termination — meaning your site works seamlessly over HTTPS using Traefik’s automatically generated certificates.
Response: The container serves your app, and Traefik relays the response back to the browser.

So while it looks like you’re visiting a remote, hosted website at https://<project-directory-name>.ddev.site, you’re actually interacting with your own machine. Traefik quietly proxies everything behind the scenes — no hosts file edits, no manual configuration.

Diving into the details of how these local development environments handled routing was a great learning for me. In a future article we can try and implement similar kind of model with simple docker & docker compose and run our local sites with custom URL.

Please leave a comment below, if you've like this article or have any kind of queries or suggestions for me.

Setting up mailcow on mail server on an EC2 instance

Kaushik Mitra — Sun, 13 Apr 2025 09:55:31 +0000

Recently I've been exploring how we can create our own mail server with our own custom domains.

In my research I've come across a tool named mailcow.

So let's dive in to learn about mailcow, and how we can set it up in an AWS EC2 instance.

So what is `mailcow`?

From the official documentation, it is given that....

mailcow: dockerized is an open source groupware/email suite based on docker.

mailcow basically generates a docker-compose file for helping setup a mail server. It already comes with preconfigured components such as

acme - For creating Let's encrypt Certificates.
ClamAV - For scanning Anti-virus
Devcot - For IMAP/POP servers
MariaDB - For storing user information
SOGo - Integrated Webmailer
Memcached - Cache for the webmailer SOGo
Nginx - Web server for components of the stack
Olefy - Analysis of Office documents for viruses, macros, etc.
PHP - Programming language of most web-based mailcow applications
Postfix - MTA (Mail Transfer Agent) for e-mail traffic on the Internet
Redis - Storage for spam information, DKIM key, etc.
Rspamd - Spam filter with automatic learning of spam mails
Unbound - Integrated DNS server for verifying DNSSEC etc.
etc. etc.

How would we install mailcow then?

Installing & setting up a mailcow server is very easy, you would just need to basically run a docker-compose file for installation. Then everything can be done from the UI.

But, there are some prerequisites we need to follow....

Setting up an EC2 instance.

Our mail goal here would be to create an EC2 instance with sufficient RAM & necessary open ports on the server.

Note: For best experience it is recommended to use atleast 4GB RAM, that's why we are using t3.medium here.

For the creation of the instance I'm using terraform.

You can find the full source code from here.

First of all for our server we need a few necessary ports to be opened.
We can create a security group for this requirement like this...

resource "aws_security_group" "mailcow-security-group" {
  name        = "mailcow-sg"
  description = "Allow TLS inbound traffic"
  
  ingress {
    description = "SSH"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
  ingress {
    description = "SSH"
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
  ingress {
    description = "SSH"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "SSH"
    from_port   = 25
    to_port     = 25
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "SSH"
    from_port   = 465
    to_port     = 465
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "SSH"
    from_port   = 587
    to_port     = 587
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "SSH"
    from_port   = 143
    to_port     = 143
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "SSH"
    from_port   = 993
    to_port     = 993
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "SSH"
    from_port   = 110
    to_port     = 110
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "SSH"
    from_port   = 995
    to_port     = 995
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]

  }

  ingress {
    description = "SSH"
    from_port   = 4190
    to_port     = 4190
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "mailcow-sg"
  }
}

Now, we can create a EC2 instance with the Ubuntu image with the above security group, like this...

resource "aws_instance" "mailcow_server" {
  ami                    = "ami-0e35ddab05955cf57"
  instance_type          = "t3.medium"
  key_name               = aws_key_pair.deployer.key_name
  vpc_security_group_ids = [aws_security_group.mailcow-security-group.id]
  user_data = file("${path.module}/install-script.sh")
  tags = {
    Name = "mailcow-vm"
  }
}

During the creation of the EC2 instance we are including an install script for installing Docker & Docker compose.
Here is the script....

#!/bin/bash

echo "Starting Docker Install" >> "/home/ubuntu/install-logs"

# Add Docker's official GPG key:
sudo apt-get update
sudo apt-get install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# Add the repository to Apt sources:
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update
sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

echo "Completed Docker Install" >> "/home/ubuntu/install-logs"
echo "Manage Docker as a non-root user" >> "/home/ubuntu/install-logs"

sudo usermod -aG docker $USER
newgrp docker

Now, that we have setup the EC2 instance as needed, let's move on to our next requirements....

Setting up an DNS for the mail server

First of all we need a domain for this step, you can buy it from anywhere like namecheap or godady

I've bought my domain from namecheap, and added my domain to cloudflare for managing various DNS records.

For the basic mailserver we need atleast two DNS records - MX Record, A Record.

MX Record

A MX Record is basically used to point DNS servers where your domain is located.

Suppose someone trying to send a mail from a@gmail.com to your domain user@yoursite.com.

Now, the problem is how gmail would figure out where this user@yoursite.com is located. So gmail would the DNS server a MX record for yoursite.com.

We generally add a MX record for your domain to mail.yourdomain.com

For example, if you have a domain yousite.com

You would add a MX Record, like this

@ -> mail.yoursite.com

A Record

An A Record, is used to tell the DNS Servers where your site is.

Following the given example above, after adding the MX Record, you would need to add the A Record like this

mail.yourdomain.com -> IP Address

Now that we are done with the server configs, let dive in with the actual setup...

Installing Mailcow

Now that we have setup our server properly, for installing mailcow we need to just basically download the git repo of the mailcow and run the docker image...

Let's see, how can we do that...

Verify current user to have proper privilage

Before cloning the git repo, first we have to check if we have proper user privileges

Run this command

umask

The output of the above command should be 0022.

For EC2 instance, by default the output should not be as expected. We need to switch the user to root, for this to work.
You can do that by running

sudo su

Clone mailcow repo

Let's clone to the repo, into /opt directory and generate the configurations.

$ cd /opt
$ git clone git clone https://github.com/mailcow/mailcow-dockerized
$ cd mailcow-dockerized
$ ./generate_config.sh

Note: If you wan to change any of the configuration, you can edit the file mailcow.conf

Run the image

Now that we have setup all the things, let's run the docker compose in the background, and hope everything is working properly.

docker compose up -d

After the running the image, visit the domain you have setup with the A record. Like in our example we will open yourdomain.com

Now that you have installed mailcow, you manage various admin tasks from the UI.

Few links for managing mailcow

Admin portal can be accessed via /admin. The default username/password is admin/moohoo.

All Department portal can be accessed via /department. The default username/password is department/moohoo.

Using markdown to manage content to NextJS App Router

Kaushik Mitra — Tue, 26 Mar 2024 02:12:43 +0000

Recently I have been building my portfolio site using NextJs/TailwindCSS.
Here is the link to the site - Visit here
It's still a work in progress, here is the source code for the site.

In the site I have used markdown files to manage the Projects data on the site.

Today we will discuss how we can use the markdown files to generate contents for a NextJS site with Server Components and integrate with Typescript.

So let's dive in...

Why `next-mdx-remote`...

If we follow the official documentation there it is mentioned that how we can basically use .mdx to generate our JSX components which we can render on our site.

But following this way can be a bit difficult as it will be very difficult to manage dynamically generated content or if the markdown is coming from somewhere else like some CMS or some other place from the file system.

To solve this issue we can use a community package next-mdx-remote. This package actually compiles a given markdown string and generates HTML, so it will solve our problem of maintaining markdown if we want to scale in future and it is coming from some other database or something.

Integrating `next-mdx-remote` to React Server components in NextJS.

Installation

npm install next-mdx-remote

Basic Usage

As we are using react server components we can simply fetch the markdown data from a file and display it with the MDXRemote component.


// page.tsx

export default async function IndexPage() {

  const markdown_data = await getProject();

  if (markdown_data === "") {
    return notFound();
  }

  return (
    <>
     <MDXRemote source={markdown_data} />
    </>
  );

}

Advance Usage

We can setup our own custom components when generating the HTML form the Markdown files.

For this we can create our own component which will wrap the libraries MDXRemote component.

// mdx-remote.ts

import { MDXRemote, MDXRemoteProps } from "next-mdx-remote/rsc";

const components = {
  h1: (props: ComponentProps<"h1">) => <HeaderOne {...props}>{props.children}</HeaderOne>,
  h2: (props: ComponentProps<"h2">) => <HeaderTwo {...props}>{props.children}</HeaderTwo>,
  p: (props: ComponentProps<"p">) => <Paragragraph {...props}>{props.children}</Paragragraph>,
  img: (props: ComponentProps<"img">) => <MdxImage {...props} />,
  a: (props: ComponentProps<"a">) => <MdxLink {...props}>{props.children}</MdxLink>,
};

export function CustomMDX(props: MDXRemoteProps) {
  return (
    <MDXRemote
      {...props}
      components={{ ...components, ...(props.components || {}) }}
    />
  );
}

And these HeaderOne, HeaderTwo, etc can be simple components with our custom styles.

For example...

// HeaderOne.tsx

import { ComponentProps } from "react";

export function HeaderOne({ children, ...props }: ComponentProps<"h1">) {
  return (
    <h1 {...props} className="mb-6 mt-16 text-5xl">
      {children}
    </h1>
  );
}

// MDXImage.tsx

import Image from "next/image";
import { ComponentProps } from "react";

type MdxImageProps = ComponentProps<"img">;
export function MdxImage(props: MdxImageProps) {
  return (
    <div className="flex justify-center">
      <div className="border-4 border-primary">
        <Image
          {...props}
          src={props.src ?? ""}
          alt={props.alt ?? ""}
          width={500}
          height={300}
        />
      </div>
    </div>
  );
}

Now we have created our custom wrapper component for the MDXRemote we can use this in our server component.

// /projects/[title]/page.tsx

export default async function IndexPage({
  params,
}: {
  params: { title: string };
}) {

  const markdown_data = await getProjectWithTitle(params.title);

  if (markdown_data === "") {
    return notFound();
  }

  return (
    <>
     <MDXRemote source={markdown_data} />
    </>
  );

}

Now as we are using NextJS we can further more optise our site by staticly generating the page with generateStaticParams function

// /projects/[title]/page.tsx

...

export async function generateStaticParams() {
  return getProjectTitles();
}

The source code for the above can be found here

Conclusion

So, in conclusion we discussed how we can integrate this community package next-mdx-remote for managing content with markdown and also how we can use Typescript to add proper types and have proper type safe development.

If you have any discussions regarding the topic feel free to comment below.

Use bunx for running npm packages with lightning fast speed.

Kaushik Mitra — Mon, 11 Sep 2023 20:34:38 +0000

Introduction
Use Case for the package
Comparing with npx
Conclusion

Introduction

bun is the latest and greatest runtime for Javascript which ships with many features like built in Typescript support and testing support and etc. etc.. bunx, alias for bun x, is a package manger for bun which can be used for auto installing and running npm packages. We can you bunx just similarly like we use npx or yarn dlx.

According to this twitter post, bunx is 100x faster than npx, which means we can use bunx and run our npm cli with lightning fast speed.

Today we will discuss an use case of running a npm package with bunx and compare the result with running it with npx.

You can view the package from here, it is a simple package that I wrote which generates a random quote of Phil Dunphy from Mordern Family. You can also view a post that I have written with my learnings and take aways from creating this package.

Use case for the package

As the package phil-s-osophy just spits out basic string output we can pipe that to any program, like I have used to pipe the value in cowsay and added the whole thing at the bottom of my zshrc file to show text at every shell creation.

bunx phil-s-osophy | bunx cowsay

Comparing with npx

To compare my changes with the npx, I have created a function which will run the shell few times and time it.

timezsh() {
    for i in $(seq 1 10); do /usr/bin/time $SHELL -i -c exit; done
}

So after running both my program with bunx and npx I timed it to aroud 0.3 to 0.4s when running with bunx but when running with npx the program took around 2s to ran.

Note: there are many more things happening in my zshrc file, but I am ignoring this as they are running in bot scenarios.

Left running - bunx phil-s-osophy | bunx cowsay
Right running - npx phil-s-osophy | npx cowsay

Conclusion

So, in conclusion we have seen how bunx is so much faster than npx and how we can use this lightning fast speed to install and use packages for that great developer experience.

For more information about the bun, you can visit bun.sh.

Journey of creating and publishing a nodejs package with typescript & eslint support

Kaushik Mitra — Fri, 08 Sep 2023 22:26:38 +0000

Today we will discuss how I've written a npm package and published it to npmjs.

You can checkout the codebase from here

This is a simple package which just generates random quotes from Phil Dunphy, the lovable and hilarious character from the TV show Modern Family. I have chosen Phil Dunphy as I love Mordern Family and he is one of my favorite caracter from the show.

The target of this package was not to create something unique and useful for everyone (though if you are a fan of Phill Dunphy you may love this idea 😉), but it was to learn how we can use these technologies to build packages in a simple and efficient manner.

Technology Used

Typescript for writing the business logic and have used tsup for compiling to javascript files.
ESlint for linting the typescript code
Also have used Github Actions for linting the code whenever a new pull request is being created.

Setting up local environment for creating packages

For setting up a local environment, we can start like a basic node js project.

mkdir my_project
cd my_prject
npm init

After that we need to add the main entry point of our package as well as a bin file.

{
  "name": "phil-s-osophy",
  "version": "1.0.1",
  "description": "Phil Dunphy's amazing life lessons from Mordern Family.",
  "main": "./dist/index.js",
  "module": "./dist/index.mjs",
  "types": "./dist/index.d.ts",
  ...
  "bin": {
    "phil-o-osophy": "./dist/index.js"
  },
  "repository": {
    "type": "git",
    "url": "git+https://github.com/MitraKumar/phil-s-osophy.git"
  },
  "author": "MitraKumar",
  "license": "MIT",
  "bugs": {
    "url": "https://github.com/MitraKumar/phil-s-osophy/issues"
  },
  "homepage": "https://github.com/MitraKumar/phil-s-osophy#readme",
  ...
}

In my scenario since it I am compiling the javascript with tsup I've added the files in here.

And in the typescript file we need to add shebang in front of the file

#! /usr/bin/env node

After updating all this we can simply run npm install -g . from the project directory to use the package.

Project Setup with Typescript

The main business logic for the package is written in typescript and the logic is very simple, it's just accessing a random element from a list of quotes and printing it out. Again the project was not to create anything unique, it is just fun enough for me to learn these things.

For compiling typescript file I have used tsup as a dev dependency, which is very useful and intuitive for compiling to javascript files. To make this process seamless I've added a npm script to build the project.

For the configuration of tsup we need to create a tsup.config.ts file.

import { defineConfig } from 'tsup'

export default defineConfig({
  target: 'es2020',
  format: ['cjs', 'esm'],
  splitting: false,
  sourcemap: true,
  clean: true,
  dts: true
})

Then after adding this I added the build command in npm scripts and voila it all worked seamlessly.

{
  "name": "phil-s-osophy",
  ...
  "scripts": {
    ...
    "build": "tsup ./src"
  },
  ...
}

This is really helpful as we get the power of types and the seamless process of compiling to javascript files.

Linting with ESLint

Linting is must in a project, this is a small simple enough project but for a live project with many contributors linting is must otherwise without following a proper coding standard it will be difficult over time to maintain a project.

I have used ESlint for checking the linting of the project. Setting up ESLint is simple enough but we have to add few dependencies to help us out here...

in the package.json we need to add few of the dev dependencies such as

{
  ...
  "devDependencies": {
    "@typescript-eslint/eslint-plugin": "^6.6.0",
    "@typescript-eslint/parser": "^6.6.0",
    "eslint": "^8.48.0",
    ...
  }
}

We can install this dependencies by running

npm install -D eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin

After that we need to add a .eslintrc file, with some basic rulesets.

{
  "root": true,
  "parser": "@typescript-eslint/parser",
  "plugins": [
    "@typescript-eslint"
  ],
  "extends": [
    "eslint:recommended",
    "plugin:@typescript-eslint/eslint-recommended",
    "plugin:@typescript-eslint/recommended"
  ],
  "rules": {
    "@typescript-eslint/no-explicit-any": "error",
    "indent": ["error", 2],
    "linebreak-style": ["error", "unix"],
    "quotes": ["error", "double"],
    "semi": ["error", "always"]
  }
}

And all the configurations are done, now we can simply add a npm script eslint ./src --ext .ts to lint our files.

But this will cause an issue as ESLint will not trigger any typescript error, for that we can simply check it with tsc --noEmit ./src/index.ts. So for linting we can simply add a script like this tsc --noEmit ./src/index.ts; eslint ./src --ext .ts to run both of them sequentially.

Also we can add a script to fix the linting errors with ESlint.

{
  ...
  "scripts": {
    "lint": "tsc --noEmit ./src/index.ts; eslint ./src --ext .ts",
    "fix": "eslint ./src --ext .ts --fix",
    ...
  },
  ...
}

And voila, linting is also setup in our project.

Setting up Github Actions for checking coding standards

In a real world we probably cannot expect everyone to properly lint code and the Pushing it. So we need to setup a Github Action to generate a check for linting errors if any whenever a PR is being generated.

Setting up such action is pretty easy, we just need create a yml file in the directory .github/workflows like I've created a file .github/workflows/linter.yml

name: Code Checker

on:
  pull_request:
    branches:
      - main

jobs:
  linting:
    runs-on: ubuntu-latest
    name: Checking coding standards & type checking.
    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - name: Setup node environment
        uses: actions/setup-node@v3
        with:
          node-version: 'latest'
      - name: Install dependencies
        run: npm clean-install
      - name: Run linting & type checking
        run: npm run lint

This workflow file is mainly divided into three sections

name - Name of the workflow
Event - On which event the workflow will trigger, like in this scenario it will trigger on creating a Pull request against the branch main
Jobs - What jobs will run in this workflow.

Jobs also have several aspects to understand, the main thing being steps
Steps basically mentions what the a job will do in a sequential order, like here it is mentioned that the job will first checkout the repo, then setup node environment then install all dependencies and then run our lint script from above.

And that's it, now creating a PR will automatically run this jobs and will show a green check mark ✅

Conclusion

So in conclusion I will say, this was a fun simple enough project which helped me learn a lot of things. And if any of you have any idea of improving the project, even if it's a change in README file, you are more than welcome to submit a Pull Request and I will be happy to merge it.

mordern_navbar

Kaushik Mitra — Sun, 05 Jan 2020 00:01:24 +0000

my first post in this community, hope to get some love.

DEV Community: Kaushik Mitra

Docker in the Wild: Use Cases & The Survival Commands

The "Day-to-Day" Command Handbook 📝

1. docker build -t <name> .

2. docker run <image>

3. docker run -d <image>

4. docker ps

5. docker exec -it <container_id> bash

6. docker logs <container_id>

7. docker stop <container_id>

8. docker rm <container_id>

9. docker rmi <image_id>

10. docker system prune

Wrapping Up

Deep Dive into Docker: Is it Magic or Just a Fancy Box?

What exactly is a Container?

Why do we even need it?

The Catch: It’s not all sunshine and rainbows ⛈️

Magic behind DDEV & Lando Routing

Setting up mailcow on mail server on an EC2 instance

So what is mailcow?

How would we install mailcow then?

Setting up an EC2 instance.

Setting up an DNS for the mail server

MX Record

A Record

Installing Mailcow

Verify current user to have proper privilage

Clone mailcow repo

Run the image

Few links for managing mailcow

Using markdown to manage content to NextJS App Router

Why next-mdx-remote...

Integrating next-mdx-remote to React Server components in NextJS.

Installation

Basic Usage

Advance Usage

Conclusion

Use bunx for running npm packages with lightning fast speed.

Introduction

Use case for the package

Comparing with npx

Conclusion

Journey of creating and publishing a nodejs package with typescript & eslint support

Technology Used

Setting up local environment for creating packages

Project Setup with Typescript

Linting with ESLint

Setting up Github Actions for checking coding standards

Conclusion

mordern_navbar

1. `docker build -t <name> .`

2. `docker run <image>`

3. `docker run -d <image>`

4. `docker ps`

5. `docker exec -it <container_id> bash`

6. `docker logs <container_id>`

7. `docker stop <container_id>`

8. `docker rm <container_id>`

9. `docker rmi <image_id>`

10. `docker system prune`

So what is `mailcow`?

Why `next-mdx-remote`...

Integrating `next-mdx-remote` to React Server components in NextJS.