DEV Community: Petros Kyriakou

How to develop a local package and use in a vite app

Petros Kyriakou — Thu, 18 Apr 2024 11:35:17 +0000

This might be a niche topic, but recently I had to link and develop a shared library that is not part of the same repo as the main app codebase. And there is no monorepo involved either.

On the web the resources to do this are scattered and don't cover hot reloading.

The problem

if you ever came across such a scenario, in such cases the usual workflow is develop the package in isolation, build and release. Then go to the app and update the version number so you can bring the changes in.

BUT, wouldn't it be cool to be able to develop the shared package side by side with live reloading and reflect the changes in the main app, make sure everything is working as expected and THEN release ?

In this article, we are gonna do just that.

Setup

The setup for the purposes of this tutorial is the following:

Package boilerplate generated using tsdx
Basic vite react app with typescript
Using yarn

Shared package

Let's call it @awesome/package (do that by changing your package.json name).

The changes needed here are very few. The main thing to know is that Vite uses ESM and needs to know exactly where to look for the root file so lets help it

in package.json

"exports": {
    ".": {
      "import": {
        "types": "./dist/index.d.ts",
        "default": "./dist/shared.esm.js"
      },
      "require": {
        "types": "./dist/index.d.ts",
        "default": "./dist/index.js"
      }
    },
  },

So what we are saying above is the following.

If you are an ESM consumer (import) use the these types and this is the entry point.

If you are a commonJS consumer (require) use these types and this is the entry point.

Now vite knows what to look for, great!

Vite setup

in vite.config.ts

import {defineConfig, ViteDevServer} from 'vite'
import react from '@vitejs/plugin-react'

// https://vitejs.dev/config/
export default defineConfig({
    plugins: [react()],
    optimizeDeps: {
        exclude: ["@awesome/shared"]
    },
})

By default, Vite likes to optimize deps but in our case since its an ESM lib we want to skip that.

Great, now vite knows about our package.

Yarn setup

Now we need to do two things.

Install the package as a local dependency.

In shared package

The first step is to make sure yarn knows where to look for the package.

yarn link

In main app

yarn add link:./../your-project // here adjust to be the relative path to your project. In case you use pnpm or npm you need to adjust this accordingly - most probably use file: in front.

If you already released and use the package with a specific version. e.g in package.json you already have the package as a dependency like so - "@awesome/shared": "0.0.1" then do the following:

yarn link @awesome/shared

At this point, we have made sure vite is aware of the package, and our package manager, in this case yarn - has made the necessary linking.

Development

In shared package do a change that is meaningful and can be easily observed in the vite app.

Afterwards,

In shared package

yarn start // if you used tsdx to scaffold or else use the equivalent command with your setup

In vite app

yarn dev

You will notice that the shared package change you made is reflected in your vite app.

However, you will notice that making a second change to the package it is not being reflected to the vite app.

Thats because, Vite by design does not watch changes in node_modules and because does caching of the dependencies under node_modules/.vite directory.

The suggestion is to run the following command

yarn dev --force // underneath its vite dev --force

This is too manual for our liking, isn't it?

So, let's see how to fix that.

Adding a plugin to watch specific packages for changes

We need to add a plugin in order to watch for our packages, so here is the final vite.config.ts

import {defineConfig, ViteDevServer} from 'vite'
import react from '@vitejs/plugin-react'

// This plugin will watch node_modules for changes and trigger a reload.
// Works only for build --watch mode.
// https://github.com/vitejs/vite/issues/8619
export function pluginWatchNodeModules(modules: string[]) {
    // Merge module into pipe separated string for RegExp() below.
    const pattern = `/node_modules\\/(?!${modules.join('|')}).*/`;
    return {
        name: 'watch-node-modules',
        configureServer: (server: ViteDevServer): void => {
            server.watcher.options = {
                ...server.watcher.options,
                ignored: [
                    new RegExp(pattern),
                    '**/.git/**',
                ]
            }
        }
    }
}

