DEV Community: Ukpai Chukwuemeka

Testing React Native Applications: Best practices and Frameworks

Ukpai Chukwuemeka — Tue, 26 Aug 2025 06:55:28 +0000

Testing is a habit — one that not every developer possesses.

Imagine driving through a busy intersection with no traffic lights.

Chaos, right ?

That’s exactly what software without testing feels like.

Testing is an integral part of software development.

For React Native applications, it ensures your features work as expected — and continue to do so as your app grows.

Yet many developers skip tests because “it works on my machine” or due to tight deadlines.

Just like you go to the gym to stay fit, testing keeps your codebase healthy.

I’ll admit, I have written my fair share of tests and then stopped.

Until I realized that many of the bugs I kept missing were the direct result of extending functionality and refactoring without proper test coverage.

Those hidden bugs eventually slipped into production.

In this article, we’ll explore testing strategies, best practices, coverage, and frameworks you can use to catch bugs before they ever reach production.

Why Testing Matters

Every app has moving parts — logic, APIs, components, and user flows. Without automated tests, changes can unintentionally break those parts.

A good test suite helps you:

Prevent regressions.
Document expected behavior.
Increase confidence when refactoring.
Ship features faster and safer.

Testing Frameworks for React Native

There are several testing tools commonly used in react native applications, including:

1. Jest

The default testing framework in React Native.
Fast, supports mocking, and integrates with libraries like react-test-renderer and @testing-library/react-native.
Great for unit and integration tests.

2. React Native Testing Library (RNTL)

A library built on top of @testing-library.
Encourages testing components the way users interact with them (via text, roles, and accessibility labels).
Example: getByText("Submit") instead of checking internal props.

3. Detox

A powerful E2E testing framework for React Native.
Automates user flows on real devices or emulators.
Ensures your app behaves correctly in real-world scenarios.

4. Cypress (for Web/Expo Web)

If your React Native project also targets web via Expo, Cypress is a great choice for browser-based E2E testing.

Test Coverage

Coverage helps track which parts of your code are tested. Common metrics include:

Statements — how many statements in the code are executed.
Branches — whether conditional paths (if, switch, ternary) are tested.
Functions — coverage of function calls.
Lines — percentage of lines run during tests.

Best Practices for Testing React Native

Whether it’s unit tests, integration tests, or E2E tests, almost every testing framework follows this Arrange → Act → Assert (AAA) pattern.

You should also make more obvious what the SUT (subject under test) is.

Example: AAA in Action

import React from "react";
import { render, fireEvent } from "@testing-library/react-native";
import { Button, Text } from "react-native";
function GreetingButton() {
  const [message, setMessage] = React.useState("");
  return (
    <>
      <Button title="Say Hello" onPress={() => setMessage("Hello, World!")} />
      <Text>{message}</Text>
    </>
  );
}
test("it shows greeting after button press", () => {
  // Arrange
  const { getByText } = render(<GreetingButton />);
  // Act
  fireEvent.press(getByText("Say Hello"));
  // Assert
  expect(getByText("Hello, World!")).toBeTruthy();
});

Best Practices

1. Test behavior, not implementation

Focus on what the user sees and does, rather than the internal details of your component. This makes tests more robust and less prone to breaking when you refactor code.

2. Keep tests fast

Unit tests should execute quickly to encourage frequent running. Slow tests discourage developers from running them regularly.

3. Mock external dependencies

APIs, AsyncStorage, native modules, and other side-effect-prone dependencies should be mocked. This prevents flaky tests and ensures your tests run reliably.

4. Use CI/CD pipelines

Automate your tests using tools like GitHub Actions, Bitrise, or CircleCI. This ensures regressions are caught before code is merged.

5. Don’t chase 100% coverage blindly

Focus on critical paths and meaningful coverage rather than trying to hit 100% line coverage. High coverage doesn’t always mean high-quality tests.

6. Use snapshots wisely

Snapshots are useful for catching unintended changes in UI, but avoid overusing them for implementation details. Also update snapshots intentionally when UI changes are expected.

7. Use Husky (optional)

Husky can enforce pre-commit hooks to run tests or linting before commits. This is helpful, but optional — only adopt it if your team finds it useful.

How to Setup Husky

React Native Test Setup

If you would like to start testing a new or an existing react native app.

It’s very easy

Plus any of the popular frameworks (like Jest for unit testing or Detox for end-to-end testing) can be integrated seamlessly.

How To Create a New React Native Project

To create a new project, you can use the official React Native Community CLI:

npx @react-native-community/cli init rntesting

Once the setup is complete, open the newly created folder in your favorite IDE (such as VS Code) and you’re ready to start adding tests.

By default, projects created with the Community CLI come with Jest preinstalled and configured, so you can immediately run tests with:

npm run test
yarn run test

Let’s update a few things to help us write and run our test.

