DEV Community: Denis Morozov

Nuxt 3 Deployment: Automating Environment-Specific Builds with GitHub Actions

Denis Morozov — Sun, 23 Feb 2025 22:39:28 +0000

Introduction

Hi All,

Recently, I needed to prepare a deployment procedure for a Nuxt-based frontend. Based on my experience, I initially expected to create a single build that could be used across all environments — QA, UAT, and PROD. However, I discovered that I had to generate separate builds for each environment, each with its own .env file defining the Strapi URL and other parameters. This limitation arose due to the @nuxt/image library which does not support runtime configuration option for its plugins (we're using Strapi to store images).

Different teams have different workflows—some prefer a single build deployed across all environments (Build-Once, Deploy Everywhere), while others go with separate builds per environment. Both approaches have their pros and cons.

I prefer the first approach due to the following advantages:

Program behavior remains unchanged, ensuring consistency. If only configuration files or databases change, you can guarantee that something working in preproduction will work in production simply by ensuring those configurations match.
It's slightly more robust. You maintain only one "gold" build, reducing the risk of mistakenly deploying a dev version to QA, and so on.

However, due to the limitation I mentioned above, I couldn't use this approach and had to venture into the unfamiliar waters of per-environment builds. Unfortunately, Nuxt’s documentation on this topic is unclear (see Nuxt Deployment Guide), focusing more on exact deployment or testing procedures rather than workflow guidance for development teams.

Environment Setup

To address this issue, I explored and documented a structured approach to handling environment-specific builds in Nuxt, aiming to bridge this gap in the official documentation.

Technology Stack

Nuxt 3
Strapi as the backend
Node.js 18 for building and running
GitHub for storing source code and artifacts

Requirements

Two environments: UAT and PROD
A changelog for each release
The ability to initiate a release by assigning a tag to a commit
The @nuxt/image plugin requires a statically injected (.env) STRAPI_URL, which cannot be placed in runtimeConfig (See the Nuxt Runtime Config Docs)

Workflow

This workflow automates the build and release process by generating environment-specific builds and creating a changelog for each release.

How It Works

Triggering the Workflow: The build and release process is triggered when a tag matching v* is pushed. To deploy to UAT, for example, we assign a tag to the respective commit. The first tag (e.g., v1.0.0) requires a manual CHANGELOG.md generation via:

   git log %YOUR_FIRST_COMMIT%..${{ env.TAG_NAME }} --pretty=format:"%h %s by %an"

Please refer to the Git documentation for a detailed explanation of the output format.

Repository Permissions: The workflow requires write access to create releases and attach artifacts.
Changelog Generation: The difference between the current and previous tags is used to generate a meaningful changelog.
Environment-Specific Configuration: GitHub Action Secrets store the Strapi backend URL for each environment, ensuring secure and correct configurations.
Release Artifacts: Each release includes two build artifacts, one for UAT and one for PROD, ensuring proper separation.

GitHub Actions Workflow:

on:
  push:
    tags:
      - 'v*'

permissions:
  contents: write

env:
  artifact_package_name: project61-nuxt

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [18.x]
        environment: [UAT, PROD]
    steps:
      - uses: actions/checkout@v4
      - name: Save tag as environment variable
        run: echo "TAG_NAME=${GITHUB_REF#refs/tags/}" >> $GITHUB_ENV
      - name: Store artifact package name as environment variable
        run: echo ARTIFACT_NAME=${{ env.artifact_package_name }}-${{ env.TAG_NAME }}-${{ matrix.environment }}.tar.gz >> $GITHUB_ENV
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v3
        with:
          node-version: ${{ matrix.node-version }}
      - run: |
          yarn install --immutable --check-cache --non-interactive
      - name: Load Environment Variables
        run: |
          echo "STRAPI_URL=${{ secrets[format('{0}_STRAPI_URL', matrix.environment)] }}" > .env
      - name: Build Nuxt App
        run: |
          npx nuxt build
      - name: Pack build artifacts
        run: >
          tar zcvf ${{ env.ARTIFACT_NAME }} .output
      - name: Upload Artifact
        uses: actions/upload-artifact@v4
        with:
          name: ${{ env.ARTIFACT_NAME }}
          path: ${{ env.ARTIFACT_NAME }}

  release:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Download All Artifacts
        uses: actions/download-artifact@v4
        with:
          path: dist
          merge-multiple: true
      - name: Save tag as environment variable
        run: echo "TAG_NAME=${GITHUB_REF#refs/tags/}" >> $GITHUB_ENV
      - name: Store previous tag
        run: echo "PREV_TAG_NAME=$(git describe --abbrev=0 --tags $(git rev-list --tags --skip=1 --max-count=1))" >> $GITHUB_ENV
      - name: Create changelog
        run: |
          echo ${{ env.PREV_TAG_NAME }}..${{ env.TAG_NAME }}   
          git log ${{ env.PREV_TAG_NAME }}..${{ env.TAG_NAME }} --pretty=format:"%h %s by %an" > CHANGELOG.md
          ls -l dist/
      - name: Create Release
        run: gh release create ${{ github.ref_name }} dist/*.tar.gz --title "Release ${{ github.ref_name }}" --notes-file CHANGELOG.md
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Conclusion

This workflow streamlines the deployment process by automating build creation, versioning, and changelog generation. Each environment gets its own dedicated build, ensuring proper separation and accurate testing. By using GitHub Action Secrets, environment-specific configurations remain secure, and every release includes artifacts for both UAT and PROD.

Oh, and one final discovery—while generating changelogs, we realized that some developers might need a refresher on writing meaningful commit messages. Turns out, "fix stuff" and "update" aren't the most helpful descriptions when trying to track changes! 😅

Async Cache Service - you don't need "isLoading" anymore!

Denis Morozov — Tue, 23 May 2023 02:07:27 +0000

What I built

Simple Javascript library to manage asynchronous cache/storage in app/service.

Category Submission:

The best category matches my project is Wacky Wildcards

App Link

You can find library page and package here - Async Cache Service on NPM

Screenshots

Description

The asynchronous cache service is designed to handle the storage and retrieval of data in a non-blocking manner. When data is being loaded into the cache, the service returns a Promise object to the requester. This Promise serves as a placeholder or notification that the data is currently in the process of being fetched.

Once the data loading process is complete and the data is successfully retrieved, the cache service resolves all previously issued Promises associated with that specific data. By resolving the Promises, the cache service effectively provides the updated and complete data to all subscribers or requesters who were waiting for it.

How to use

Typescript Example:

import { AsyncCacheService } from 'async-cache-service';

// by default - the cache is never expire
const cacheService = new AsyncCacheService<string>();

// with 5min expiration
const cacheService = new AsyncCacheService<string>(300_000);

// as a dependency with 15min expiration
export class SomeDataService {
  constructor(private cacheService = new AsyncCacheService<string>(900_000)) {}
}

Javascript Example:

import {AsyncCacheService} from 'async-cache-service';

class DataService {
  // cache expires in 15min
  constructor(cacheService = new AsyncCacheService(15 * 60 * 1000)) {
    this.cacheService = cacheService;
  }

  async getData(id) {
    if (this.cacheService.isExpired(id) {
      this.cacheService.refreshItem(id);

      try {
        // retrieve data from somewhere
        const data = await axios.get('/some/resource');
        this.cacheService.setItem(id, data);
      } catch (e) {
        this.cacheService.flushItem(id);
      }
    }

    return this.cacheService.getItem(id);
  }
}

When the getData method of DataService is called, it returns a Promise, and DataService initiates the data load. During this process, all incoming calls to getData will receive Promises that resolve after the data load. In other words, we eliminate the necessity to have a well-known isLoading flag in our DataService and provide an elegant way to handle multiple data requests.

Link to Source Code

You can find library sources here - Async Cache Service on Github

Permissive License

This project is under MIT License

Background (What made you decide to build this particular app? What inspired you?)

In the preceding article Vanilla JS data cache service, I emphasized the issue of asynchronous data cache and outlined a potential solution. However, after thoughtful consideration, I opted to integrate the suggested approach into a compact Javascript library, accompanied by comprehensive unit tests and leveraging Github Actions for complete CI/CD workflow - encompassing build -> test -> package -> deploy. The resultant library, named "async-data-service", introduces an efficient method to manage asynchronous cache/storage operations with minimal developer overhead.

How I built it (How did you utilize GitHub Actions or GitHub Codespaces? Did you learn something new along the way? Pick up a new skill?)

Well, I used TypeScript (love it!) and Rollup for bundling. For my projects, I prefer to use the Nx build systemit provides me with a lot of pre-defined tools and allows me to focus on what I do. For unit tests, I used the Jest framework. The real challenge for me in this project was to utilize GitHub Actions for NPM publishing.

The most available resources describe the publishing process in a pretty straightforward way, like (taken from official :

name: Publish Package to npmjs
on:
  release:
    types: [published]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      # Setup .npmrc file to publish to npm
      - uses: actions/setup-node@v3
        with:
          node-version: '16.x'
          registry-url: 'https://registry.npmjs.org'
      - run: npm ci
      - run: npm publish
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

Which isn't really helpful. How does "npm ci" relate to "npm publish"? What is the difference between a "published" release and a "created" release? And finally, where are my built artifacts?

So, I need to find answers. The first thing I resolved was the question regarding the difference between "created" and "published" events for releases. Actually, the "created" event is emitted only for draft releases, while the "published" event is emitted for non-draft releases. Therefore, I will use the "published" event in my Github Actions.

Next, I have to consider that Nx puts build artifacts into the "dist/packages/async-cache-service" folder. Therefore, I need to run "npm publish" from there. As a result of my GitHub Actions efforts, I implemented two actions - "push" and "publish".

The "push" action is used to handle the push event of a pull request and performs the build and test of the proposed changes:

name: Node.js CI

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:

    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [18.x]

    steps:
      - uses: actions/checkout@v3
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v3
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm ci
      - run: npm run build --if-present
      - run: npm test

The "publish" action is used to handle the release publish event and performs the build, test, and publish steps for the release in two steps:

name: Publish Package to npmjs
on:
  release:
    types: [published]
jobs:
  build:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [18.x]

    steps:
      - uses: actions/checkout@v3
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v3
        with:
          node-version: ${{ matrix.node-version }}
      - run: |
          npm ci
          npm run build --if-present
          npm test 
      - name: Archive production artifacts
        uses: actions/upload-artifact@v3
        with:
          name: artifact
          path: dist/packages/async-cache-service

  download:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Download build step artifact
        uses: actions/download-artifact@v3
        with:
          name: artifact
      - uses: actions/setup-node@v3
        with:
          node-version: '18.x'
          registry-url: 'https://registry.npmjs.org'
      - run: npm publish
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

As you can see, this action contains two steps - build and publish. The build step performs the build, test, and stores the build artifacts into the Github storage. The publish step retrieves the just created build from the build node and publishes it into the NPM registry.

In summary, I find myself very interested in using GitHub Actions for my current and future projects. I love the way it works. My next step is to adopt GitHub Actions for another project I'm working on, written in C.

Additional Resources/Info

Demystifying Nx's "dependsOn" configuration

Denis Morozov — Sun, 07 May 2023 02:07:18 +0000

We're using Nx in our multirepos to build our Node/Nest apps, as well as Angular. It was a long story how we migrated from Angular Workspace repo for web apps, and single repos for NodeJS/Nest, but in this article I'd like to focus on "dependsOn" property of project.json and how we treat it.

Nx documentation contains a good portion of "dependsOn" description - https://nx.dev/reference/project-configuration#dependson but as for me it still not clear how does "dependsOn" inside "targetDefaults" interact with project-level "dependsOn".

In our project we're utilizing some shared libraries which can be used for Angular apps and for NodeJS/Nest apps as well, i.e. some models definitions and so on. Thus, it is important that those libraries should be built before other apps. That's why we included libraries definitions into "targetDefaults". From other hand we have got some script which need to be run before build, so we create a separate task inside project.json to describe it.

 "injectBuildVersion": {
   "executor": "nx/run-script",
   "options": {
     "script": "inject-build-version some-app"
   }
 }
 "targetDefaults": {
   "build": {
     "dependsOn": "some-lib"
   }
 },
 "dependsOn": ["injectBuildVersion"]

as a result the application was failing to build, because library wasn't built yet. But we noticed that "injectBuildVersion" was executing correctly.

The reason of such behavior is that project-level "dependsOn" overrides "targetDefaults". Moreover, this behavior already described somewhere in Nx issues :-) To make it work, we have to include a special dependency "^build" into project-level "dependsOn" property, like this:

 "injectBuildVersion": {
   "executor": "nx/run-script",
   "options": {
     "script": "inject-build-version some-app"
   }
 }
 "targetDefaults": {
   "build": {
     "dependsOn": "some-lib"
   }
 },
 "dependsOn": ["injectBuildVersion", "^build"]

Now, everything works as expected, build version value (which comes from Jenkins) injects into environment.ts file, and then Nx performs the build with all necessary dependencies. Good job, Nx!

Singletons in JS And How To Use Them

Denis Morozov — Wed, 07 Sep 2022 02:20:18 +0000

Hi Team,

Today, I'd like to tell about singletons and how we are using them on daily-basis.
So, singleton pattern allows us to create single instance of particular class. For which purposes can it be helpful? We are using them for:

data interchange services, which take care about data transferring to/from underlying services
data processing services, which can be instantiated only once on application start
cache services
testing purposes

For example, we decided to continue with previously described Cache Service (https://dev.to/frozer/vanilla-js-data-cache-service-1ei2), for some reasons we don't need multiple
cache services in our app, so how we are going to create a singletone?

Let's start with very basic code to create a singletone:

class SingletoneService {
  static instance;

  getInstance(args) {
    if (!SingletoneService.instance) {
      SingletoneService.instance = new SingletoneService(...args);
    }

    return SingletoneService.instance;
  }

  constructor(args) {
    // do something with args
  }

  doSomething() {
    // do something
  }
}

So, how does it work? In the main program we can create instance of singleton by calling this getInstance method with arguments (if we need them):

function main() {
  const instance = SingletoneService.getInstance();

  instance.doSomething();
}
main();

By calling the getInstance method it checks for static instance field value of class SingletoneService, and then instantiate a new object based on that class using the new keyword. If it exists, it simply returns the existing instance.

Now, once the draft implementation is done, try to move this functionality into our CacheService:

class SomeServiceWithDataCache {
  static instance;

  getInstance(args) {
    if (!SomeServiceWithDataCache.instance) {
      SomeServiceWithDataCache.instance = new SomeServiceWithDataCache(...args);
    }

    return SomeServiceWithDataCache.instance;
  }

  constructor() {
    this.cache = {
      isLoading: false,
      expire: 0,
      data: null
    };
    this.cacheSubscriptions = [];
  }
  ...
}

Also, you can use singletones to inject dependency to your class:

class DataProcessingService {
  // use existing DataCacheService instance by default
  constructor(cacheService = DataCacheService.getInstance()) {
    // do something in constructor)
  }
  ...
}

Which allows you to implement code isolation and Open-Closed principle.

Vanilla JS data cache service

Denis Morozov — Mon, 11 Jul 2022 01:35:09 +0000

Hi Team,

Some time ago I faced an interesting task to solve, and today I'd like to share what I found. Let's imagine that we have a service which needs to load some data (sounds familiar, huh?),

Also we've got several "customers" which utilize the data retrieval method from this service, and for first look all works fine, but when I opened the Developers Console, I was wondering how much duplicate data requests we got there!

Here is our initial implementation of that service (I rewrote it to be more general):

// let's assume we have some network slowness there...
const delayedDataFetch = () => new Promise((resolve) =>
  setTimeout(() => resolve([1, 2, 3]), 2000)
);

class SomeService {
  async getData() {
    return await delayedDataFetch();
  }
}

// ...
// emulation of parallel requests for the same data
function main() {
  const service = new SomeService();
  await Promise.all([
    service.getData(1),
    service.getData(2)
  ]).then(
    ([res1, res2]) => {
      // receives correct data
      console.log(`1. ${JSON.stringify(res1)}`);
      // receives correct data once again, 
      // from the second call to delayedDataFetch
      // and I want to get rid of that second data call to server
      console.log(`2. ${JSON.stringify(res2)}`);
    }
  );
}

Well, my first thought was to implement a some little cache for such data:

const CACHE_EXPIRATION_TIME_MS = 5000;

class SomeService {
  constructor() {
    this.cache = {
      isLoading: false,
      data: null,
      // current timestamp plus expiration delay
      expire: 0
    };
  }

  // added sequenceId for more clarity
  async getData(sequenceId) {
    console.log(`Received ${sequenceId} request`);

    // if cache is expired and isLoading is false 
    // - initiate data update from server
    if (this.cache.expire < new Date().getTime() && !this.cache.isLoading) {
      this.cache.isLoading = true;

      this.cache = {
        isLoading: false,
        data: await delayedDataFetch(),
        expire: new Date().getTime() + CACHE_EXPIRATION_TIME_MS
      };
    }

    console.log(`Response ${sequenceId} with data`);
    return this.cache.data;
  }
}

It works! At least, as I can see from Network Tab the number of networks requests reduced to one. Looks like I can submit this code to repo.

But... hold on, I just started to receive errors from other parts of applications, and the main issue here, that they are different from time to time. Quick searching gives me a new problem - the new code returns null data from time to time.

So, this simple approach didn't solve the problem completely. Let's look closely to this code of getData method:

  // a first request switch isLoading to true, and...
  if (this.cache.expired < new Date().getTime() && !this.cache.isLoading) {
    this.cache.isLoading = true;
    // ... do something
  }

  // the second one simply receives empty data... 
  console.log(`Response ${sequenceId} with data`);
  return this.cache.data;
}

Gotcha! I found! But how can we say our "customers" that they need to wait? Of course, I can switch to RxJS f.e., but I don't want to bubble up the size or our bundle, and I was eager to reach the goal using more vanilla approach.

I started about to return an another Promise to the second response:

  // a first request switch isLoading to true, and...
  if (this.cache.expire < new Date().getTime() && !this.cache.isLoading) {
    this.cache.isLoading = true;
    // ... do something
  }

  if (this.cache.isLoading) {
    // it should return something to client in such cases, 
    // which "something" should be resolved back to refreshed data
    console.log(`Response ${sequenceId} with unresolved promise`);
    return new Promise(resolve => ???);
  }

  // the second one simply receives empty data... 
  console.log(`Response ${sequenceId} with data`);
  return this.cache.data;
}

I was thinking about how I can resolve it, and a flash brighten my brain :-) - I need a simple PUB/SUB!
I decided to add an additional subscribers pool into SomeService class and renamed it to SomeServiceWithDataCache:

class SomeServiceWithDataCache {
  constructor() {
    this.cache = {
      isLoading: false,
      expire: 0,
      data: null
    };
    this.cacheSubscriptions = [];
  }

and change the code of getData method accordingly:

  async getData(sequenceId) {
    console.log(`Received ${sequenceId} request`);
    if (this.cache.expire < new Date().getTime() && !this.cache.isLoading) {
      this.cache.isLoading = true;

      this.cache = {
        isLoading: false,
        data: await delayedDataFetch(),
        expire: new Date().getTime() + CACHE_EXPIRATION_TIME_MS
      };

      // once we receive data - iterate over subscribers pool, 
      // and resolve each with received data, and finally drop
      // subscriptions
      await Promise.all(
        this.cacheSubscriptions.map((res) => res(this.cache.data))
      ).then(() => (this.cacheSubscriptions = []));
    }

    if (this.cache.isLoading) {
      console.log(`Response ${sequenceId} with unresolved promise`);
      // push the promise resolve into subscribers pool
      return new Promise((resolve) => this.cacheSubscriptions.push(resolve));
    }

    console.log(`Response ${sequenceId} with data`);
    return this.cache.data;
  }
}

Well, how it works - it receives the first data request from client, founds that internal data cache is expired, and initiates data loading. For the second request it returns the unresolved Promise, and put the resolver function into the subscribers pool. Once it receives data from server it iterates through the subscribers pool and call resolver with an actual data. That's it.

You can find complete code for the solution on CodeSandBox - https://codesandbox.io/s/simple-data-caching-service-cds83d

SCRUM Retrospective meeting is for what?

Denis Morozov — Sat, 19 Sep 2020 18:19:03 +0000

Hi Devs,

Most of us tackled with SCRUM at least at once. As for me, I do my job about five years using the SCRUM methology. It helpful, it allows us to deliver features and fixes more predictive and transparent, and sometimes, in time :-) you know what I mean. I was a SCRUM master, team leader, ordinal developer, chief... and know what? I still can't understand why we need retrospective.

Last Friday we had one, and our SCRUM master opened a Word document with empty three-column table and asked us the question - "John/Sam/Dan, what you think about last sprint, what was good, what we need to change and what is ugly?". You know that question and I always in trouble what I should to answer. Look, I have a lot of JIRA's, I communicated well with others (BAs, QAs) to get them to solve, and I solved them. Nothing to say - ALL GOOD! And everyone of us said nothing, because - all works well. Right after the meeting, our SCRUM master said that my team-mates "aren't evolved into product". Hey dude, these guys deliver features/fixes every two week in-time and mostly error-free, you can't judge them for the silence on the Retrospective meeting!

If I can't communicate with someone, have hardware problem, or my IDE license has been expired - I don't need to wait until end of the sprint, to tell about it on the retrospective, otherwise I won't do my job well.

As SCRUM methology said - "discuss problems and circumstances with other team-mates..." Cool, but I have time to discuss about on the daily meetings.

So, what do you think about Retrospective? How do we need to cook it well?