DEV Community: Dániel Gál

Developing a Node CLI App in an NX monorepo

Dániel Gál — Sun, 10 Mar 2024 21:55:53 +0000

Bare bones setup. Using NX version 17.

Create the app

npx nx g @nx/node:app --name cli --directory packages/cli --framework none --e2eTestRunner none --unitTestRunner none

Install Commander

npm i -S commander @commander-js/extra-typings

Configure targets

Modify the default build target's development configuration to include "watch": true.

{
  "name": "cli",
  "$schema": "../../node_modules/nx/schemas/project-schema.json",
  "sourceRoot": "packages/cli/src",
  "projectType": "application",
  "targets": {
    "build": {
      "executor": "@nx/esbuild:esbuild",
      "outputs": ["{options.outputPath}"],
      "defaultConfiguration": "production",
      "options": {
        "platform": "node",
        "outputPath": "dist/packages/cli",
        "format": ["cjs"],
        "bundle": false,
        "main": "packages/cli/src/main.ts",
        "tsConfig": "packages/cli/tsconfig.app.json",
        "assets": ["packages/cli/src/assets"],
        "generatePackageJson": true,
        "esbuildOptions": {
          "sourcemap": true,
          "outExtension": {
            ".js": ".js"
          }
        }
      },
      "configurations": {
        "development": {
          "watch": true
        },
        "production": {
          "esbuildOptions": {
            "sourcemap": false,
            "outExtension": {
              ".js": ".js"
            }
          }
        }
      }
    },
    "lint": {
      "executor": "@nx/eslint:lint",
      "outputs": ["{options.outputFile}"]
    }
  },
  "tags": []
}

Write a program

// packages/cli/src/main.ts
import { program } from "@commander-js/extra-typings";

program.command("list").action(async () => {
  const things = ["one", "two", "three"];
  things.forEach((thing) => console.log(thing));
});

program.parse();

Start the development server

npx nx run cli:build:development

This will watch for changes and recompile.

Run the program

node dist/packages/cli/main.js list

Output:

one
two
three

Grow your CLI App from here

Visit the Commander.js reference.

Quick and dirty Docker development environment for Node.js apps

Dániel Gál — Mon, 19 Apr 2021 07:59:44 +0000

This article is also available on Medium.

Pre-requisites

Files

Usage

Start the environment.

docker-compose up -d

Attach to the container in VSCode.

Enjoy! :)

When done, stop the environment.

docker-compose stop

Why?

I wrote an article on the benefits of using a Dockerized development environment. Check it out here:

9 reasons why you should use Docker as a development environment | by Dániel Gál | Medium

Dániel Gál ・ Apr 19, 2021 ・
danielgaldev.Medium

What is this good for?

A Node.js app can be:

an Express backend (eg. a REST API)
any JavaScript frontend — React, Angular, Vue
a CLI app written in JavaScript
any other type of JavaScript app

It is up to you what you make in this environment. I usually do React frontends.

Tips

When you are attached to the container in VSCode, the IDE's terminal opens a terminal session inside the container. Here you can execute commands directly inside your container without the need to attach to it from another external terminal like PowerShell.

You can reduce the time spent starting and stopping the environment by shortening your Docker commands. If you have multiple concurrent projects, this will save you time and annoyance. I also wrote an article on how to do this, read it here:

Speed up your Docker workflow with Bash functions | by Dániel Gál | Medium

Dániel Gál ・ Nov 2, 2020 ・
danielgaldev.Medium

After you opened the dev container once, you can return to it from the "Open recent..." (Ctrl+R) command of VSCode. You don't have to always do the "Attach to running container…" command.

You can extend this bare bones development environment with many different functionalities. I listed my suggestions here.

If you would like to install packages in the container, the best way is to create a Dockerfile, define the install commands inside and change the image property in the yml to build with the correct reference to the build context. Here is an example for ffmpeg and the Vercel CLI:

FROM node:14.5.0-alpine
RUN apk add ffmpeg
RUN npm i -g vercel