"test:nowatch": "jest --watchAll=false",
"test:coverage": "jest --coverage --watchAll=false",
"test:update:snapshot": "npm test -- -u"

We would update our jest.config.js

module.exports = {
  preset: 'react-native', // use the react-native preset
  transformIgnorePatterns: [
    'node_modules/(?!(@react-native|react-native|react-native-reanimated|react-native-image-picker)/)', // add any other packages that need to be transformed
  ],
  setupFiles: [
    './jestSetup.js', // your custom setup file
  ],
  moduleNameMapper: {
    '\\.(jpg|jpeg|png|gif|eot|otf|webp|svg|ttf|woff|woff2|mp4|webm|wav|mp3|m4a|aac|oga)$':
      'jest-transform-stub', // mock static assets
  },
  fakeTimers: {
    enableGlobally: true, // use fake timers for all tests
  },
  collectCoverageFrom: [
    'src/**/*.{js,jsx,ts,tsx}', // your source files
    '!src/assets/**', // exclude assets
    '!src/**/*.d.ts', // exclude types
    '!src/**/index.{js,ts,tsx}', // exclude barrel index files
  ],
  testMatch: [
    '**/__tests__/**/*.{js,jsx,ts,tsx}', // look for tests in __tests__
    '**/?(*.)+(spec|test).{js,jsx,ts,tsx}', // or files ending in .test/.spec
  ],
  collectCoverage: true, // enable coverage collection
  coverageThreshold: {
    // set coverage thresholds
    global: {
      branches: 100, // set to 100% or your desired threshold
      functions: 100, // set to 100% or your desired threshold
      lines: 100, // set to 100% or your desired threshold
      statements: 100, // set to 100% or your desired threshold
    },
  },
};

Now the next time you run coverage you should be able to see your code coverage and a coverage folder would be generated.

npm run test:coverage

To view the report in your browser open up the index.html file under rntesting/coverage/lcov-report/index.html .

Github Repo Link

Conclusion

We all dream of the fancy job with good pay but the harsh reality you are not ready to write test :).

Likewise teams that invest in tests build software that lasts.

Do you want to practice?

You can fork the repo, experiment, and add your own test cases. Let’s help each other write better, more reliable apps !

Cheers and happy testing!

Windows Android Development Setup

React Native Get Started Without a Framework

React Native Testing Library

telegram webhook

Ukpai Chukwuemeka — Sun, 19 Jan 2025 11:19:03 +0000

Unlike polling, which repeatedly requests updates from Telegram, webhook allow Telegram to push updates directly to your server, reducing server resource usage and improving efficiency.
In a previous article, I explained how to set up a Telegram bot using Node.js, where we implemented polling to fetch updates repeatedly. While this setup works well, webhooks are a better alternative if you’re looking to scale, even if you’re not currently experiencing rate limits, switching to webhook ensures your bot runs more efficiently and can handle increased traffic with less strain on your server.

Key Considerations for Telegram Webhook

When using webhook, it’s crucial to understand the following:

Allowed Ports

Telegram supports only four ports for webhooks. While the reason for this limitation is still unclear to me, it might change in the future. For now, these are the supported ports:

443 (recommended for HTTPS)
80
88
8443

Either of these ports must be free and accessible for the webhook to function correctly. If you don’t explicitly specify a port, the webhook will default to using port 8443.

Server Limits

Since only four ports are allowed, you cannot run more than four apps using webhook on the same server.

Prerequisites

Before diving into the setup, ensure you have the following:

Node.js Installed: Download and install Node.js from nodejs.org if you haven’t already.
Telegram Account: You’ll need a Telegram account to obtain a bot token and interact with your bot.
Ngrok for HTTPS URL: Telegram requires an HTTPS endpoint for webhooks. Use Ngrok to expose your local server to the internet.

You can find full code on Github .

Setting Up Telegram Webhook (Node.js Example)

// Import the Telegram Bot API
const TelegramBot = require('node-telegram-bot-api');

// Replace with your bot token
const token = 'your telegram token'; // Check out my article on how to get a bot token from @BotFather on Telegram

const WEB_HOOK_URL = 'https://localhost:3000/telegram-bot-webhook'; 
// NOTE: It won't work on localhost, so use a tunneling service like ngrok.

// Create a bot that uses a webhook
const bot = new TelegramBot(token, {
  webHook: {
    port: 88, // Allowed ports for Telegram webhook: 443, 80, 88, 8443
  },
});

// Initialize the webhook
const initWebHook = async () => {
  const webhookInfo = await bot.getWebHookInfo();
  if (webhookInfo.url !== WEB_HOOK_URL) {
    await bot.setWebHook(WEB_HOOK_URL, {
      max_connections: 100,
    });
  }
};
initWebHook();

