DEV Community: 100x.crypto 🚀🚀

Understanding TypeScript Execution Tools: A Deep Dive

100x.crypto 🚀🚀 — Fri, 05 Dec 2025 07:06:14 +0000

When you start exploring TypeScript in Node.js, it's easy to get overwhelmed by all the tools, utilities, and concepts involved: tsx, ts-node, tsc, @types/node, tsconfig.json, CommonJS, and ES Modules. It's not always obvious what each of these does or why they even exist.

This blog post walks you through everything in a logical order:

A brief history of JavaScript and its module system
What Node.js is and how it handles modules
What TypeScript is and how it compiles to JavaScript
How to run TypeScript files using three different tools: tsc, ts-node, and tsx

By the end, you'll understand not only how to run .ts files, but why things work the way they do and how to avoid the classic Unexpected token 'export' errors.

Let's get started.

1. A Brief History of JavaScript

JavaScript follows a language specification called ECMAScript. Each version of ECMAScript (ES5, ES6, ES2020…) introduces new features to the JavaScript language. Below is a simplified overview of the major versions:

Name	Year	Notes
ES3	1999	Very old, still the foundation of modern JavaScript
ES5	2009	Big cleanup, added strict mode
ES6 / ES2015	2015	Added classes, `let`, `const`, and modules (`import`/`export`)
ES2016–ES2023	yearly	Regular yearly updates with smaller language improvements
ESNext	future	The next version; upcoming approved features not yet tied to a single release

Note: A module in JavaScript is a separate file that exports values (functions, variables, classes) and can be imported by other files. Modules help you break your code into reusable, isolated pieces.

Before ES6 (2015), JavaScript did not have a built-in module system. ES6 introduced native modules with the import / export syntax.

Example:

import fs from "fs";
const file = fs.readFileSync("example.txt", "utf8");
export { file };

2. What is Node.js

Node.js (or "Node" in short) was created in 2009, years before ES6 existed. Node is a JavaScript runtime environment which runs JavaScript outside the browser and provides additional functionality through APIs like fs, path, crypto, etc.

Because modules didn't exist yet, Node invented its own module system: CommonJS (CJS), which uses require() and module.exports syntax.

Example:

const fs = require("fs");
const file = fs.readFileSync("example.txt", "utf8");
module.exports = { file };

When ES6 modules arrived, Node could not support them immediately due to compatibility and ecosystem concerns. Years later, Node eventually added ESM support. But because millions of packages were already written in CommonJS and changing everything would break the ecosystem, Node decided to support both module systems.

How Node decides which module system to use

The type field in package.json tells Node.js how to interpret .js files:

When it's missing or "type": "commonjs", Node expects require / module.exports syntax in .js files.
When "type": "module", Node expects import / export syntax in .js files.

This setting affects only how Node interprets .js files, not how TypeScript compiles them (important to remember for later).

Node's dual module support (CommonJS and ES Modules) is one of the main sources of confusion when using TypeScript in Node.js. But now that you understand the historical context, you're ready to learn how TypeScript fits into all of this and how it gets compiled to JavaScript.

3. What is TypeScript

TypeScript (TS) is a typed superset of JavaScript (JS). Let's break down what that really means.

JavaScript example

In plain JavaScript, you might write a function like this:

function add(a, b) {
  return a + b;
}

Intuitively, the caller should pass numbers, but nothing enforces that. Calling

add("a", "b");

…is perfectly valid JavaScript, and it will return:

"ab"

…because JavaScript will convert it to string concatenation.

How TypeScript improves this

TypeScript adds optional static typing, which lets you describe what types values should have.

The same function in TypeScript:

function add(a: number, b: number): number {
  return a + b;
}

We explicitly state:

a must be a number
b must be a number
the function returns a number

If you try this:

add("hello", "world");

…TypeScript will give you a compile-time error, before the code runs. Catching mistakes without executing your code is one of the main benefits of TypeScript.

Type annotations in your code

The type annotations in your code are optional, meaning that you can add types but you don't have to. That is, you can write plain JavaScript inside a .ts file and TypeScript will still compile it.

If you omit types, TypeScript will try to infer them (e.g., const x = 5 becomes a number), and if it cannot infer a type, it falls back to the any type.

This allows you to adopt TypeScript's type system gradually at your own pace.

Type definitions for the runtime environment

