Forem: Bruce Simiyu

Build, Deploy, and Host Your Vite App on GitHub Pages with GitHub Actions CI/CD

Bruce Simiyu — Mon, 21 Aug 2023 00:52:42 +0000

Build, Deploy, and Host Your Vite App on GitHub Pages with GitHub Actions CI/CD

GitHub Actions is a powerful, flexible, and user-friendly CI/CD platform that allows you to automate your build, test, and deployment pipeline from idea to production. With GitHub Actions, you can define, create and share actions to perform a job without leaving the GitHub environment. An example of a possible job you’d like done includes combining actions in a custom workflow for CI/CD.

GitHub Actions allows you to run a workflow on any GitHub events like issue creation, new release, or push. Whether you want to deploy on a web service, build a container, or automate new users to your open-source projects, an action is available for that. GitHub offers Linux, macOS, and Windows virtual machines to run your workflows. However, you can use your self-hosted runners in cloud infrastructure or your own data center.
GitHub Actions support your language of choice such as .NET, Rust, Go, PHP, Ruby, Java, Python, and Node.js. I will take you through building a CI/CD workflow for a React project. We will use Vite to scaffold the development environment. Vite is a build tool that aims at offering a leaner and faster development experience for modern-day web projects. To host our app directly from our repository, we will use GitHub Pages. To learn more about GitHub pages, visit GitHub Pages Official docs.

Prerequisites

Node v.16+: Our yaml file is configured to run on machines that have node-version 16. Please update your machine to the latest version.
Some knowledge on running Git commands on Git Bash.
A development environment; I will use Visual Studio Code.
A GitHub Account

We are going to do the following:

Scaffold a new React application with Vite and create its empty repository in GitHub
Set the base of vite.config.js to the name of our repository
Create the .github/workflows/deploy.yaml file and add our custom workflows
Push the app to GitHub, configure GitHub Pages and activate your workflow
Ensure deployment success.

Let’s scaffold a new React application locally and create an empty GitHub repository remotely

The best method to scaffold a React project is by using Vite. Use any of the commands below depending on your package manager:

With NPM: npm create vite@latest my-ghactions-app --template react
With Yarn: yarn create vite my-ghactions-app --template react
with PNPM: pnpm create vite my-ghactions-app --template react

This command prompts you to select a framework and a variant of your choice. For our project, we will use React as our framework and JavaScript as our variant.

Now that we have our Vite application up and running, let’s create a new repository in GitHub.

Before we push our Vite application to the GitHub repository, let’s first;

Add the base in vite.config.js file. Set its name to that of our currently empty GitHub repository.
Create the .github/workflows directory in the root folder. This is where we create our deploy.yml file.

Working with workflows: The .github/workflows/deploy.yaml file

You can configure a GitHub Actions workflow that will be triggered when an event has occurred in your repository, such as when a pull request is opened or when a new issue is created. Your workflow comprises one or more jobs which can run in parallel or in a sequential order. Each job runs inside its own virtual machine runner, or inside a container, and has one or multiple steps that either run a script you define or an action (a reusable extension that simplifies your workflow.)

Workflows

A workflow is a configurable automated process that is going to run a single or multiple jobs. To define workflows, we use a YAML file that is checked into your repository and will run when an event in your repository triggers them.

The YAML files also run at a defined schedule or when manually triggered.

We define workflows in the .github/workflows directory in a repository. A repository can have multiple workflows each of which is set to perform a different set of tasks.

For instance, you can have a workflow that builds and tests pull requests, another workflow that deploys your application every time there is a new release made, and another one that adds a label every time a new issue has been created.

Workflow Basics

The following are basic components a workflow must contain;

One or more event to trigger the workflow
Single or multiple jobs, each of which is going to execute on a runner machine and run a series of one or more steps.
Each step can either run an action, which is a reusable extension that simplifies your workflow, or run a script you define.

Triggering a Workflow

Those events that cause a workflow to run are known as workflow triggers. These events can be:

Events that occur in the workflows of your repository.
Events that occur outside GitHub triggering a repository_dispatch event on GitHub
Scheduled times
Manual

For instance, you could configure your workflow to run when a new release has been created, when a new issue is opened, or when a push has been made to the default branch of your repository.

In our .github/workflows/deploy.yaml file, copy and paste this code.
While copying this file, check on how the spacing of elements is done. Failure might result in a dormant workflow.
Copy and paste this file to your .github/workflows/deploy.yaml without adding any customs.