// Listen for any message
bot.on('message', (msg) => {
  const chatId = msg.chat.id;

  // Simple command handling
  if (msg.text.toLowerCase() === '/start') {
    bot.sendMessage(chatId, 'Welcome! How can I assist you today?', {
      reply_markup: {
        keyboard: [['/start', '/help']],
      },
    });
  } else if (msg.text.toLowerCase() === 'hello') {
    bot.sendMessage(chatId, `Hello, ${msg.from.first_name}!`);
  } else {
    bot.sendMessage(chatId, "I'm not sure how to respond to that.");
  }
});

// Export the bot module
module.exports = bot;

Telegram Webhook Route

const express = require("express");
const app = express();
const bot = require("./bot");

// parse json body  for post request
app.use(express.json());

app.get("/", (req, res) => {
  res.send("Hello World");
});

app.post("/telegram-bot-webhook", (req, res) => {
  bot.processUpdate(req.body);
  res.sendStatus(200);
});

app.listen(process.env.PORT || 3000, () => {
  console.log("Server is running on port 3000");
});

Conclusion

Switching to webhook eliminates telegram rate-limiting issue and improves your bot’s efficiency. Just ensure you configure your server properly, use the allowed ports, and secure your connection with HTTPS.

Kindly follow me to get notified on my next post 📫.

do not be racist to yourself

Ukpai Chukwuemeka — Sun, 19 Jan 2025 10:53:24 +0000

Let’s be real for a second. We all face external barriers — judgment, bias, societal nonsense. But honestly? The biggest roadblock isn’t “out there.” It’s inside. Yup, it’s that little voice in your head, the one that loves to whisper things like, “You’re not good enough,” or, “Why even bother?” You know the one I’m talking about.

Here’s the crazy part. We’re quick to call out racism or injustice when it comes from other people, right? But when it’s our own thoughts doing the damage, we just… let it slide. Why? Think about it. If someone else said, “You’ll never make it because of where you’re from” or “You’re not smart enough for this,” you’d be furious. So why let your inner voice get away with that kind of nonsense?
Listen, the color of your skin shouldn’t limit you, and neither should your mindset. Where you grew up? How much money you had (or didn’t have)? The mistakes you’ve made? None of that defines you — unless you let it.

Now, let’s talk about your life for a minute. Be honest. How much time do you spend scrolling through your phone, liking random posts, making money for people who’ve figured out the game while you sat there doubting yourself? Ouch, right? And it’s not just individuals — businesses fall into this trap, too, holding themselves back instead of going all-in.

But here’s the good news regrets don’t belong here, Only lessons. Think about those superstars you admire. They’re not some magical breed of humans. They made bold moves, invested in themselves, and shut down that inner critic.

And guess what? You’ve got that same potential. Yeah, you. Don’t let that voice in your head tell you otherwise. Success doesn’t come from being perfect — it comes from showing up, putting in the work, and believing you’re worth it.

So, the big question is: Are you ready to silence that voice and unlock the future that’s been waiting for you? Because trust me, it’s ready when you are.

Before you go, don’t forget to clap 👏 and follow.

Safeguarding Your Users: A Simple Guide to Preventing CSRF Attacks

Ukpai Chukwuemeka — Fri, 06 Sep 2024 16:55:00 +0000

Introduction

Cross-Site Request Forgery (CSRF) is a common web security vulnerability in which an unsuspecting user is tricked into unknowingly performing actions they did not intend to.

A CSRF attack is like a trickster convincing someone to do something they wouldn't normally do.

A classic example of a Cross-Site Request Forgery (CSRF) attack is a hacker slipping a malicious link into your email, hoping you will click it without realizing the danger. When you do, your browser might unknowingly send a request to a website you are already logged into, carrying out actions like making unauthorized purchases, transfers, withdrawals, or changing your password.

Types of CSRF attacks

Client-Side Attacks: These attacks exploit vulnerabilities on the client side. They often involve injecting malicious scripts that alter the DOM, change styles or pictures, or even add external forms to other applications

Server-Side Attacks: These attacks target vulnerabilities on the server side of an application. They involve exploiting weak authentication mechanisms, insecure session management, or other vulnerabilities to forge requests for authenticated users.

Client Side CSRF Prevention Measure

While server-side measures are generally considered the most effective way to prevent Cross-Site Request Forgery (CSRF), implementing client-side restrictions can provide an additional layer of defense.

CAPTCHA (Completely Automated Public Turing Test to Tell Computers and Humans Apart): While CAPTCHA can be a frustrating experience, it's a valuable tool in the fight against Cross-Site Request Forgery (CSRF). By requiring users to complete a simple task difficult for bots to mimic, CAPTCHA helps verify that a human is behind the request, making it harder for attackers to exploit vulnerable client-side applications.