// https://vitejs.dev/config/
export default defineConfig({
    plugins: [react(), pluginWatchNodeModules(['@awesome/shared'])],
    optimizeDeps: {
        exclude: ["@awesome/shared"]
    },
})

Start the vite app again and do changes to the shared package. They should be reflected to vite app almost instantly.

Bonus

Now that you are able to develop and test your package, you need to unlink the local package and use the version you used when releasing the package with the changes

yarn unlink @awesome/shared

Now update package.json (in vite app) with the latest release version and run yarn to install it.

Conclusion

You have learned how you can easily make changes to a shared package and they are then reflected to your vite app. Now you can be sure the changes work before releasing the shared package.

I hope you found this useful and if you want to keep in touch you can always find me on Twitter.

Introducing Messageraft! # buildinpublic

Petros Kyriakou — Thu, 07 Oct 2021 15:07:15 +0000

Introducing Messageraft 🎉. A single API that can be used to dispatch email, SMS, and chat-based notifications all from a single interface.

Backstory

Since I sold my startup, I have been left with a void that my creative mind was looking for ways to fill.

One of the ideas that I kept coming back to prior to selling my startup was a notification gateway as a service. I went ahead and scratched my itch and MessageRaft is the result of that.

Let's get some things out of the way first.

Notifications gateway, erm whats that doc?

A notifications gateway as the name implies is a portal where notifications pass through. In layman terms, it's basically a server that has an API exposed to other services/apps and receives requests.

And you guess it, notification requests. Simply put, it is a single API that can process multiple types of notifications and dispatch accordingly.

While it is still in its infancy, it is fully functional, the core is open-source hence it is free to use and you can get started in under 2 minutes (your internet connection and computer is the only bottleneck on that!!!)

So, without further ado, I have built and released a CLI which you can use to get started here

Future plans

Messageraft is going to be 100% build in public and its core will always be free. I am looking to see if it picks traction and if it does I plan to create a product around it for people who don't want to host the service themselves plus a magnitude more providers support.

In addition, I have recently released a helper tool that makes it even easier and faster to develop and test emails locally from your machine with the help of MessageRaft which I am going to cover in another article so stay tuned for that!

This is the first time I am building in public and would appreciate any type of feedback you can provide. As always you can find me on twitter

Managing multiple environments in NestJS

Petros Kyriakou — Wed, 22 Sep 2021 16:47:32 +0000

So, recently I started working on a new startup and each time I do, I try to adopt a new technology be it language or framework . (this is not always recommended, in this case I have previous experience with NestJS)

This time around I chose to adopt NestJS. Have used it before for pet projects and found it really fun so I thought why not to use it as the backend for my new startup? Felt like a no-brainer.

The problem

As this is not my first rodeo with startups, I actually take time to set up the backend properly instead of being in an MVP rush mode. One of the things that needed configuration early on, was the separation of environment variables between different modes.

e.g development, test, staging, and production

Looking at the docs there is no real suggestion on how to do that but it gives you breadcrumbs here and there on how to achieve such a thing by putting the pieces together.

So here I am documenting how I did it so you don't have to waste more time on it. Ready? Let's go.

Step 1

Create the following structure in the root of your NestJS app.

Step 2 - Initializing ConfigModule

Open up your app.module and write the following

import { ConfigModule } from '@nestjs/config';

// ...skipping irrelevant code

@Module({
  imports: [
    ConfigModule.forRoot(), 
    PrismaModule,
    ProductsModule,
    AuthModule,
  ],
  controllers: [AppController],
  providers: [AppService],
})

// ...skipping irrelevant code

if we don't pass any options to the ConfigModule by default it is looking for a .env file in the root folder but it cannot distinguish between environments. Let's move onto the next steps where we make the ConfigModule smarter in where to look and what to load

Step 3 - Populating the development.env file

Let's populate the development.env file as a first step towards creating separate environments.