You could also install Git to get access to the version control tools inside VSCode while you are attached to the container. However, if you want to do version control efficiently inside the container, you will need to set up SSH and configure Git to be able to push your code. It is possible, but I am not a fan because it makes the setup more complex. I do version control on the host system in a separate VSCode window with the IDE's built-in Git tools and the Git Graph extension.

Explained, line-by-line

PROJECT_NAME=my-project
PORT=3000

Docker-compose can fetch the environment variables from a local .env file. The purpose of this is to avoid repetition in the docker-compose.yml.

image: node:14.5.0-alpine

I use the Alpine version of the Node image simply because it is small (40 MB compared to the :latest 344 MB). I also use fixed versions to avoid the image upgrading itself and breaking something when I'm in a rush. This way I can upgrade the image when I have the time.

working_dir: /usr/src/${PROJECT_NAME}

You can use any working directory you want inside the container, I just use /usr/src to avoid name collisions in the root of the filesystem. It also helps me differentiate the projects in VSCode's "Open recent..." menu — back when I used /app or /code everywhere, I didn't know which project's folder I'm about to open.

env_file:
  - .env

The environment variables defined in .env will be available inside the container. This is where I put my config options, passwords and secret keys for the app.

ports:
  - ${PORT}:${PORT}

There is a high chance I'm building a web app or a REST API, so I map a port of the container to the same port of the host system to be able to access my app or service in the browser.

volumes:
  - /usr/src/${PROJECT_NAME}/node_modules
  - .:/usr/src/${PROJECT_NAME}

I am mapping the project directory to the container's working directory so that the edits I make in the container propagate to the host system where I do my version control. I don't want the content of node_modules leaking into my host system however, so I defined that folder as a volume on its own. Otherwise the npm installs would be noticeably slower because the files need to be copied from the container to the host.

entrypoint: tail -F /dev/null

If I would start the container without this entrypoint, it would just exit and I would not be able to attach to it. This command makes the container run indefinitely.

For more advanced devcontainer options visit VSCode's Developing inside a Container article.

Thank you for reading to the end and have a wonderful day :)

Cover photo by Jefferson Santos on Unsplash

Speed up your Docker workflow with Bash functions

Dániel Gál — Mon, 02 Nov 2020 20:24:42 +0000

This article is also available on Medium.

Introduction

I am a web developer and I use docker-compose in all of my projects. Sometimes it is just one container for the frontend part of the app, sometimes it is the whole stack: client, api, database, proxy server.

I recently started using WSL2 as the backend of the Docker for Windows service, and for performance reasons I keep my projects on the Ubuntu VM. This means that I do the command line work in Ubuntu's terminal, which uses Bash.

If you are curious as to why I am using Docker everywhere, check out my article about the pros of using it as a development environment.

9 reasons why you should use Docker as a development environment | by Dániel Gál | Oct, 2020 | Medium

Dániel Gál ・ Oct 9, 2020 ・ 5 min read
Medium

The problem

Given the circumstances, I have to type many long commands to start up, manage and stop my stack. I would guess that I use some form of docker-compose at least 50 times a day, with the length of the command being 20-60 characters depending on the project. The history feature of Bash is not perfect either, pressing the up and down arrows until you find the command you are looking for requires more attention than you might expect.

Photo Soumil Kumar by on Pexels

The goal

I would like to substitute most of the commands I use by 2 or 3 character long mini-commands. I should choose short commands that you are not likely to use. I chose du, dud, ds, dd, da, dss and dus.

Note that I'm not going to define a shortcut to every Docker command, as that would be pointless. My goal is that I can use a mini-command at least 8 out of 10 times.

But there is a catch. There are some projects, where we have two different compose files: one for development and one for production. In this case, I would like to use the dev compose file.
This requires a -f docker-compose.dev.yml option.

The commands I will define bash functions for:

docker-compose up — starting the containers
docker-compose up -d — starting the containers in detached mode
docker-compose stop — stopping the containers
docker-compose exec <servicename> <command> — attaching to a running service with a shell of our choice
docker-compose up <servicename> -d — starting a specific service in detached mode
docker-compose stop <servicename> — stopping a specific service

As you can see some of these functions will have parameters, which will have default values.

The solution

I am going to define my functions in the home directory, in a file named .bash_functions. This file should be sourced at the beginning of the terminal session, so I extend my .bashrc file with the following code:

if [ -f ~/.bash_functions ]; then
    . ~/.bash_functions
fi

Now onto the .bash_functions file.

I start with the first part of the command. We need to determine if we need the -f option or not.

function set-compose-command {
    COMPOSE_COMMAND="docker-compose"
    if [ -f docker-compose.dev.yml ]
    then 
        COMPOSE_COMMAND="docker-compose -f docker-compose.dev.yml"
    fi
}

I will not call this function manually, however it will be executed at the beginning of every other function. It will set the COMPOSE_COMMAND variable in our current shell instance so the other functions just need to attach their specific task at the end. The logic is simple: if the docker-compose.dev.yml file exists, apply the -f option with the filename.

Next, I define 4 shortcuts that do not require parameters.

function dud {
    set-compose-command
    sh -c "$COMPOSE_COMMAND up -d"
}

function du {
    set-compose-command
    sh -c "$COMPOSE_COMMAND up"
}

function dd {
    set-compose-command
    sh -c "$COMPOSE_COMMAND down"
}

function ds {
    set-compose-command
    sh -c "$COMPOSE_COMMAND stop"
}

The next two functions require one argument each. Without an argument, they will fail.

# Stop service
function dss {
    if [ -z $1 ]; then
        echo "Please specify a service."
        return 1
    fi
    set-compose-command
    sh -c "$COMPOSE_COMMAND stop $1"
}

# Start service
function dus {
    if [ -z $1 ]; then
        echo "Please specify a service."
        return 1
    fi
    set-compose-command
    sh -c "$COMPOSE_COMMAND up -d $1"
}

The functions check if the user supplied at least one argument, and exit with a failing status if not.

The last function has two parameters, both of which have default values.

function da {
    local service=${1:-dev}
    local shell=${2:-sh}
    set-compose-command
    sh -c "$COMPOSE_COMMAND exec $service $shell"
}