Content Security Policy (CSP): Integrating a content security policy (CSP) is one of the effective ways to prevent CSRF attacks, cross-site scripting (XSS), and injection attacks on the client side. It acts like a digital shield, strictly controlling which resources your application can load. By using directives like script-src and style-src. You can specify where styles and scripts load up from.

<head>
  <meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' 'nonce-random-string'; style-src 'self' 'nonce-random-string'; img-src 'self' https://yourdomain.com">
</head>

<meta http-equiv="Content-Security-Policy" content="...">

This is the specific meta tag that defines the CSP.

http-equiv="Content-Security-Policy" This attribute specifies that the meta tag defines the content security policy for the page.

content="..." This attribute holds the CSP directive, usually a string of semicolon-separated rules.

default-src 'self' This directive sets the default source for all resources (scripts, stylesheets, images, etc.) to be 'self' only. This means resources can only be loaded from the same domain as the current webpage.

script-src This directive specifically defines allowed sources for scripts.
(a) 'self' Allows scripts from the same domain as the webpage.
(b) 'nonce-XYZ' Allows scripts with a "nonce" attribute set to the unique value "XYZ" usually generated on the server.

style-src Similar to scripts, this directive defines allowed sources for stylesheets
(a) 'self' Allows stylesheets from the same domain as the webpage.
(b) 'nonce-ABC' Allows stylesheets with a "nonce" attribute set to the unique value "ABC" usually generated on the server.

img-src This directive defines allowed sources for images.
(a) 'self' Allows images from the same domain as the webpage.
(b) https://yourdomain.com Allows images from a specific external domain, ensuring it uses a secure HTTPS connection.

In Next.js 13 and later, adding a list of remote patterns for images or other documents in the next.config file under the hood adds an img-src directive using the domains added.

# typical next.config file specifying allowed sources for images
const nextConfig = { 
   images: {
    remotePatterns: [
      {
        protocol: "https",
        hostname: "google.com",
      },
      {
        protocol: "https",
        hostname: "avatar.vercel.sh",
      },
      {
        protocol: "https",
        hostname: "lh3.googleusercontent.com",
      },
      {
        protocol: "https",
        hostname: "avatars.githubusercontent.com",
      },

    ],
  },
}

3. Input validation: Hackers can send malicious scripts and contents through form inputs that aren't adequately validated and sanitized. Validating inputs is another preventive measure to consider when safeguarding your client-side application from CSRF attacks.

4. HTTP Strict Transport Security (HSTS): Enforcing strict HTTPS connections can help prevent CSRF attacks, but this would only be able to prevent attacks that rely on HTTP.

Server-Side CSRF Prevention Measure

CORS (cross-origin resource sharing): CORS is a mechanism that allows a client-side application to make requests to the server-side application on a different domain. It's also a crucial security measure for preventing CSRF attacks.

Synchronizer Token Pattern (STP): The Synchronizer Token Pattern, or STP for short, is like a secret handshake between your web server and your users' browsers. When a user signs in or starts a new session, it generates and stores a CSRF token in the server sessions, and on forms. The token is sent back to the server on each user request for verification. However, as your user grows, this could lead to potential memory issues if not configured properly. It is also one of the measures to prevent CSRF attacks on the server side.

Double Submit Cookie: The Double Submit Cookie pattern is another measure to consider against preventing CSRF attacks on the server side. It works by storing a CSRF token in cookies and including the same token in a hidden field, preferably inside a form. When the server receives a form submission, it validates the submission by checking if the CSRF token in cookies matches the token stored in the hidden field. This helps to ensure that the form submission originated from the user's browser and not from an attacker.

Checking the HTTP Referer Header: Checking the HTTP referer header is like showing a store clerk your ID to prove you are of age. This helps prevent underage purchases. Similarly, on the server, this involves checking the referer header to verify that a request is coming from a legitimate source. This simple security measure can help prevent Cross-Site Request Forgery (CSRF) attacks.

Conclusion
While these measures can help prevent CSRF attacks, it is important to remember that the digital landscape is constantly evolving. Other threats, like XSS attacks, also pose significant risks. As developers, our responsibility extends beyond creating functional products to ensuring their security. By diligently implementing defenses against CSRF and other attacks, we can safeguard our users' data and protect our businesses from potential harm.

Check out your application CSP status using the links below:

csp-evaluator
observatory by Mozilla

Set up a monorepo using pnpm workspace

Ukpai Chukwuemeka — Thu, 05 Sep 2024 18:40:16 +0000

In the previous article, we discussed how a monorepo structure could be package-centric or app-centric, depending on your project needs. Well, in this particular article, we will set up a monorepo using pnpm and take the app-centric route.

What's Pnpm?

Pnpm is a new generation of package management tools; it works just like NPM and yarn but offers some advantages.

## install pnpm
npm install -g pnpm # install pnpm globally

Create a new directory or clone an existing repository

mkdir monorepo # creates a new folder

or

git clone repository-link # clones a git repository (note: replace the link with repository URL)`