JWT_SECRET=luckyD@#1asya92348
JWT_EXPIRES_IN=3600s
PORT=3000

Step 4 - Populating the `configuration` file

configuration.ts - its main purpose is to create an object (of any nested level) so that you can group values together and make it easier to go about using it.

Another benefit is to provide defaults in case the env variables are undefined and on top of that you can typecast the variable as it's done for the port number below.

// configuration.ts

export const configuration = () => ({
  NODE_ENV: process.env.NODE_ENV,
  port: parseInt(process.env.PORT, 10) || 3001,
   jwt: {
    secret: process.env.JWT_SECRET,
    expiresIn: process.env.JWT_EXPIRES_IN,
  }
});

Then let's pass options to the ConfigModule to use this configuration file like so:


import { configuration } from '../config/configuration'; // this is new

// ... skipping irrelevant code

@Module({
  imports: [
    ConfigModule.forRoot({ 
       envFilePath: `${process.cwd()}/config/env/${process.env.NODE_ENV}.env`,
       load: [configuration] 
    }), 
    PrismaModule,
    ProductsModule,
    AuthModule,
  ],
  controllers: [AppController],
  providers: [AppService],
})

// ...skipping irrelevant code

We have now used two options to configure the ConfigModule.

load

This should be pretty self-explanatory, that it loads the configuration file we are giving it and does all the goodies mentioned above.

envFilePath

We are pointing the module (underneath its using the dotenv package) to read an .env file based on the process.env.NODE_ENV environment variable.

process.cwd() is a handy command that provides the current working directory path

BUT we are just now loading the variables, how do you expect the module to make use of the process.env.NODE_ENV variable before the env variables are loaded?!

Well, read more on the next step!

Step 5 - Initializing the NODE_ENV env variable

First of all, what is the NODE_ENV variable for? Well, it's a practice used by devs to denote which environment they are using.

In short, NODE_ENV lets the app know if it should run in the development, production, you-name-it environment by looking at its value.

There are actually many ways to go about loading env variables, and one of them is to set the variable inline to the execution script like so:

// package.json

"scripts": {
    "prebuild": "rimraf dist",
    "build": "nest build",
    "format": "prettier --write \"src/**/*.ts\" \"test/**/*.ts\"",
    "start": "nest start",
    "start:dev": "NODE_ENV=development nest start --watch",
    "start:debug": "nest start --debug --watch",
    "start:prod": "NODE_ENV=production node dist/main",
    "lint": "eslint \"{src,apps,libs,test}/**/*.ts\" --fix",
    "test": "jest",
    "test:watch": "jest --watch",
    "test:cov": "jest --coverage",
    "test:debug": "node --inspect-brk -r tsconfig-paths/register -r ts-node/register node_modules/.bin/jest --runInBand",
    "test:e2e": "jest --config ./test/jest-e2e.json",
  },

Notice the NODE_ENV=development and NODE_ENV=production above.

When we execute the script using one e.g npm run start:dev it will actually set the variable and will be accessible in your NestJS app. Cool, this gives an answer to the question we had above.

Windows users must install cross-env package as windows doesn't support this way of loading variables and alter the commands like so "start:dev": "cross-env NODE_ENV=development nest start --watch"

Step 6 - Usage

We now have two methods of reaching the values of the env variables

Method 1

As seen above we can make use of the process.env. to access the variables. However, this has some drawbacks in terms of accessing env variables during module instantiation so be mindful of that.

Method 2

Using the ConfigService to access the variables. Setting up the ConfigModule now gives us access to its service which consequently gives us access to the variables

Example

import { Controller, Get } from '@nestjs/common';
import { AppService } from './app.service';
import { ConfigService } from '@nestjs/config';

@Controller()
export class AppController {
  constructor(private readonly appService: AppService, private configService: ConfigService) {}