name: Deploy


on:
  push:
    branches:
      - main


jobs:
  build:
    name: Build
    runs-on: ubuntu-latest


    steps:
      - name: Checkout repo
        uses: actions/checkout@v2


      - name: Setup Node
        uses: actions/setup-node@v1
        with:
          node-version: 16


      - name: Install dependencies
        uses: bahmutov/npm-install@v1


      - name: Build project
        run: npm run build


      - name: Upload production-ready build files
        uses: actions/upload-artifact@v2
        with:
          name: production-files
          path: ./dist


  deploy:
    name: Deploy
    needs: build
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'


    steps:
      - name: Download artifact
        uses: actions/download-artifact@v2
        with:
          name: production-files
          path: ./dist


      - name: Deploy to GitHub Pages
        uses: peaceiris/actions-gh-pages@v3
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          publish_dir: ./dist

We have everything required to run our workflows now. Push the Vite app to GitHub and activate your workflow.

Upon pushing your Vite app to GitHub, wait as the build and deploy checks are running. Running checks are indicated by a yellow spinning dot. A green checkmark represents successfully run checks while a red one indicates failed checks.

We expect a red mark that indicates failing checks because on pushing the code to the repository, the build process will run successfully but the deploy check will fail because we have not yet instructed it where we are deploying from.

Workflow permissions and Deploying to GitHub Pages

Navigate to “code and automation” in the repository settings. Here, we will click Actions to prompt a dropdown. Clicking “General” allows us to set our workflow permissions to “read and write permissions”. Save the changes and rerun the failed workflows.

Our failed deploy workflow rerun successfully and popped green checks indicating that our app is ready.
Once the build and deploy steps run successfully, we can find our site’s file in the gh-pages.
To see our app, we are supposed to build our GitHub Pages site from the gh-pages branch where our files are located.

Publishing your app might take a moment so don’t be in panic once you cannot see your site live.

The default domain of a site you’d like to publish to GitHub is .github.io, where is your GitHub username.
For instance, if my GitHub username is Brucedevnairobi, my published site’s domain name would be Brucedevnairobi.github.io. However, you can create a custom domain name that allows you to serve your site from a domain other than .github.io.

Other web hosting environments you would use for your applications rather than GitHub Pages include Netlify, GitLab Pages, Vercel, Heroku, Firebase Hosting, Amazon S3, Amazon EC2, among many more.

You are all set

Any changes you make locally will be sent to production upon pushing your code to the GitHub repository. However, this only happens when your build and deploy steps run successfully. While you have sites in production, you can introduce new features without having to pull the site down.

Why use GitHub Actions in your development

Improved and simplified collaboration
As software development teams scale, quality and reliability of software is not compromised since all workflows are stored in GitHub where everyone can access and contribute. Workflows could also be configured to check every pull request before merging. This ensures code that is below the quality agreed upon from making it to deployment.
Improved workflow visibility
You can track the progress of your releases and spot any occurring problem because GitHub Actions offers visibility into your build, test and deployment processes. You have a track of how often you have pushed changes to GitHub and deployment history visible.
Automating saves time, increasing speed
With GitHub Actions, automation of tasks such as building, testing and deployment frees up development teams to focus more on more strategic and creative work. More time is spent in innovation and writing code rather than debugging and writing tests.
Reduced errors
Automating your build, test, and deploy process reduces the number of errors likely to make it to your software releases. Not only does this improve the quality of your software, but also saves you time and energy.
Security
You can be confident that your data and code are safe since GitHub Actions shares the same security infrastructure as GitHub. While you could use secrets to protect sensitive data, your GitHub Actions workflows are encrypted while in transit and at rest.

Conclusion

As software development becomes more demanding and complex, and team sizes increase, there is a need to have reliable and quality software. CI/CD are two essential practices in software development. While CI ensures that code changes have been integrated into the codebase automatically and frequently, CD ensures that those changes have been deployed to production reliably and safely. CI/CD can also be used to deploy software to a variety of environments for example, containers such as Kubernetes, edge devices, and in the cloud. GitHub Actions CI/CD is one powerful tool I encourage you to use and you will be shocked by how much you were missing out on. In the future, we can predict more automation on CI/CD and its integration with other devOps tools. GitHub Actions is built on top of GitHub, so there’s no need to learn any new platforms or tools. Creating a new workflow will only take you a few minutes, and there are many pre-made actions available you could use to automate your build, test, and deployment processes.