Let's change our current directory to the recently created directory or cloned repo.

cd monorepo # change directory

Next, we are going to initialize the package manager with pnpm.

pnpm init

Optional: Initialize git if the directory wasn't cloned from GitHub or GitLab.


git init # initializes git

touch .gitignore

Add node_modules and common build output folders to exclude pushing them to your repository.

# .gitignore  

node_modules  
dist  
build
.env

Once all this is done, you can open your folder in your favorite code editor. If you use Visual Studio Code, you can open up the folder by using the command below

code . # opens up the folder in vs code

code . didn't work fix here

Set up the workspace

To set up a workspace, create a new file pnpm-workspace.yaml

touch pnpm-workspace.yaml # creates a new file

Add the configuration below to the workspace file:

# pnpm-workspace.yaml

packages:
 - 'apps/*'
 - 'packages/*'

This configuration tells pnpm that your workspace includes all directories in the apps and packages folders.

Create the apps and packages directory

mkdir -p apps packages

We will break down our apps into two apps/website and apps/api.

**apps/website **The website directory, which we will configure using NextJS. To configure this, we need to change our current working directory to apps.

cd apps

pnpm create next-app website

apps/api The api directory, which we will configure using NestJs.

# monorepo/apps (current working directory)

nest new api --package-manager=pnpm # creates a new NestJS project

Create a Shared UI Library

Great job! You have got your apps set up. Now, let's take things to the next level by creating a shared UI library. This is where the magic of monorepos starts to shine.

packages/library The library directory will contain our shared UI components.

# monorepo 

cd packages

mkdir library && cd library && pnpm init

# monorepo/packages/library/package.json 
{
  "private": true,  
  "name": "library",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}

Note we declare it as private by setting privateproperty to true; this is because we don't want to publish it to NPM or somewhere else, but rather just reference and use it locally within our workspace.

In our library folder, we will install the following: React as a dependency and TypeScript as a development dependency.

# monorepo

pnpm add --filter library react  
pnpm add --filter library typescript -D

The --filter library in the installation command, tells pnpm to install these NPM packages locally to the library package.

To keep things simple, we will make use of the TypeScript compiler to compile our package. We could have a more comprehensive arrangement for bundling numerous files together, using something like Rollup or Vite.

To use the TypeScript compiler, we are going to create a tsconfig.json file at the root of our library directory and add the configuration below.

# monorepo/packages/library/tsconfig.json 
{  
  "compilerOptions": {  
    "jsx": "react-jsx",  
    "allowJs": true,  
    "esModuleInterop": true,  
    "allowSyntheticDefaultImports": true,  
    "module": "commonjs",  
    "outDir": "./dist"  
  },  
  "include": ["."],  
  "exclude": ["dist", "node_modules", "**/*.spec.ts"]  
}

Next, we will update the package.json file main property to match the output directory specified in tsconfig.json and also add a build script.

# monorepo/packages/library/package.json 
{
  "private": true,
  "name": "library",
  "version": "1.0.0",
  "description": "",
  "main": "dist/index.js",
  "scripts": {
    "build": "rm -rf dist && tsc"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "react": "^18"
  },
  "devDependencies": {
    "typescript": "^5.5.4"
  }
}

Creating our first shared library UI component

Let us create a simple select component first Create the file in our library directory.

# monorepo/packages/library 

touch Select.tsx
# monorepo/packages/library/Select.tsx 

function CustomSelect(props: any) {  
   return <select onChange={(e) => props.onChange(e)}>
            {props.children}
          </select>;  
}

export default CustomSelect;

We also want to have a public API where we export components to be used outside of our library package. To achieve this, we will create an index.tsx file and export the Select component we just created.

# monorepo/packages/library 

touch index.tsx
# monorepo/packages/library/index.tsx 

export * from './Select';

Building our library

pnpm --filter library build

Consuming our library package from the NextJs app

Congratulations! You just created your own shared UI library component. To use this library inside our NextJS app in the apps directory, you can add it using pnpm or manually.

pnpm add library --filter website --workspace

This adds the library package as a website dependency

{
  "name": "website",
  "version": "0.1.0",
  "private": true,
  ...,
  "dependencies": {
    "library": "workspace:*",
    ...
  },
  "devDependencies": {
    ...  
  }
}

We are almost done. Let us update the library dependency value to "workspace:*". This means we want to resolve the package locally rather than from a registry like NPM, and * means we want to always use the latest version.

Now to use our Select Component, all we have to do is import it.

Start up the development server to see the component in action.

pnpm --filter website dev

Setting up scripts for the monorepo

In our root package.json file, we are going to add some scripts to make our workflow easier.

# monorepo/package.json