To analyze your code, TypeScript must not only understand the types in the code you write, but also the types of the APIs provided by the runtime environment (e.g., browser DOM APIs or Node's built-in modules).

There are two environments you'll most commonly use with TypeScript:

Browser environment:

When you install TypeScript, it automatically includes DOM type definitions. These describe the APIs that browsers provide (e.g., window, document, fetch, setTimeout). TypeScript bundles their type definitions by default because many TypeScript projects are browser-based.

➡️ You don't need to install anything extra.

Node environment:

Node provides its own APIs that do not exist in JavaScript or the browser (e.g., fs, path, process). TypeScript does not bundle type defintions for Node by default.

So if you want to use Node APIs in TypeScript (e.g., import fs from "fs"), you must install:

npm install --save-dev @types/node

Without this package, TypeScript will complain:

Cannot find module 'fs'

➡️ Whenever you write TypeScript for Node.js and use Node APIs, you need to install @types/node.

Compilation of TypeScript to JavaScript

Browsers and Node.js cannot run TypeScript directly, they only understand JavaScript. Therefore, TypeScript must be translated ("compiled" / "transpiled") to JavaScript. To do that you need tools like tsc, ts-node or tsx.

These tools "strip out" the TypeScript types and produce valid JavaScript that Node.js or browsers can execute.

How TypeScript decides what JavaScript to emit

TypeScript uses a configuration file called tsconfig.json, located/created in the root of your project, which tells TypeScript how to compile .ts files into .js files.

The two most important settings are:

compilerOptions.target: Defines which version of JavaScript TypeScript should generate (e.g., ES5, ES2015, ES2020, etc.; see the history table above for all available options).
compilerOptions.module: Defines which module system the emitted JavaScript should use.
- "commonjs" → output uses require / module.export syntax
- "es2015" / "es2020" / "esnext" → output uses import / export syntax

Example tsconfig.json file:

{
  "compilerOptions": {
    "target": "ES2020",
    "module": "commonjs"
  }
}

This tells TypeScript:

"Compile my code to JavaScript that matches ES2020 features"
"Use CommonJS module syntax in the output"

If no tsconfig.json file is provided, TypeScipt defaults to:

{
  "compilerOptions": {
    "target": "ES3",
    "module": "commonjs"
  }
}

Puuh... that was a lot of background, but it's all essential context. With this foundation in place, we can now explore the different tools for compiling and running TypeScript.

4. Setup an example project

Let's create a fresh project with a simple TypeScript file:

mkdir my-typescript-project
cd my-typescript-project
npm init -y

Create hello.ts:

import { join } from "path";
console.log(join("folder", "file.txt"));

This uses ESM. But since package.json has no "type": "module", Node expects CommonJS, which creates a mismatch and is expected to result in an error.

Let's see how we can use tsc, ts-node and tsx to execute the scripts and how each of them addresses the mismatch.

5. Executing TypeScript with `tsc`

tsc is the official TypeScript compiler. It converts TypeScript into JavaScript so Node.js can run it.

Workflow:

hello.ts
    ↓
tsc compiles it to hello.js
    ↓
node runs hello.js

Installation and configuration

To use tsc, first install TypeScript:

npm install --save-dev typescript

Next, generate a tsconfig.json file:

tsc --init

Note: While tsc can compile files without configuration, it's best practice to use a tsconfig.json file.

This creates a configuration file with recommended settings, as shown below (comments and unused options were removed for clarity):

{
  "compilerOptions": {
    "target": "es2016",
    "module": "commonjs",
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "strict": true,
    "skipLibCheck": true
  }
}

We have already discussed target and module. Here is a brief explanation of the other options:

`esModuleInterop: true`

Allows importing CommonJS modules (i.e., files using require / module.exports syntax) into ES modules (i.e., files using import / export syntax).

Without it, you'd need:

import * as express from 'express';

With it, you can simply write:

import express from 'express';

This enables interoperability between CommonJS and ES packages.

`forceConsistentCasingInFileNames: true`

Enforces consistent casing in import paths to prevent issues on case-sensitive file systems. This prevents bugs where ./MyFile and ./myfile would be treated differently.

`strict: true`

Enables all strict type-checking options for better type safety. It catches:

implicity any types
null/undefined issues
incorrect argument types
uninitialized class properties
and more.

This is the setting that gives TypeScript its reputation for safety.

`skipLibCheck: true`

Skips type checking of declaration files (.d.ts) in node_modules to speed up compilation. Your code is still fully type-checked; only third-party library types are skipped.

Compilation

To compile your project, run:

npx tsc

This generates a .js file for each .ts file in your project (in our case, hello.js).

If you inspect hello.js, you will find the following:

"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
var path_1 = require("path");
console.log((0, path_1.join)("folder", "file.txt"));

You see the require() syntax because module: "commonjs" was set in tsconfig.json.

Run with Node

Now you can run hello.js with Node (note that it's .js, not .ts):

node hello.js

Notes on compiling single files

When you specify file names after tsc:

npx tsc hello.ts

you're invoking tsc in single-file mode.

In this mode, TypeScript ignores tsconfig.json and compiles the specified file(s) with it's built-in defaults (i.e. target: "es3" and module: "commonjs").

Try it out yourself:

Set module: "es2020" in tsconfig.json
Run npx tsc hello.ts -> You still get CommonJS syntax in the output

Only if you run npx tsc without file names, it will use the configuration specified in your tsconfig.json file.

Summary

Below the commands to install and execute TypeScript with tsc for quick reference (including installation of @types/node for completeness):

npm install --save-dev typescript @types/node
tsc --init
npx tsc
node file.js

(Replace file.js with the name of your file)

Further reading:

https://www.typescriptlang.org/docs/handbook/tsconfig-json.html

6. Executing TypeScript using `ts-node`

ts-node is a tool that allows you to run TypeScript files directly, without generating .js files. It transpiles your .ts code in memory and executes it immediately.

Workflow:

hello.ts
    ↓
ts-node transpiles & executes in memory (no .js files are created)

ts-node is great for development, quick scripts, and interactive use. It always respects your tsconfig.json. There are no special cases like in tsc where it may be ignored.

Installation and requirements

To use ts-node, install both ts-node and typescript:

npm install --save-dev ts-node typescript

Note: ts-node does not include TypeScript.
It is just a wrapper that asks the TypeScript compiler to transpile your file in memory.
Without installing typescript, ts-node will throw:
Error: Cannot find module 'typescript'

Running TypeScript with `ts-node`

Once installed, run your TypeScript file directly:

npx ts-node hello.ts

This:

Reads your tsconfig.json
Transpiles the file in memory
Executes it immediately

No .js file is created.

Summary

Below the commands to install and execute TypeScript with ts-node for quick reference (including installation of @types/node for completeness):

npm install --save-dev ts-node typescript @types/node
tsc --init
npx ts-node file.js

(Replace file.js with the name of your file)

7. Executing TypeScript using `tsx` (Easiest Option)

tsx is the simplest and most modern way to run TypeScript files.
It runs .ts files directly, without creating .js files, and requires zero configuration in most cases.

Workflow:

hello.ts
    ↓
tsx transpiles & executes in memory (no .js files are created)

The key difference compared to ts-node is that tsx handles many cross-environment details automatically. It works out of the box with:

ES Modules and CommonJS
JSX / TSX
TypeScript path aliases
JSON imports
.mjs, .cjs, .ts, .tsx, .jsx, .js files

…and requires almost no setup.

Installation

First, install tsx:

npm install --save-dev tsx

Unlike ts-node, tsx already bundles everything it needs to execute TS files. It does not require installing typescript separately, though most projects will have typescript installed anyway.

If you already installed TypeScript or ts-node earlier, uninstall them or start a fresh project so you can clearly see that tsx works without any additional setup.

Running TypeScript with `tsx`

Simply run your TypeScript file:

npx tsx hello.ts

That's it. No tsconfig.json required. No .js output. No module-system headaches.

tsx automatically:

Detects whether your project uses "type": "module"
Handles CommonJS and ESM differences
Applies sensible defaults
Loads TypeScript configuration if it exists
Avoids the Unexpected token 'export' errors that beginners often hit

It just works.

Tip: tsx also provides a watch mode for development:
npx tsx watch hello.ts
This automatically reruns your script whenever the file changes.

Summary

For quick reference:

npm install --save-dev tsx @types/node
npx tsx file.ts

(Replace file.ts with the TypeScript file you want to run.)

Absolutely — here is a polished and clear section “When to Use What”, matching the tone and structure of your existing sections.

8. When to Use What (`tsc` vs `ts-node` vs `tsx`)

You now know three different ways to run TypeScript:
tsc, ts-node, and tsx.
But which one should you actually use?

This section gives you a simple, practical decision guide.

✅ Use `tsx` when you want the easiest, fastest developer experience

tsx is ideal for:

small scripts
development environments
experimentation / prototyping
running files directly
building CLIs or dev tools
any situation where you don’t care about emitted .js files

Pros

Zero config
Just works with ESM and CJS
Bundles everything it needs
Fastest startup
No .js output clutter
Great watch mode

Cons

Not a build tool
Not ideal for production deployment (since nothing is emitted)

Recommendation:
Use tsx for 99% of development and daily scripting.

✅ Use `ts-node` when you need TypeScript execution that respects your project configuration

ts-node is ideal for:

long-running dev environments
debugging complex TS applications
environments that rely heavily on your TypeScript configuration
older projects that already use ts-node
scripts/workflows integrated into existing tooling

Pros

Always respects tsconfig.json
No .js files emitted
Supports advanced TS features
Embedded in many mature TS ecosystems

Cons

Slower startup than tsx
Requires installing typescript
More sensitive to ESM/CJS configuration
Requires more setup

Recommendation:
Use ts-node when you have a configured TypeScript project and need the compiler settings to be honored exactly.

✅ Use `tsc` when you need actual `.js` output (production builds)

tsc is ideal for:

production deployments
packaging libraries
creating build artifacts
publishing to npm
bundling workflows (paired with tools like esbuild, webpack, tsup, etc.)

Pros

Produces clean .js files
Lets Node run without any TS tooling
Uses static analysis to catch errors before runtime
Needed for code that must run in production environments

Cons

Requires a config
Two-step workflow: compile → execute
Can be slow without incremental builds

Recommendation:
Use tsc for build steps, production bundles, and anything you want to ship or deploy.

9. Final words

We covered a lot of ground, from JavaScript history, to module systems, to TypeScript configuration, all the way to three different execution tools. With this foundation in place, you're well-positioned to explore more advanced TypeScript features and deepen your understanding at your own pace.

Run TypeScript Files in 30 Seconds

100x.crypto 🚀🚀 — Sun, 23 Nov 2025 16:13:08 +0000

If you have a TypeScript script (.ts file) and want to run it quickly without setting up a full build pipeline or compiling anything manually, this guide shows you how to run it in 30 seconds.

Environment: I'm using WSL (Ubuntu) on Windows, but this works the same on Linux and macOS. I also assume you already have Node.js installed.

Step 1: Create a New Project Directory

mkdir my-typescript-project
cd my-typescript-project
npm init -y

Step 2: Install tsx

npm install --save-dev tsx

tsx runs TypeScript files directly without compiling to JavaScript.

Step 3: Run Your TypeScript File

npx tsx your-file.ts

That's it.

Example

Let's look at a practical example. Suppose you have a JSON file exported from a Discord chat and want to convert it to Markdown.

data.json:

[
  {
    "thread_id": 1,
    "thread_name": "Example Thread",
    "message_count": 2,
    "messages": [
      {
        "message_id": 1,
        "author_name": "Alice",
        "timestamp": "2025-01-15T10:00:00Z",
        "content": "Hello, world!",
        "attachments": []
      },
      {
        "message_id": 2,
        "author_name": "Bob",
        "timestamp": "2025-01-15T10:05:00Z",
        "content": "Hi there!",
        "attachments": []
      }
    ]
  }
]

convert-to-markdown.ts:

import * as fs from 'fs';
import data from './data.json';

interface Message {
  message_id: number;
  author_name: string;
  timestamp: string;
  content: string;
  attachments: any[];
}

interface Thread {
  thread_id: number;
  thread_name: string;
  message_count: number;
  messages: Message[];
}

const threads: Thread[] = data as Thread[];
let markdown = '# Threads\n\n';

threads.forEach((thread) => {
  markdown += `## ${thread.thread_name}\n\n`;

  thread.messages.forEach((message) => {
    const date = new Date(message.timestamp).toLocaleString();
    markdown += `### ${message.author_name} - ${date}\n\n`;
    markdown += `${message.content}\n\n`;
    markdown += '---\n\n';
  });
});

fs.writeFileSync('output.md', markdown);
console.log('Converted to output.md');

Set up a project directory as described earlier and place both files inside it.

Then run:

npx tsx convert-to-markdown.ts

output.md is created.

Quick reference

# 1) Setup
mkdir my-typescript-project
cd my-typescript-project
npm init -y
npm install --save-dev tsx

# 2) Add the .ts file into the directory

# 3) Run
npx tsx your-file.ts

Symlinks

100x.crypto 🚀🚀 — Sun, 02 Nov 2025 18:59:08 +0000

🧩 Intro

In my previous blog post on how to back up and sync your terminal configuration with a GitHub dotfiles repo, we had to manually copy configuration files into the ~/dotfiles directory every time we wanted to push updates to GitHub:

cp ~/.bashrc ~/dotfiles/bashrc
cp ~/.bash_aliases ~/dotfiles/bash_aliases

If you changed ~/.bashrc or ~/.bash_aliases, you had to remember to copy them back into ~/dotfiles before committing.

That’s tedious and easy to forget. What if the files stayed in sync automatically? That’s where symlinks come in handy.

🪄 What is a symlink?

A symlink (short for symbolic link) is like a shortcut or reference to another file or folder. It points to the original location and behaves like the real file, meaning you can open, read, or edit it just like the original. If you’ve ever created shortcuts on Windows, it’s the same concept.

Think of it like this:

📁 Original file: ~/.bashrc
📎 Symlink: ~/dotfiles/bashrc → points to that original file

When a program or shell tries to read ~/dotfiles/bashrc, the system redirects it to the real file ~/.bashrc.

⚙️ Syntax

ln -s <original> <link>

Where:

<original>: the original file or directory
<link>: the new symlink (the name/path of the shortcut you want to create)
The -s flag stands for symbolic

Example:

ln -s ~/.bashrc ~/dotfiles/bashrc

✅ Result:

This creates ~/dotfiles/bashrc as a shortcut to ~/.bashrc.
When you edit ~/.bashrc, the change is immediately reflected in ~/dotfiles/bashrc.
When you edit ~/dotfiles/bashrc, the change is immediately reflected in ~/.bashrc.
You can commit and push ~/dotfiles/bashrc to GitHub without manual copying.

📌 Quick symlink cheatsheet

Command	Meaning
`ln -s <original> <link>`	Create a symbolic link
`ls -l`	Show links to the original
`rm <link>`	Delete only the symlink (not the original file)
`readlink <link>`	Show where the symlink points

💡 Things to keep in mind

Name collisions: If ~/dotfiles/bashrc already exists, the ln -s command will fail. Delete or rename the existing file first via

rm ~/dotfiles/bashrc

Deleting the symlink does not delete the original file; it just removes the shortcut.
Deleting or moving the original file will break the symlink.
If the original file has been deleted, editing the symlink may either create a new file at the path it points to or throw an error (depending on your editor). So, as long as the original exists, both stay perfectly in sync.
File permissions and metadata: A symlink has its own minimal permissions (lrwxrwxrwx), which don’t affect the original. Running ls -l shows the link’s metadata, not the original’s. Use ls -lL to view the original’s details.
Relative vs. absolute paths: A symlink stores the path string to its target, either absolute (e.g., /home/user/.bashrc) or relative (e.g., ../.bashrc).
- Absolute symlinks contain the full path. They work as long as the original stays in the same place, but will break if the file is moved.
- Relative symlinks use a path relative to the link’s own location. These are more portable. If you move the whole directory structure (e.g., a Git repo or project folder), the links still work because the relative relationship remains the same. You can create a relative symlink like this:

  ln -s ../real_folder shortcut

Symlinks can point to directories as well as files.

✨ Final Thoughts

Symlinks are a simple yet powerful way to automate your dotfiles workflow.
They remove the need for manual copies and keep your configurations perfectly in sync across devices.

Note: I use ChatGPT to help me gather information and shape these posts, but I always test the commands myself and add my own insights to make them easier to understand. This blog is my personal record of what I learn as I go deeper into Linux. If it helps someone else too, even better!

How to install Git on Ubuntu and push your first repository to GitHub

100x.crypto 🚀🚀 — Fri, 17 Oct 2025 15:22:29 +0000

Git is the most widely used version control system in the world. If you're building software, writing scripts, or even just managing configuration files, it's an essential tool to learn.

In this guide, we'll walk step-by-step through:

🛠️ Installing Git on Ubuntu
✏️ Configuring your Git identity
📁 Creating a local repository
🔑 Setting up SSH access to GitHub
🌐 Connecting it to GitHub
🚀 Pushing your first commit

Prerequisite: You'll need a GitHub account before starting. If you don't have one yet, sign up. It's free and takes just a minute.

🛠️ Step 1: Install Git on Ubuntu

Check if Git is already installed:

git --version

If you see command not found, continue with the installation steps below. If it's already installed, move on to Step 2.

sudo apt update
sudo apt install git -y

The -y flag "yes" automatically answers "yes" to any prompts during the installation.

Verify the installation:

git --version

If successful, it should return something like this:

git version 2.34.1

✏️ Step 2: Configure your Git identity

Git needs to know your name and email so it can label your commits. You'll see them locally in git log and on GitHub next to each commit.

To set your name and email run the following commands:

git config --global user.name "Your Name"
git config --global user.email "your-email@example.com"

user.name does not have to match your GitHub username. It's just a label on your commits. Use your real name or a handle, up to you.

user.email should match one of the emails registered with your GitHub account if you want your commits linked to your profile. If it doesn't, commits still appear, but won't show your avatar or count toward your contribution graph.

Verify your settings:

git config --global --list

The output should look like this:

user.name=Your Name
user.email=your-email@example.com

🔑 Step 3: Set up SSH access to GitHub

Using SSH means you won't have to type your username and password every time you push code to GitHub.

3.1. Check existing SSH keys

Let's first check whether you have existing SSH keys.

ls -a ~/.ssh

If you see files like id_ed25519 and id_ed25519.pub, you already have a key pair and you can continue with Step 4.

If you don't have any or wish to create new ones, continue with this step.

3.2. Generate a new SSH key

📌 Warning: If you generate a new key with the same name as an existing one, you will overwrite it and any service (like GitHub) using the old key will stop recognizing your machine until you add the new one.

Generate an SSH key:

ssh-keygen -t ed25519 -C "test-key"

-t defines the key type which is ed25519 in our case.

-C adds a comment to your SSH key. It's just a label to help identify the key later if you generate multiple ones. It's not used for authentication or commit association.

You'll be asked to enter a name for the new key. If you simply press Enter, the key will be saved under the default name id_ed255119. To avoid overwriting any existing keys, append the proposed name with _test. Make sure to include the full path and replace walodja1987 with your Ubuntu username:

/home/walodja1987/.ssh/id_ed25519_test

You'll be asked to set a password to protect your keys. It's optional but recommended.

3.3. Start the SSH agent and add your key

Before we run the commands, let's briefly understand what an SSH agent is:

When you generated the key with ssh-keygen, it was saved as a file on your disk (/home/walodja1987/.ssh/id_ed25519_test).
That file contains your private key, but SSH clients like Git won't use it automatically. And if it's protected by a passphrase, they can't read it directly without your help.
An SSH agent is a small background program that runs in your session and remembers unlocked keys in RAM. It handles authentication automatically any time you connect to a server like GitHub over SSH, without asking you to type the passphrase again.
Think of ssh-keygen as creating a key and storing it in a safe. ssh-add is like unlocking it once and handing it to a trusted assistant (the SSH agent), who will present it whenever needed, so you don't have to fetch and unlock it yourself each time.

With that in mind, let's start the SSH agent and add your key. 👇

First, check that SSH tools are installed (they usually are on Ubuntu, but minimal Docker images not include them):

ssh -V

If you don't see an OpenSSH version in the output, install the client:

sudo apt update
sudo install -y openssh-client

Now start the SSH agent and add your key:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519_test

Here's what's happening:

eval "$(ssh-agent -s)": Starts the SSH agent and sets up your environment to talk to it.
ssh-add ~/.ssh/id_ed25519_test: Loads your private key into the agent. If it's passphrase-protected, you'll be prompted once. After that, the agent remembers it for the rest of your session.

You can confirm the key was added with:

ssh-add -l

3.4. Add your public key to GitHub

Show your public key:

cat ~/.ssh/id_ed25519_test.pub

Copy the full line (it starts with ssh-ed25519 and ends with the comment you chose, e.g. test-key).

Then go to GitHub → Settings → SSH and GPG keys → New SSH key, then paste it there.

3.5. Test the SSH connection

ssh -T git@github.com

If everything is set up correctly, you'll see:

Hi <your-username>! You've successfully authenticated, but GitHub does not provide shell access.

Note: The first time you run this command, you may see The authenticity of host 'github.com (140.82.121.4)' can't be established. Just confirm with yes to continue.

📁 Step 4: Create a new repository on GitHub

Go to https://github.com/new and create a new repository.

Choose a name (e.g. test)
Leave it empty (don't initialize with a README or .gitignore)
Click Create repository

Note: There are ways to create a GitHub repository entirely from the terminal (e.g. using GitHub CLI or the REST API). But to keep things simple, we're creating it through the web interface here. We'll cover terminal-only workflows in a future post.

📂 Step 5: Initialize a local repository

Back in your terminal, create a new folder and initialize a Git repository:

mkdir ~/test
cd ~/test
git init

Create a simple file to commit:

echo "My first Git-backed config!" > README.md

Check the status:

git status

📥 Step 6: Add and commit your changes

Stage the file:

git add README.md

Commit it:

git commit -m "Initial commit"

This records a snapshot of your project in Git history.

🌐 Step 7: Connect local repo to GitHub

In order to be able to push to the remote GitHub server, you have to connect your local repository to it.

For this, copy the SSH URL from the GitHub repository page.

It should look like this:

git@github.com:your-username/test.git

Now connect your local repo to that remote:

git remote add origin git@github.com:your-username/test.git

Explanation:

git remote add: Creates a new remote connection.
origin: The name (alias) you give to that remote (conventionally called origin, but you can name it anything).
git@github.com:yourusername/test.git: The remote repository URL (over SSH in this case, not HTTPS).
You are basically telling Git that the local repository now has a remote called origin, and it lives at the provided URL (git@github.com:...).

To list all currently configured remote repositories, run:

git remote -v

Output:

origin  git@github.com:yourusername/test.git (fetch)
origin  git@github.com:yourusername/test.git (push)

💡 Note: Git can use different URLs for pulling and pushing. Usually they're the same, but you can configure them separately. For example, if you push via SSH but fetch from a read-only HTTPS mirror.

SSH vs HTTPS

There are two main ways to connect your local Git repository to GitHub: SSH and HTTPS.

SSH (git@github.com:...): This method uses your SSH key for authentication. Once your key is added to GitHub, Git can authenticate automatically, no username, password, or token required. It's usually the easiest and most seamless option for everyday use.
HTTPS (https://github.com/...): This method uses an HTTPS connection instead of SSH. However, GitHub no longer accepts your regular password for Git operations. Instead, you'll need to create a Personal Access Token (PAT) and use that as your password. You can generate a PAT in GitHub → Settings → Developer settings → Personal access tokens → Tokens (classic).

When using HTTPS, you'll clone or add your remote with the HTTPS URL. Then, when prompted for credentials:

Username: your GitHub username
Password: your Personal Access Token (PAT)

Both approaches work equally well. SSH is usually the smoother choice for daily development because it "just works" once set up, while HTTPS + PAT can be handy in automated scripts, CI/CD pipelines, or environments where SSH is blocked.

📤 Step 8: Push your file to GitHub

Let's first rename the default branch named master to main, the modern convention used by most projects today:

git branch -M main

This is typically a one-off operation after you created a new repository. When you create new branches in the future, you'll name them yourself (e.g. feature-branch), so you won't need to rename anything again unless you want to rename an existing branch.

Further, not that if you haven't made any commits yet, this command will fail with an error like:
error: refname refs/heads/master not found
fatal: Branch rename failed
That's because no branch actually exists until you've made your first commit.

Then push to GitHub:

git push -u origin main

-u (short for --set-upstream): Creates the main branch on remote (origin) and links your local main branch with that remote branch (origin/main).

Once this upstream relationship is established, you can use the short commands git push and git pull instead of typing the full forms git push origin main and git pull origin main, respectively, when working on the main branch.

Whenever you create a new branch (e.g. git checkout -b feature-branch), you should also include u the first time you push it to ensure the new local branch is linked to the corresponding remote branch (origin/feature-branch), so you can use the short commands git push and git pull while working on feature-branch.

If you forget the u, the git push origin feature-branch may still succeed, but git pull will give you an error fatal: no upstream configure....

To show all the local branches as well as their linked remote branches, run git branch -vv.

If everything is correct, you'll see something like:

📊 Step 9: Verify on GitHub

Go to your new repository's page on GitHub. You should now see your README.md file and your initial commit 🎉

✨ Conclusion

Congratulations! You've successfully installed Git on Ubuntu, connected it to GitHub, and pushed your first commit. This simple workflow is the foundation of virtually every modern software project.

The next step is to deepen your understanding of Git's most common commands and workflows, things like branching, merging, and rebasing. The Git command reference by Atlassian is a great place to continue the learning path.

How to back up and sync your terminal configuration with a GitHub dotfiles repo

100x.crypto 🚀🚀 — Tue, 14 Oct 2025 07:40:03 +0000

If you use Ubuntu (or any Linux system) regularly, chances are you've customized it over time, adding handy aliases, defining environment variables, tweaking your shell prompt, and installing useful tools.

These small changes make your system feel yours. But here is the problem:

💡 What happens if your system breaks, gets wiped, or you switch to a new machine?

If all your configuration lives only on one device, you could lose hours — even days — of work rebuilding your environment from scratch.

The solution: Store your configuration files ("dotfiles") in a GitHub repository.
This not only backs them up but also makes it easy to sync them across devices and restore your setup instantly on a new machine.

This guide shows you how to do exactly that, step by step.

🚀 Step 1: Organize your config files

Let's say you would like to back up your ~/.bashrc and ~/.bash_aliases files (you can apply the same approach to any other config file).

First, create a dedicated folder within your home directory (~) to hold your dotfiles:

mkdir ~/dotfiles

Now copy your config files into that folder:

cp ~/.bashrc ~/dotfiles/bashrc
cp ~/.bash_aliases ~/dotfiles/bash_aliases

💡 Tip: To view your dotfiles in your home directory (hidden by default), use ls -a.

⚠️ Security Warning:
Be very careful not to include sensitive files in your dotfiles repository — especially if it's public.

❌ Never commit files like:

~/.ssh/* (private SSH keys)
~/.aws/credentials (cloud access keys)
.env files with API keys or passwords
GPG keys or database credentials

If someone gains access to these files, they could impersonate you, access your servers, or compromise your accounts.

✅ Best practice:

Only track safe, reusable configuration files (like .bashrc, .bash_aliases, .gitconfig, etc.).
Add sensitive files to .gitignore so they’re never pushed by mistake.
Consider using a private repository if you absolutely must store sensitive configs — and even then, avoid committing secrets directly.

🧰 Step 2: Initialize a Git repository

Log in to your GitHub account in your browser and create a new repository called dotfiles. Leave it empty (i.e., don't initialize with a README or .gitignore). We'll add the files from our local machine shortly.

Now navigate to your newly created local dotfiles folder via

cd ~/dotfiles

...and turn it into a Git repository:

git init
git add .
git commit -m "Initial backup of my shell config"

Your configuration files are now tracked by Git locally.

💡 Note: If you don't have Git installed or run into issues here, check out my other post on how to install Git and push your first repository.

🐙 Step 3: Push it to GitHub

Next, connect your local repository to the remote one you just created:

git remote add origin git@github.com:yourusername/dotfiles.git

Now rename the branch from its default name master to main (modern convention) via

git branch -M main

…and push your local files to GitHub:

git push -u origin main

If everything worked correctly, you should now see your bashrc and bash_aliases files listed in your GitHub repository.

🧪 Step 4: Restore your setup on a new machine

Here's where the magic happens. If you ever reinstall your OS or switch to a new device, you can bring your setup back with just a few commands:

git clone git@github.com:Walodja1987/dotfiles.git ~/dotfiles
cp ~/dotfiles/bashrc ~/.bashrc
cp ~/dotfiles/bash_aliases ~/.bash_aliases
source ~/.bashrc

Boom! Your terminal is back exactly how you left it.

💡 Note on SSH vs HTTPS:
In the example above, I cloned the repo using the SSH URL (git@github.com:...), which lets Git authenticate automatically using your SSH key, without a password or token.

Once your SSH key is configured on GitHub, this is usually the easiest option. Check out my other post no how to set up the SSH key.

If you prefer to use HTTPS, you can do so, but GitHub no longer accepts passwords for Git operations. Instead, you'll need to use a Personal Access Token (PAT) as your password when prompted (you find the PAT in GitHub under Settings -> Developer Settings -> Personal access tokens -> Tokens (classic)):

git clone https://github.com/yourusername/dotfiles.git ~/dotfiles

Username: your GitHub username
Password: your Personal Access Token (PAT)

Both methods work, but SSH is often smoother for day-to-day use, while HTTPS + PAT can be useful in scripts or CI/CD pipelines.

🧠 Step 5: Keep it up to date

Whenever you tweak your local dotfiles, just update your repository:

cp ~/.bash_aliases ~/dotfiles/bash_aliases
cp ~/.bashrc ~/dotfiles/bashrc
cd ~/dotfiles
git add .
git commit -m "Update aliases and bashrc"
git push

This ensures your GitHub repo always mirrors your current setup and your latest configuration is always just a git clone away.

✨ Final Thoughts

Treating your shell configuration like code — version-controlled, backed up, and portable — is one of the most valuable habits you can develop as a developer or power user.

With a simple dotfiles repository on GitHub, your carefully crafted setup is safe, reproducible, and always within reach, no matter what happens to your system.

If you want to take it one step further, check out my follow-up post on how to use symlinks to keep your dotfiles automatically in sync. It shows how to avoid manual copying altogether and make the process even more seamless.

Test installs in a clean Ubuntu sandbox

100x.crypto 🚀🚀 — Sun, 12 Oct 2025 14:51:41 +0000

When you include installation guides in your tutorials or documentation, it's good practice to test the installation steps. But what if you already have the tool installed on your machine and don't want to uninstall it?

Here's a simple, elegant solution: use Docker to spin up a fresh Ubuntu environment in seconds, no changes to your existing setup required.

Note: This guide is written for Ubuntu. Windows and macOS are not covered here.

🛠️ Step 1: Install Docker (if not already installed)

Check whether docker is already installed on your system:

docker --version

If docker is not yet installed on your Ubuntu system, install it with:

sudo apt update
sudo apt install docker.io -y

Then start the Docker service:

sudo service docker start

You can verify the installation:

docker --version

You should see something like:

Docker version 26.1.3, build 26.1.3-0ubuntu1~20.04.1

🧪 Step 2: Launch a fresh Ubuntu container

Now spin up a fresh Ubuntu 22.04 container with:

docker run -it ubuntu:22.04 bash

What this does:

docker run – creates and runs a container
-it – makes it interactive (so you can use it like a shell)
ubuntu:22.04 – pulls the official Ubuntu image from Docker Hub
bash – starts a Bash shell inside the container

You're now inside a clean Ubuntu environment, just like a fresh server install.

💡 Note: The official ubuntu:22.04 Docker image is extremely minimal. It doesn't even include sudo by default. And since you're already logged in as the root user inside the container (notice the root@...:/# prompt), you will not need sudo in front of any commands. For example, you can simply run apt update instead of sudo apt update. If you try the latter, you'll see bash: sudo: command not found.

🧪 Step 3: Test installation steps

Let's test the installation of the curl tool.

Inside the container, try running:

curl --version

You'll likely get:

bash: curl: command not found

This is exactly what we want. Now you can follow your installation guide exactly as a new user would:

apt update
apt install curl -y

Then verify again:

curl --version

You should now see the installed version:

curl 7.88.1 (x86_64-pc-linux-gnu) libcurl/7.88.1 OpenSSL/3.0.2 ...

🧹 Step 4: Exit and throw away the test environment

When you're done testing, simply type:

exit

The container stops and disappears. Your real system remains unchanged, and you can spin up a new clean one anytime by running the same command:

docker run -it ubuntu:22.04 bash

✨ Conclusion

Using Docker to simulate a clean Linux environment is one of the easiest ways to validate installation instructions without touching your real system. It’s quick, lightweight, and repeatable.

Boost your terminal workflow with aliases

100x.crypto 🚀🚀 — Sun, 12 Oct 2025 14:29:36 +0000

If you often work in the terminal, you've probably found yourself looking up and typing the same long commands again and again. Whether it's starting a service, launching a Docker container, or running a script, those commands are hard to remember and slow you down your workflow.

Fortunately, there's a simple trick that makes your life much easier: aliases

An alias is a short, memorable word you define to stand in for a longer command. It's one of the simplest and most powerful ways to make your command-line experience faster, cleaner, and more enjoyable.

Let's see how it works. 👇

🚀 Example

Imagine you're frequently running these two commands:

sudo service docker start
sudo docker run -it ubuntu:22.04 bash

The first starts the Docker service, and the second launches a fresh Ubuntu container (see my other blog post to learn where this combination can be helpful). Both are useful, but memorizing and typing them every time is tedious.

With aliases, you can replace those long commands with simple, human-friendly words like:

startdocker
freshubuntu

🧪 Step 1: Create temporary aliases (for testing)

You can define an alias directly in your terminal. It will work until you close the session:

alias startdocker='sudo service docker start'
alias freshubuntu='sudo docker run -it ubuntu:22.04 bash'

Now try them:

startdocker
freshubuntu

Much cleaner and easier to remember.

If you want to change the command associated with an alias, just redefine it with the new command. The new definition will overwrite the old one.

Note: You need to have Docker installed to run these commands. If you don't have Docker, either install it via

sudo apt update
sudo apt install docker.io -y

...or try other commands you use frequently.

🔁 Step 2: Make aliases permanent

Temporary aliases disappear when you close the terminal. To make them permanent, add them to your shell configuration file.

For bash (Ubuntu's default shell):

nano ~/.bashrc

Then add your aliases at the bottom:

alias startdocker='sudo service docker start'
alias freshubuntu='sudo docker run -it ubuntu:22.04 bash'

Save and exit (CTRL+O, Enter, CTRL+X), then reload the configuration:

source ~/.bashrc

Now these aliases will work every time you open a new terminal window.

Note: If you're using zsh instead of bash, add aliases to ~/.zshrc instead of ~/.bashrc.

🔗 Combine multiple commands into a single alias

Aliases can do more than just shorten single commands. They can chain multiple commands together.

For example, you could create an alias that starts Docker and then launches the container:

alias freshubuntu='sudo service docker start && sudo docker run -it ubuntu:22.04 bash'

Now, typing:

freshubuntu

…will automatically start the Docker service (if needed) and drop you into a fresh Ubuntu environment, all in one step.

🧠 Useful tips

Command to list all defined aliases:

alias

Note: Some aliases may already be defined by default in your system’s .bashrc or other startup files.

Command to remove an alias:

unalias freshubuntu

Best practices:
- Use short, meaningful names.
- Keep a consistent naming convention (e.g., all lowercase).

📂 Optional: Store aliases in a separate file

As your list of aliases grows, it can clutter your ~/.bashrc. A cleaner approach is to store them in a dedicated ~/.bash_aliases file and then load that file from .bashrc.

Step 1 – Create the .bash_aliases file:

nano ~/.bash_aliases

Add your shortcuts:

alias startdocker='sudo service docker start'
alias freshubuntu='sudo docker run -it ubuntu:22.04 bash'

Save and exit the file (CTRL+O, Enter, CTRL+X).

Step 2 – Source it from .bashrc:

Open your ~/.bashrc and add this snippet near the bottom:

if [ -f ~/.bash_aliases ]; then
    source ~/.bash_aliases
fi

This tells your shell to load all aliases from ~/.bash_aliases if the file exists.

Note: You may already have this if-block in your .bashrc file.

Now reload your configuration to apply the changes:

source ~/.bashrc

With that approach, your ~/.bashrc stays clean, and you can back up or share your aliases separately without touching the rest of your configuration.

This small structure change pays off later, especially when you start version-controlling your config (as we'll explore in the next post).

✨ Conclusion

Aliases are a small trick that deliver big productivity gains. With just a few lines in your shell config, you can turn long, hard-to-remember commands into short, memorable shortcuts, saving time and making your workflow more enjoyable.

DEV Community: 100x.crypto 🚀🚀

Understanding TypeScript Execution Tools: A Deep Dive

1. A Brief History of JavaScript

2. What is Node.js

How Node decides which module system to use

3. What is TypeScript

JavaScript example

How TypeScript improves this

Type annotations in your code

Type definitions for the runtime environment

Compilation of TypeScript to JavaScript

How TypeScript decides what JavaScript to emit

4. Setup an example project

5. Executing TypeScript with tsc

Installation and configuration

esModuleInterop: true

forceConsistentCasingInFileNames: true

strict: true

skipLibCheck: true

Compilation

Run with Node

Notes on compiling single files

Summary

6. Executing TypeScript using ts-node

Installation and requirements

Running TypeScript with ts-node

Summary

7. Executing TypeScript using tsx (Easiest Option)

Installation

Running TypeScript with tsx

Summary

8. When to Use What (tsc vs ts-node vs tsx)

✅ Use tsx when you want the easiest, fastest developer experience

✅ Use ts-node when you need TypeScript execution that respects your project configuration

✅ Use tsc when you need actual .js output (production builds)

9. Final words

Run TypeScript Files in 30 Seconds

Step 1: Create a New Project Directory

Step 2: Install tsx

Step 3: Run Your TypeScript File

Example

Quick reference

Symlinks

🧩 Intro

🪄 What is a symlink?

⚙️ Syntax

📌 Quick symlink cheatsheet

💡 Things to keep in mind

✨ Final Thoughts

How to install Git on Ubuntu and push your first repository to GitHub

🛠️ Step 1: Install Git on Ubuntu

✏️ Step 2: Configure your Git identity

🔑 Step 3: Set up SSH access to GitHub

3.1. Check existing SSH keys

3.2. Generate a new SSH key

3.3. Start the SSH agent and add your key

3.4. Add your public key to GitHub

3.5. Test the SSH connection

📁 Step 4: Create a new repository on GitHub

📂 Step 5: Initialize a local repository

📥 Step 6: Add and commit your changes

🌐 Step 7: Connect local repo to GitHub

SSH vs HTTPS

📤 Step 8: Push your file to GitHub

📊 Step 9: Verify on GitHub

✨ Conclusion

How to back up and sync your terminal configuration with a GitHub dotfiles repo

🚀 Step 1: Organize your config files

🧰 Step 2: Initialize a Git repository

🐙 Step 3: Push it to GitHub

🧪 Step 4: Restore your setup on a new machine

🧠 Step 5: Keep it up to date

✨ Final Thoughts

Test installs in a clean Ubuntu sandbox

🛠️ Step 1: Install Docker (if not already installed)

🧪 Step 2: Launch a fresh Ubuntu container

🧪 Step 3: Test installation steps

🧹 Step 4: Exit and throw away the test environment

✨ Conclusion

Boost your terminal workflow with aliases

5. Executing TypeScript with `tsc`

`esModuleInterop: true`

`forceConsistentCasingInFileNames: true`

`strict: true`

`skipLibCheck: true`

6. Executing TypeScript using `ts-node`

Running TypeScript with `ts-node`

7. Executing TypeScript using `tsx` (Easiest Option)

Running TypeScript with `tsx`

8. When to Use What (`tsc` vs `ts-node` vs `tsx`)

✅ Use `tsx` when you want the easiest, fastest developer experience

✅ Use `ts-node` when you need TypeScript execution that respects your project configuration

✅ Use `tsc` when you need actual `.js` output (production builds)