Beginner's Guide to Tailwind CSS and the Just-In-Time Engine

Bruce Simiyu — Sun, 19 Feb 2023 17:41:29 +0000

Beginner’s guide to Tailwind CSS and the Just-in-Time Engine

Tailwind CSS is a utility-first CSS framework stacked with a variety of classes that could be composed to come up with any designs and interfaces in your markup. First released in May 2019, it is currently at version 3.2. Since its release, it has created a sizeable following of developers using it to enrich their design systems.
It is stats like these that make Tailwind CSS a key developer’s asset for user interface development. Its vast array of features makes it an ideal choice for a wide variety of projects. While other frameworks use predefined components in styling, Tailwind uses utility-first classes. Examples of utility classes include; text-white, font-bold, bg-purple-700, hover:bg-purple-800, py-2, and, rounded.
Prerequisites

A good command for custom CSS
Basic understanding of HTML

Injecting Tailwind utilities, base styles, and components into your static HTML Document

Tailwind CSS runs by scanning your JavaScript templates, HTML files, and other templates in search of class names, invoking these parallel styles, and then converting them to their related static CSS files. It is fast, flexible, and reliable- with zero runtime.

Unlike other CSS frameworks, like Bootstrap, Material UI, and Foundation, Tailwind CSS being a utility-class-based framework, does not provide users with pre-defined component classes. You will define the interface of your components by combining several classes depending on your demands in your project. Tailwind CSS lets you harness the power of customization of components to your liking.

Get started with Tailwind CSS using any of the following ways;

Play CDN
Using PostCSS
Using Tailwind CLI In this article, we will focus only on using Tailwind CLI.

Use of the Tailwind CLI tool is the fastest yet simplest way you could get up and running with Tailwind from scratch. A standalone executable is provided if you would like to run Tailwind in the absence of Node.js.

Step 1: Run npm init –y

This command initializes the package.json file that carries your devDependencies and scripts.

Step 2: Run npm i –D tailwindcss
This command will install Tailwind CSS as a devDependency in your package.json file.
Step 3: npx tailwindcss init
The command creates a ‘tailwind.config.js’ file. You can add any customizations you would like to use in this file.

-_ Step 4._

We do have to tell Tailwind CSS where to look for the utility classes. In the module.exports attribute of your tailwind.config.js file, locate where you have your utility classes under the content array.
Tailwind will look for any HTML files in the root, watch them, and compile its content to a static stylesheet.

- Step 5

Create an input.css file in the root folder and add the three layers of Tailwind, that is;
@tailwind base;
@tailwind utilities;
@tailwind components
Additionally, any custom CSS classes you have made and used in your project, but are not offered by Tailwind CSS should be stored here.

_- Step 6: _
Customize the “scripts” object to “build” and “watch” in the package.json
In your “scripts” attribute, you should have a build and a watch command. For development, you will run npm run watch in the terminal. Running npm run build compiles your CSS files that contain Tailwind directives into a single CSS file. The output will contain the Tailwind styles as well as custom styles you might have added to your project.

Remember to flag the “watch” with --watch. This is how your “build” and “watch” should look like;
“scripts”: {
“build”: “tailwindcss –i ./input.css –o ./css/main.css”,
“watch”: “tailwindcss –i ./input.css –o ./css/main.css --watch”
},

- Step 7:

Create an index.html file in your source folder and link the CSS file with Tailwind utility classes, in our case, the css/main.css.

_Step 8: _

Run npm run watch. You are all hooked up and ready to enjoy the goodies of Tailwind CSS.
You will be required to run this command to constantly watch and compile Tailwind CSS whenever you are in development.

Why Tailwind CSS

Revealingly, most developers prefer the framework to create stunning user interfaces in their projects.
The stress that comes with choosing one CSS framework and going extremely hard in it can be tough when you are soaring just fine with your vanilla CSS. At this stage, choosing one framework feels as if you have betrayed the others. Tailwind is designed to let developers craft custom designs without using pre-defined styles or writing additional code.
Tailwind CSS is vastly customizable and has a good variety of components that are easily adaptable to any style. In addition, Tailwind has taken care of modern technologies like grid and flexbox making it more efficient to use as compared to the other CSS frameworks. Other perks that make it an asset for designers include;