"scripts": {
 "dev": "pnpm run - parallel - filter \"./apps/**\" dev",
 "build": "pnpm run - recursive - filter \"./apps/**\" build",
 "test": "pnpm run - recursive - filter \"./apps/**\" test",
 "lint": "pnpm run - recursive - filter \"./apps/**\" lint"
}

Congratulations! We did it. This process shows how to set up a monorepo using pnpm. For a real project, I would recommend using any of the monorepo tools available; I mentioned a few in my previous post. They offer some advantages over pnpm.

GitHub Repository

Hire Me

Portfolio

Understanding Monorepo: A Deeper Dive

Ukpai Chukwuemeka — Sat, 31 Aug 2024 19:46:49 +0000

Hey Devs! , In our previous chat, we talked about monorepos.

If you missed the previous chat Understanding Monorepo, here’s a quick recap; A monorepo is one big repository that houses all of your projects. These projects, packages, or libraries are typically linked by common rationale or business requirements.

Now, you might be thinking, Why would I want to put all my projects into one big repository? Fair question!

In this post we will be diving a little deeper into the rabbit hole, so grab your favorite caffeinated brew.

Let us look at some of the benefits of monorepo:

Benefits of monorepo

1. Code Sharing: It is super easy to share code, packages, and libraries in a monorepo, the copy-and-paste marathons between projects are no more You can write it once and use it across all platforms. You can even publish directly to a public registry.

2. Code Reuse: Monorepo makes your work efficient, the clever little function you wrote at 2 AM. You can reuse it across apps, packages, or libraries inside a monorepo with just a quick import.

3. Sharing Types: As a typescript fan, your types can now roam free across your codebase like happy little electrons.

4. Easy Bugs Fix: In a monorepo, resolving bugs across multiple projects is easy. It eliminates the need to hop between repositories like a caffeinated kangaroo.

5. Faster Development: Words on the street is that monorepos are flipping software development on its head. Some folks are saying it is like strapping a rocket to your development process — you build, ship, and tweak faster than ever.

Monorepos are pretty sweet, right? But hold up monorepos aren’t all unicorns and rainbows. They’ve got their challenges too.

Monorepo Challenges

Managing a large codebase can be complex, especially for new team members.
Merging changes and resolving conflicts can be more difficult if not well configured.
Specialized tools are often needed to manage monorepos effectively.
Cloning a large monorepo codebase might take a lot of time, especially with bad connectivity, but i guess this doesn’t count.
A monorepo requires a more sophisticated CI setup.
Lastly, it requires you to think about large-scale changes.

Choosing the Right Monorepo Tool

To mitigate the challenges and fully leverage the benefits of monorepos, selecting the right tools is crucial and there are various tools out there. These tools are also what makes monorepo tick. Some popular options include:

NX: A versatile, smart, and fast-build system with features like caching and parallel execution.
Bazel: Google’s build system on steroids, A high-performance build system, especially suitable for large-scale projects, it is open source and i believe it is owned and used by Google internally too.
NPM, Pnpm, and Yarn: The holy trinity of JavaScript package managers, they are popular package managers that can be used in monorepo setups. I think this too can be challenging to manage.
Turbo Repo: A modern monorepo tool with a focus on performance and developer experience. Vercel’s new kid on the block
Lerna: The OG monorepo tool with a focus on flexibility.
Rush stack: Microsoft’s scalable monorepo manager.
Git submodules: A more traditional approach, but can be challenging to manage. Also for those who like to keep it old-school.

Monorepo structure
There are two types of monorepo structures, and the structure is determined by what you plan on building or your use case.

Package-centric is used for developing and publishing an organized collection of reusable packages. This is a common setup in the open-source world and can be seen in repositories such as Angular, React, Vue, and many others. Those repos are characterized by most commonly having a packages folder which are then commonly published to some public registry such as NPM.

App-centric is used mainly for developing applications and products. This is a common setup in companies. Such repos are characterized by having an apps and packages or libs folder, where the apps folder contains the buildable and deployable applications, while the packages or libs folder contains libraries that are specific to one or multiple applications that are being developed within the monorepo. You can still also publish some of these libs to a public registry.

Your Thoughts on Monorepos

Do you think the benefits of monorepos outweigh the challenges? Have you had experience using monorepos in your projects? Share your thoughts and experiences in the comments below.

In our next post, we will dive deeper by setting up a monorepo using just pnpm.

Stay tuned! Happy coding!

Understanding Monorepo

Ukpai Chukwuemeka — Thu, 22 Aug 2024 10:16:05 +0000

Hey there, fellow devs! Ever felt like you’re drowning in a sea of repositories? Well, let me introduce you to monorepo. It might just be your new best friend.

What is a monorepo?

So picture this: instead of juggling a lot of different repositories, you only need one big repository that houses all of your projects. That is a monorepo, in a nutshell. But do not get it twisted; it is not the same as that monolithic architecture we all love to hate.