  @Get()
  getHello(): string {
    console.log(this.configService.get<string>('jwt.secret')
  }
}

Step 7 - Update .gitignore

If you do a git status you should notice that the development.env file is being watched and will be committed. While that is somewhat OK as long as you don't use the same values for example in the production.env lets update .gitignore to ignore .env files:

// .gitignore

// add at the bottom

**/*.env
!config/env/development.env

What it says here, is to ignore all .env files except for development.env

(BONUS) - Validating the env variables

Now we have come full circle but we can go one step further to ensure that our variables are in the correct type and loaded.

Step 1 - Install `joi`

This library will do the heavy lifting of validating our env variables by comparing them against a schema we provide.

npm install joi

OR

yarn add joi

Step 2 - Populate validation.ts

import * as Joi from 'joi';

export const validationSchema = Joi.object({
  NODE_ENV: Joi.string().valid(
    'development',
    'production',
    'test',
    'provision',
  ),
  JWT_SECRET: Joi.string().required(),
  JWT_EXPIRES_IN: Joi.string().required(),
  PORT: Joi.number().default(3000),
});

So what we did above was to make sure that the NODE_ENV is one of the mentioned strings, the JWT_* variables are strings and required, and we require the port to be a number and have a default value (hence why we don't required() a value to be present)

Notice that the validation schema naming must be exactly like it's in the .env file and NOT how you wrote the names in configuration.ts

Step 3 - Update options in `ConfigModule`

import { validationSchema } from '../config/validation';

@Module({
  imports: [
    ConfigModule.forRoot({
      envFilePath: `${process.cwd()}/config/env/${process.env.NODE_ENV}.env`,
      load: [configuration],
      validationSchema,
    }),
    PrismaModule,
    ProductsModule,
    AuthModule,
  ],
  controllers: [AppController],
  providers: [AppService],
})

So here we imported and provided the validationSchema to the module.

Exercise: Try setting up NODE_ENV something else than the four values defined in the validation schema and see what happens

(BONUS 2) - Avoid the need of importing the config module everywhere

There is a handy option to avoid having to import the config module in every module that is being used which is pretty neat. Its called isGlobal and below you can find how it's used

@Module({
  imports: [
    ConfigModule.forRoot({
      envFilePath: `${process.cwd()}/config/env/${process.env.NODE_ENV}.env`,
      isGlobal: true,
      load: [configuration],
      validationSchema,
    }),
    PrismaModule,
    ProductsModule,
    AuthModule,
  ],
  controllers: [AppController],
  providers: [AppService],
})

Summary

You have set up a flexible way of setting up your env variables for each environment in a non-complicated manner while also maintaining type and value integrity by validating the env variables against a schema.

I hope you found this useful and if you want to keep in touch you can always find me on Twitter.

Cheap/Free SMS API ?

Petros Kyriakou — Fri, 16 Aug 2019 21:51:15 +0000

Is there a cheap / free API of sending SMS?

DEV Community: Petros Kyriakou

How to develop a local package and use in a vite app

The problem

Setup

Shared package

Vite setup

Yarn setup

In shared package

In main app

Development

Adding a plugin to watch specific packages for changes

Bonus

Conclusion

Introducing Messageraft! # buildinpublic

Backstory

Notifications gateway, erm whats that doc?

Future plans

Managing multiple environments in NestJS

The problem

Step 1

Step 2 - Initializing ConfigModule

Step 3 - Populating the development.env file

Step 4 - Populating the configuration file

Step 5 - Initializing the NODE_ENV env variable

Step 6 - Usage

Method 1

Method 2

Example

Step 7 - Update .gitignore

(BONUS) - Validating the env variables

Step 1 - Install joi

Step 2 - Populate validation.ts

Step 3 - Update options in ConfigModule

(BONUS 2) - Avoid the need of importing the config module everywhere

Summary

Cheap/Free SMS API ?

Step 4 - Populating the `configuration` file

Step 1 - Install `joi`

Step 3 - Update options in `ConfigModule`