A Simple Guide to Setting Up Absolute Imports in Vite + React (TypeScript)

Victor Bruce — Fri, 16 Jan 2026 19:38:49 +0000

Using relative imports can get messy in no time, especially in large, complex projects. Moving from relative paths like ../../../components/Button makes your code cleaner and easier to refactor.

However, if you're working with Vite and TypeScript, simply updating your tsconfig.json isn't enough. You have to ensure both the TypeScript compiler and the Vite build tool are on the same page. Here is the most direct way to set it up.

Step 1: Update your TypeScript Configuration

In recent Vite templates, the tsconfig.json file often acts as a base configuration that references other files. To follow this project structure correctly, you should place your path aliases inside tsconfig.app.json.

Handling the "baseUrl" Deprecation

A common issue developers face is the deprecation of baseUrl in newer versions of TypeScript. You have two ways to handle this:

Option A: The Modern Approach (Recommended) Remove baseUrl entirely and use paths relative to the configuration file. Notice the ./ prefix in the path:

{
  "compilerOptions": {
    "composite": true,
    "paths": {
      "@/*": ["./src/*"]
    }
  }
}

Option B: The Legacy Workaround If you must use baseUrl, you will need to silence the deprecation warning:

{
  "compilerOptions": {
    "ignoreDeprecations": "5.0", // Use 5.0 or 6.0 depending on your TS version
    "baseUrl": "./",
    "paths": {
      "@/*": ["src/*"]
    }
  }
}

Step 2: Update your Vite Configuration

While TypeScript now understands what @/ means for autocompletion and type checking, Vite still doesn't know how to resolve that alias during the actual build or dev process.

Open your vite.config.ts file and add the resolve.alias property:

export default defineConfig({
// other configurations
  resolve: {
    alias: {
      '@': '/src',
    },
  },
})

Why do we need both?

It's helpful to remember the roles of these two files:

tsconfig.json: Tells VS Code and the TypeScript compiler how to find files so you get "Click to Definition" and no red squiggly lines.
vite.config.ts: Tells the Bundler how to actually grab the code and put it in the browser.

By syncing these two files, you get a seamless development experience with clean, absolute imports.

The End!

Managing Multiple Git Identities: A Seamless Workflow for Personal and Work Accounts

Victor Bruce — Fri, 16 Jan 2026 19:24:09 +0000

The Identity Crisis:

We've all been there: pushing code using the wrong identity(e.g. using your personal email coding_ninja1@gmail.com to commit work related code).

Managing multiple Git identities on a single machine is a rite of passage for every developer. Whether you're balancing open-source work with a 9-to-5 or juggling different freelance clients, it's incredibly easy for your professional identities to start overlapping or lose track of which "hat" you're wearing at any given moment.

In this post, I am going to walk you through a two-step evolution to solve this once and for all:

The SSH Foundation: We'll start by setting up unique SSH keys for different platforms(like GitHub vs. Bitbucket). While this secures your connection, it has a major limitation; you still have to manually remember to set your user.email every single time you clone a new repo.
The Secret Sauce (Git Conditional Includes): I'll show you how to go beyond the manual setup. We will configure Git to be "context-aware" so that your machine automatically swaps your name and email based on which folder you're working in.

By the end of this guide, you'll have a "set it and forget it" system that ensures your professional work stays professional and your personal projects stay personal.

Step 1: The SSH Foundation

What is SSH?

SSH(Secure Shell) is a protocol that allows your computer to communicate securely with a server over an unsecured network. Instead of typing a username and password every time you push code, you use a key pair: a public key (which you share with Bitbucket/GitHub) and a private key (which stays locked on your machine).

Setting it up (Step-by-Step)

1. Generate a New SSH key:

Open your terminal and run the following command to create a key specifically for your work account and personal account(assuming you don't have one already created).

Work (let's assume the organisation uses Bitbucket):

ssh-keygen -t ed25519 -C "work.email@acme.com" -f ~/.ssh/id_ed25519_bitbucket

Personal (let's assume you use Github):

ssh-keygen -t ed25519 -C "personal.email@gmail.com" -f ~/.ssh/id_ed25519_github

When prompted for a passphrase, you can add one or leave it blank.
This creates a specific file named id_ed25519_bitbucket and id_ed25519_github .

Why `ed25519`?

You might notice we didn't use the traditional RSA algorithm. Here is why ed25519 is the modern gold standard:

Security: It offers a higher security level than RSA with a much smaller key size.
Performance: It is faster to generate and verify, making your Git commands feel snappier.
Collision Resistance: It is mathematically designed to be more resistant to certain types of hacking attacks that older methods might be vulnerable to.

2. Configure your SSH Config File

Next we use the ~/.ssh/config file to act as a traffic controller. Whenever you interact with bitbucket.org or github.com --- Git will automatically use your work email key or personal email key respectively.

Open (or create) the config file: nano ~/.ssh/config
Add the following block:

# Personal Account (GitHub)
Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_github

# Work Account (Bitbucket)
Host bitbucket.org
  HostName bitbucket.org
  User git
  IdentityFile ~/.ssh/id_ed25519_bitbucket

3. Add Keys to the Platforms

Now, the next step is to copy the "public" half of the keys generated to their respective websites:

GitHub:

1. Copy the public key: cat ~/.ssh/id_ed25519_github.pub
2. Log in to GitHub web interface
3. Go to Settings > SSH and GPG keys > New SSH Key
4. Paste the content you copied

Bitbucket:

1. Copy the public key: cat ~/.ssh/id_ed25519_bitbucket.pub
2. Log in to Bitbucket web interface
3. Go to Personal Settings > SSH Keys > Add Key
4. Paste the content you copied

4. Clone and Set Up Local Identity

Before we dive into cloning your first work repo, it's important to understand how Git handles your identity. By default, Git is "lazy" --- it will use whatever you've set globally for every project on your machine.

Setting Your "Default Base" (Global Config):

Most developers prefer to set their personal account as the global default. This ensures that if you're hacking away on a side project or an open-source contribution, you don't have to do any extra setup.

Run this once to set your "Default Base":

git config --global user.email "personal.email@gmail.com"

Now, every repository you create or clone will use this email unless you explicitly tell it otherwise.

Set Up Local Identity:

When you transition to your professional workspace, you need to "override" that global default. Since your machine is already using your personal email, you must manually sign your work for each corporate repository.

1. Clone the Repository

Using the SSH key we configured earlier, clone your work repo:

git clone git@bitbucket.org:acme-corp/project-alpha.git

2. Set the local override

cd repo-name
git config user.name "Your Name"
git config user.email "work.email@acme.com"

The Manual Burden:

This works perfectly, but there is a catch:

You have to remember to do this for every single work repo you clone. If you forget that git config command, you'll end up pushing professional code with your personal "default base" email.

Note: This manual overhead is exactly why we use Conditional Includes --- to make this switch happen automatically so you never have to think about it again.

Step 2: Git Conditional Includes

Now your computer can 'talk' to both GitHub and Bitbucket without asking for a password. However, there is still one major problem; SSH handles the connection, but Git handles the name. Meaning that, even if you use your work SSH key to push to Bitbucket, Git might still label your as **personal_email@gmail.com** because of your global settings. Let's fix that with the Secret Sauce*(Git Conditional Includes)*

The Goal: Automate your identity so you never have to type git config user.email again. This is a "set it and forget it" strategy. By using Conditional Includes, you tell Git: "If I am working inside my Work folder, automatically swap my identity to my Acme email"

This prevents the common mistake of accidentally pushing a work commit with your personal email address.

Setting it up (Step-by-step)

1. Organise Your Folders

First, ensure your projects are separated by directory. For example:

~/Documents/Personal/ : All your personal stuff or projects
~/Documents/Work/ : All your work stuff or projects

2. Create a "Work-Only" Config File

Create a new file inside your Work folder by running the command below:

nano ~/Documents/Work/.gitconfig-work

Paste the following into the .gitconfig-work file:

[user]
    name = Your Name
    email = work.email@acme.com

Save and exit

3. Link the "Work-Only" Config File in your Global Config

Now, you need to tell your main Git configuration to "watch" your folders.

Open your global config:

nano ~/.gitconfig

Add this logic at the very bottom of the file:

# Default/Personal Identity
[user]
    name = Your Name
    email = personal.email@gmail.com

# Conditional Include: If the path starts with ~/Documents/Work/
[includeIf "gitdir:~/Documents/Work/"]
    path = ~/Documents/Work/.gitconfig-work

How it Works

When you run a Git command Git checks your current directory.

If you are in ~/Documents/Personal/repo , it sees your global email.
If you are in ~/Documents/Work/acme-project , the includeIf trigger activates and overwrites the global email with the one found in .gitconfig-work

Verifying The Setup

To make sure it's working perfectly, navigate into a repo inside your Work folder and run: git config user.email . It should return work.email@acme.com . If you move to a folder outside "Work" and run the same command, it should return your personal email.

Conclusion

By combining SSH Config (for secure access) and Conditional Includes (for automated identity), you've built a professional-grade development environment. No more accidental commits, no more "unrecognised user" errors, and zero manual setup for new repos.

DEV Community: Victor Bruce