I recently discovered monorepo and was pleasantly impressed by it. Monorepo has existed since the early 2000s! and tech behemoths like Google and Facebook have been employing them for years. Talk about arriving late to the party.

Monorepos are not entirely the new kid on the block, but they’ve recently gained much attention. And why is that? As our initiatives become increasingly connected, we will require smarter methods to keep everything under control.

Do you want to see monorepos in action? You can check out the list below:

React Email (GitHub: resend/react-email)
Highstorm (GitHub: chronark/highstorm)
Dub (GitHub: dubinc/dub)
React (GitHub: Facebook/react)
Angular (GitHub: angular/angular)

Did you look at the list and still could not spot why they are monorepos?

Well, here is how you can easily spot a monorepo. If you’re browsing through a repository and notice multiple packages or apps inside, there is a big chance you just stumbled upon a monorepo. It’s that simple.

Stick around, and we will dig into why they are awesome, how to set up one, and the tools that make them tick. Trust me, whether you are a newbie or a seasoned pro, this monorepo stuff could seriously up your game.

Ready to dive in? Let’s go!

Pre-deployment Checklist: Setting up Husky 🐶

Ukpai Chukwuemeka — Mon, 12 Aug 2024 10:36:47 +0000

As developers, we have all felt the sting of build and test failures after pushing our code. I’ve found that having a pre-deployment checklist can save a lot of headaches. In this article, we will set up Husky to automate crucial checks before committing and pushing code using the pre-commit and pre-push hooks in a Node.js project. This would help us catch potential issues early in the development process.

Now, I know what you’re thinking aren’t there CI/CD pipelines for this kind of thing? And you’re right, there are. But here’s my take: why push code that’s destined to break when you can catch those pesky errors before they ever leave your machine? It’s like giving your code a quick once-over before it heads out the door. Trust me, your future self (and your team) will thank you.

To get started, create a new directory or clone an existing repository

mkdir website # creates a new folder
or 
git clone repository # clones a git repository

cd website #change directory

npm init -y # Initializes a new Node.js project with default settings