The reason for the default values is that I attach to a sh shell in the container 90% of the time (I mostly use alpine images and they don't have bash), and if I only have one service in my compose file, I will most likely name it dev, hence the default service name.

Conclusion

My docker-compose workflow is now faster and also more comfortable. No more typing the same long commands over and over again.

This is me starting up an environment, making some changes inside and then stopping it when I'm finished:

den@workstation:~/work/myproject$ dud
Starting myproject_myservice_1 ... done
den@workstation:~/work/myproject$ da myservice
/usr/src/myproject # touch somefile.txt
/usr/src/myproject # ^D
den@workstation:~/work/myproject$ ds
Stopping myproject_myservice_1 ... done
den@workstation:~/work/myproject$

Photo by cottonbro on Pexels

Keep in mind that you might not need the exact functions I did, or you might need more. It would be best if you paid some attention to which commands you use most often in your workflow, and define functions for those.

You also don't have to be a bash expert or even an intermediate level script developer to write your custom functionalities. There are plenty of resources to help you, as long as you are not new to programming and know what to search for.

I hope you have a nice day. Work smarter, not harder.

If you're curious about Docker and want to try it out in development or in production, check out these articles to get started:

A Beginner-Friendly Introduction to Containers, VMs and Docker | by Preethi Kasireddy | freeCodeCamp.org | Medium

Preethi Kasireddy ・ Oct 29, 2019 ・ 13 min read
Medium

Learn Enough Docker to be Useful. Part 1: The Conceptual Landscape | by Jeff Hale | Towards Data Science

Jeff Hale ・ Dec 13, 2019 ・ 7 min read
towardsdatascience.com

9 reasons why you should use Docker as a development environment

Dániel Gál — Fri, 09 Oct 2020 20:47:50 +0000

I have been developing React apps in Docker for a few years now, and so far nothing was able to stop me from containerizing every project I get started with.

This article is perfect for you if you read about containers or already started playing around with them, but you are not yet sold on the idea of using them as a development environment. If you have no idea what a container is, check out the links at the bottom.

This is more of a "meta" writing about container based development, not a guide on getting started with it. If you are looking for some tutorials, hit up the search bar above.

Photo by Noel Broda on Unsplash

No clutter on your PC

Know the feeling of working on multiple projects and having 4 versions of Node, 2 versions of Python and 3 separate database management software installed on your machine? Do you have the habit of starting a new project every few months to try out a new trending technology, but during the struggle of setting it up and getting a "Hello World" app to work you lose your motivation?

With Docker, all the software required to run your app is inside the container. This gets us to the next reason:

No other software needed

At least not on the host computer (your machine). Given a fresh install of Windows, macOS or Linux, once you install Docker, you can just clone the project repository and fire up your app. If you set the environment up right, it should work out of the box.

Isolated environment

What happens in the container, stays in the container. You can install all the dependencies you want, it will not affect your host machine. The opposite applies too, the other software installed on your computer will not interfere with your app in the container.

Works anywhere

If a computer has Docker installed, you can develop your app on it without effort. If you want your friend or colleague involved in creating your app, they don't have to spend hours installing software and dependencies. The just need to give one universal command and they are ready to go. If you don't like taking your computer to and from the office you work at, you can have the same environment on both machines with Docker. You can even set it up on a server and attach to it remotely.

Photo by Steve Halama on Unsplash

Easy cleanup

Once you are done with a project, just delete the image and any containers you created, and you're good. It doesn't take up space on your machine anymore. If you change your mind, you can build it again with one single command. Without Docker, you would have to remember all the software you installed just to get a project running, and get rid of them individually to free your computer from the stuff you don't use anymore.

Easy on disk space

Not everybody has terabytes of SSD storage these days. Maybe you only own a 256 GB drive, like me. Working on multiple projects, having 5 different IDEs and many libraries installed takes its toll on your storage space. With Docker, if you put a project on hold, you can just delete its images and containers from your computer. You can easily build it again if you want to continue and you will get the same environment.

It is also possible to persist files across builds with the help of volumes, so you don't have to delete and recreate some parts of your app every time, for example a database.

Gateway to production

The skills learned trying to configure a Docker environment for the development process might come in handy when you're shipping your app. Chances are you will deploy it on some kind of cloud infrastructure that supports containers like Kubernetes.

CI/CD

Some CI/CD providers (like CircleCI) offer the possibility of using containers in your builds. Since your environment is already a container, little to no configuration is needed to make your app test and deploy itself automatically.

Photo by Yancy Min on Unsplash

VSCode Remote - Containers

This VSCode extension is so great, it deserves its own section. To be honest, it is the main reason why I wanted to share this knowledge with you.

Before this extension existed, if we wanted to edit the code in the container without restarting it every time we made a change, we had to mount the project folder as a volume. If you changed the file on the host computer, it changed in the container as well. This had (still has) some problems.

Technology reliant on filesystem events like live reloading were a pain to work with. They were not as reliable because the filesystem events did not happen in the container (a shortcoming of mounted volumes), and on many occasions polling was required, draining your computer's processing power just to watch file changes.

With VSCode Remote - Containers, these problems don't exist. You can attach VSCode to the container itself, open the project folder inside it and get to work. The file changes now happen inside the container, no need for polling or mounting the code as a volume.

Mounting the code is still a good idea though, if you want to use version control software on the host computer (a Git client like GitKraken for example).

Check out the VSCode docs on developing inside a container.

Conclusion

The community behind Docker based development environments is strong. The most popular languages, runtimes and frameworks like Node, Python and Ruby have a plethora of guides to help you Dockerize your development experience. If the reasons listed in this article made you curious about this way of creating software, make sure to try it out!

If you decide to go with Docker for your next project, check out these tips to improve your productivity:

Speed up your Docker workflow with Bash functions | by Dániel Gál | Medium

Dániel Gál ・ Nov 2, 2020 ・
danielgaldev.Medium

Other useful resources

Check out these writings on Docker and containers in general:

A Beginner-Friendly Introduction to Containers, VMs and Docker | by Preethi Kasireddy | freeCodeCamp.org | Medium

Preethi Kasireddy ・ Oct 29, 2019 ・
Medium

Learn Enough Docker to be Useful. Part 1: The Conceptual Landscape | by Jeff Hale | Towards Data Science

Jeff Hale ・ Dec 13, 2019 ・
towardsdatascience.com

This article is also available on Medium.

DEV Community: Dániel Gál

Developing a Node CLI App in an NX monorepo

Create the app

Install Commander

Configure targets

Write a program

Start the development server

Run the program

Grow your CLI App from here

Quick and dirty Docker development environment for Node.js apps

Pre-requisites

Files

Usage

Why?

9 reasons why you should use Docker as a development environment | by Dániel Gál | Medium

Dániel Gál ・ Apr 19, 2021 ・ danielgaldev.Medium

What is this good for?

Tips

Speed up your Docker workflow with Bash functions | by Dániel Gál | Medium

Dániel Gál ・ Nov 2, 2020 ・ danielgaldev.Medium

Explained, line-by-line

Speed up your Docker workflow with Bash functions

Introduction

9 reasons why you should use Docker as a development environment | by Dániel Gál | Oct, 2020 | Medium

Dániel Gál ・ Oct 9, 2020 ・ 5 min read Medium

The problem

The goal

The solution

Conclusion

A Beginner-Friendly Introduction to Containers, VMs and Docker | by Preethi Kasireddy | freeCodeCamp.org | Medium

Preethi Kasireddy ・ Oct 29, 2019 ・ 13 min read Medium

Learn Enough Docker to be Useful. Part 1: The Conceptual Landscape | by Jeff Hale | Towards Data Science

Jeff Hale ・ Dec 13, 2019 ・ 7 min read towardsdatascience.com

9 reasons why you should use Docker as a development environment

No clutter on your PC

No other software needed

Isolated environment

Works anywhere

Easy cleanup

Easy on disk space

Gateway to production

CI/CD

VSCode Remote - Containers

Conclusion

Speed up your Docker workflow with Bash functions | by Dániel Gál | Medium

Dániel Gál ・ Nov 2, 2020 ・ danielgaldev.Medium

Other useful resources

A Beginner-Friendly Introduction to Containers, VMs and Docker | by Preethi Kasireddy | freeCodeCamp.org | Medium

Preethi Kasireddy ・ Oct 29, 2019 ・ Medium

Learn Enough Docker to be Useful. Part 1: The Conceptual Landscape | by Jeff Hale | Towards Data Science

Jeff Hale ・ Dec 13, 2019 ・ towardsdatascience.com

9 reasons why you should use Docker as a development environment | by Dániel Gál | Medium

Dániel Gál ・ Apr 19, 2021 ・ Medium

Dániel Gál ・ Apr 19, 2021 ・
danielgaldev.Medium

Dániel Gál ・ Nov 2, 2020 ・
danielgaldev.Medium

Dániel Gál ・ Oct 9, 2020 ・ 5 min read
Medium

Preethi Kasireddy ・ Oct 29, 2019 ・ 13 min read
Medium

Jeff Hale ・ Dec 13, 2019 ・ 7 min read
towardsdatascience.com

Dániel Gál ・ Nov 2, 2020 ・
danielgaldev.Medium

Preethi Kasireddy ・ Oct 29, 2019 ・
Medium

Jeff Hale ・ Dec 13, 2019 ・
towardsdatascience.com

Dániel Gál ・ Apr 19, 2021 ・
Medium