- Responsiveness

It sucks to be in a constant wrestle with a handful of syntax of media queries like it happens when you are using vanilla CSS. So Tailwind CSS pre-built classes allow you to craft responsive designs directly into your markup. It has also been proven to be stable, making bugs and breaks a rare occurrence.
The five default breakpoints Tailwind CSS offers are; ‘sm’, ‘md’, ‘lg’, ‘xl’, and ‘2xl’

- Put an end to Naming Conventions

The naming of classes is one of the most stressful jargon of custom CSS. At that moment, you are making guesses on which classes will be specific or generic which is at times overwhelming in a massive project. Additionally, organizing the classes to ensure that they are cascaded is an extra task under your sleeve. These problems are seamlessly solved courtesy of Tailwind CSS which provides utility-based classes. However, in some instances, you will be required to compose names for your classes.

- Ability to remove unused CSS classes

Being a frontend technology, developers demand ultimate responsiveness and get rid of all the unused CSS classes. To achieve this, PurgeCSS comes into play. This minifies your final CSS to the smallest size possible.
Some shortcomings that come with this CSS framework include;

- Mixing of styling and HTML

With preference to separate page structure and style, Tailwind CSS breaks the principle of “separation of concerns”. Styling is done in your markup file, which makes the Tailwind markup process expansive. Where you are working on a small project that requires less styling, the use of Tailwind is an overkill.

- A steep learning curve

The built-in classes make Tailwind CSS learning-intensive, even for experienced developers. Many are posed with the challenge to learn how to use and fully utilize these pre-built classes.

Let’s Activate the Just-In-Time (JIT) Engine

JIT is an on-demand, faster, more powerful engine for Tailwind CSS v2.1+. This engine saves you from building everything upfront leading to quicker build times and certifying that you are using the same stylesheet in development and production.

Why JIT mode?

- Super-fast build times

Tailwind CSS can take up to 8 seconds to compile initially using CLI. In webpack projects, it can take upwards of 30-45 seconds because webpack struggles with large CSS files.
While using JIT, compiling even the biggest projects could take about 800ms no matter the build tool you are using.

- Out-of-the-box enabling of every variant

Due to file-size considerations, variants like ‘focus-visible’, ‘active’, and ‘disabled’ are normally enabled by default. The ability of this library to generate styles on demand gives you the freedom to use any variant you want whenever you want it.
Additionally, you can stack these variants like ‘md:hover:active:disabled:opacity-75’. Upgrade from configuring your variants.

- Generate arbitrary styles without writing custom CSS

In development, it is common to come across the need to use some ultra-specific value that is not part of your design system, for example, using ‘top: -113px’ for a strange background image. Since styles are made on-demand, you can just make a utility for this as needed by the use of square bracket notation like ‘top-[-113px]’. This can also work with variants, like ‘md:top-[-113px]’.

- Identical CSS in development and production

There is no need of purging unused styles for production since styles are made as they are needed. This means that you will have the same CSS in all environments. Bury your worries on the accidental purging of important styles in production.

- Better browser performance in production

The browser does not need to parse and manage multiple megabytes of pre-generated CSS because development builds are as small as production builds. This makes development tools a lot more responsive in projects that have heavily extended configurations.

Activating JIT Engine

To enable JIT mode, in your ‘tailwind.config.js’ file, set the ‘mode’ option to ‘jit’. It is also important to configure the ‘purge’ option in this config file since JIT mode generates your CSS on-demand by scanning your template files, otherwise, your CSS will be blank.
Now when you build runner or start your development server, Tailwind CSS will generate your styles on-demand rather than generating everything in advance.

Final Remarks

While attempting to improve the game on user interfaces, a ton of awesome CSS frameworks and libraries have been built. However, most of these foist design verdicts that tend to be tough to undo. Unlike most of these frameworks, Tailwind CSS utilizes utility-first classes, therefore eradicating the need for dynamic customization. This makes Tailwind CSS a good choice for building 21st-century user interfaces. With all the goodies Tailwind CSS brings to the game, it lies upon a developer’s decision to judge whether the utility classes work just right for them or the pre-defined components. However, if you are quick and confident when it comes to writing custom CSS classes, Tailwind may not be the ultimate choice for you. In addition, Tailwind CSS might not be your user interface design asset if you dislike classes jumbled all over the place.