We also need to initialize git (assuming it's already a git repository; there would be no need for this)

git init  # initializes a new GitHub repository

Once these steps are completed, install Husky as a dev dependency; hence the -D.

We don’t want to push our node_modules and environment variable (.env) files, so we create a .gitignore file and add node_modules to it.

PS: You can go ahead and add files you don't want to push online, like your environment variable.

npm install husky@latest -D   # installs husky as dev dependencies

touch .gitignore && echo node_modules >> .gitignore   # create a new file called .gitignore and writes node_modules into the file

Once the previous steps are completed, We can go ahead and initialize Husky

npx husky init # initializes husky in the project

Husky creates a new .husky directory

Inside this directory, we are going to create our two new hooks: pre-commit and pre-push.

touch .husky/pre-commit && touch .husky/pre-push # creates 2 new files inside the .husky directory

Inside the pre-commit hook file, we are going to run our test

and in the pre-push, we want to run our application build

Note: This is just an example, and in your case, you can decide to lint your commit messages, code, run tests, etc. upon committing or pushing.

You can also implement this using Git pre-commit and pre-push hooks. Check out the article below by Benjamin Chibuzor-Orie.

How to run tests automatically on each push to the repository

By setting up Husky with these pre-commit and pre-push hooks, you’ve added an extra layer of quality assurance to your development process. This simple setup can save you time and prevent embarrassing mistakes from making their way into your repository. Remember, you can customize these hooks to fit your project’s specific needs. Happy coding!

The Developer's Pre-Deployment Checklist: Catching Bugs Before They Fly

Ukpai Chukwuemeka — Mon, 05 Aug 2024 13:42:34 +0000

In high-stakes professions like aviation and surgery, checklists are essential tools for reducing errors and improving outcomes. They serve as structured reminders of critical steps, ensuring that nothing is overlooked. During my experience as a front-end developer, I've learned the hard way how easily bugs can slip through the cracks, bugs that could cost a company thousands of dollars. This is where the importance of checklists in development comes into play.

The Importance of Checklists in Development

1. Reduce Human error
Developers are humans, and humans make mistakes. A checklist helps ensure that all necessary steps are completed, reducing the likelihood of missing critical tasks.

2. Ensure Consistency Across Team Members
Checklists standardize processes, ensuring that every team member follows the same steps. This consistency is crucial, especially in larger teams where different developers might have varying levels of experience.

3. Improve Code Quality and reliability.
By systematically checking each part of the code, developers can catch potential issues early, leading to higher-quality, more reliable software.

4. Save Time and Resources in the Long Run
While it might seem like an extra step, using a checklist can save significant time and resources by preventing bugs that would be costly to fix post-deployment.

Integrating Checklists into Your Workflow

In today's software engineering processes, we can use tools like Continuous Integration/Continuous Deployment (CI/CD) and Husky to automate parts of the checklist, ensuring code quality and consistency. However, having a personal checklist before pushing code is equally important.

Sample Pre-Deployment Checklist

1. Code Review

Ensure that at least one other team member reviews all code.
Address any feedback or requests for changes.

2. Testing

Run all unit tests and ensure they pass.
Perform integration tests to verify the interaction between different parts of the application.
Conduct end-to-end tests to simulate real-world user scenarios.

3. Linting and Formatting

Run the linter to catch syntax and style issues.
Ensure code is formatted correctly using a tool like Prettier.

4. Performance Checks

Analyze the performance of the new code and ensure it meets the application's performance benchmarks.

5. Security Review

Check for common security vulnerabilities.
Ensure that sensitive data is handled properly and securely.

6. Dependency Updates

Verify that all dependencies are up-to-date and compatible with the codebase.

7. Documentation

Update any relevant documentation to reflect changes in the codebase.
Ensure comments and documents are clear and informative.

8. Final Verification

Manually test the application to catch any issues that automated tests might have missed.
Verify that all necessary environment variables and configuration settings are correctly set.

By incorporating such a checklist into your workflow, you can catch bugs before they fly, ensuring a smoother deployment process and a more robust application. While tools and automation are invaluable, nothing beats the diligence and thoroughness of a well-prepared developer.

Share Your Checklist
Every development team has unique needs and workflows. What does your pre-deployment checklist look like? Share your checklist in the comments below, and let's learn from each other's best practices. Your insights could help fellow developers improve their processes and deliver better software.

Data Structure 102: Types of Data Structure

Ukpai Chukwuemeka — Tue, 05 Jul 2022 14:31:45 +0000

Introduction

In my previous post Data Structure 101 we were able to understand what data-structure is and algorithm

On that note, we would be looking at the types of data-structure.
There are two main types of data structures, These includes;

Primitive Data Structure - They store the data of only one type.
Examples of primitive data structure are integer, character, float.

Non-Primitive Data Structure - is a type of data structure that can store the data of more than one type. Non primitive data structure are classified into two i.e., linear and non-linear data structure

LINEAR DATA STRUCTURE
Elements are stored in a sequential order. Examples; Arrays, Queues, Stacks and Linked Lists.

NON-LINEAR DATA STRUCTURE
Elements are not stored in sequential order. Examples; trees and graphs are non-linear data structures.

Data Structures 101: Introduction to Data Structures and Algorithms.

Ukpai Chukwuemeka — Mon, 20 Jun 2022 17:27:34 +0000

What is Data Structure?

A data structure is a named location that can be used to store and organise data. And, an algorithm is a collection of steps to solve a particular problem.

Learning data structures and algorithms allow us to write efficient and optimised computer programs.

What is an Algorithm?

An algorithm is a set of well-defined instructions to solve a particular problem. It takes a set of inputs and produces the desired output.
For example;
An algorithm to add two numbers:
Take two number inputs
Add numbers using the + operator
Display the result

Qualities of Good Algorithms

Input and output should be defined precisely.
Each step in the algorithm should be unambiguous.
Algorithms should be the most effective among many different ways to solve a problem.
An algorithm shouldn't include computer code. Instead, the algorithm should be written in such a way that it can be used in different programming languages.

With this knowledge, we can choose the most appropriate data structures for specific projects.

Web 3.0 vs Web 2.0

Ukpai Chukwuemeka — Mon, 07 Mar 2022 05:57:00 +0000

Hi, I recently ventured into the web3 space and would like to share with you the difference between web3.0 and web2.0

What's Web3.0

Web3.0 is a fast growing iteration of world wide web based on blockchain technology. Web3 has to do with websites using blockchain technologies.

What's Web2.0

Web2.0 is an iteration of world wide web but without blockchain technology.

Web3.0 vs Web2.0

Web 3.0 will provide access to connected data in a decentralised way VS Web2.0, which primarily stores data in centralised locations.
Web 3.0 payment apps require no personal data and can't prevent payments VS Web2.0 Payment service may decide to not allow payments for certain types of work.
Web 3.0 is decentralised, which means rather than controlled by governments and corporations, as is the case with today’s internet, it's not VS Web2.0 is centralised; data can be manipulated by individuals, governments and corporations.

Some examples of web 3.0 applications
Let’s look at some examples of web 3.0:

Bitcoin – The original cryptocurrency has been around for more than ten years, and the protocol itself is decentralised, although not all of its ecosystem is.
Diaspora – Non-profit, decentralised social network
OpenSea – A marketplace for buying and selling NFTs, itself built on the Ethereum blockchain
Uniswap – Decentralised cryptocurrency exchange

Examples of web 2.0 applications
Web 2.0 applications are not decentralised, data can be manipulated, some examples of web 2.0:

Facebook
Dev.to
Twitter

Blockgames

Nestcoin

Zuri