Yet, that's not real life, at least not what you will do when working on a professional project. Your code needs to be versioned and pushed to a location where your colleagues can work on it. The provisioning of Azure resources and deployment to Azure should be carried out using a properly configured CI/CD pipeline with the necessary authorization.

That's a lot of work that would need to be done each time you start a new project. So let's automate that using Pulumi to simplify the process and create an "Azure-Ready GitHub repository".

What's an Azure-Ready GitHub repository?

"Azure-Ready GitHub repository" is not an official term or concept, it's just something I've come up with to describe a Github repository that has everything correctly configured to provision Azure resources or deploy applications to Azure from a GitHub Actions CI/CD pipeline.

The GitHub part

On the GitHub side, to have an Azure-Ready GitHub repository, we need:

• the GitHub repository itself (already initialized with a main branch)

• the necessary GitHub Actions variables/secrets to authenticate to the correct Azure subscription

• a YAML file located in the .github/workflows/ folder that contains the CI/CD pipeline that provisions resources in Azure

The Azure part

On the Azure side, to have an Azure-Ready GitHub repository, we need:

• the existing Azure subscription to which resources are deployed

• an identity in the Azure Active Directory of the desired tenant so that the GitHub CI/CD pipeline can authenticate to Azure and interact with the subscription

  • an Azure AD application that represents the GitHub Actions pipeline identity

  • a Service Principal (related to the Azure AD application) that has the contributor role on the Azure subscription

  • credentials for the CI/CD pipeline to authenticate to Azure on behalf of this Azure AD application

The problem with secret credentials

People tend to use secret credentials to authenticate their pipeline to Azure and that's not the best thing to do.

From a security standpoint, depending on secrets always poses a security risk. Even if in that case the secret would be safely stored in a GitHub secret and never exposed publicly, it's still better to avoid secrets when we can.

From a practical standpoint, depending on secrets can quickly become problematic as they expire and thus require rotation. Of course, you can set up alerting or automate secret rotation but that's something you would prefer to avoid managing.

So what can we do about that?

👉 We can stop using secret credentials and use Workload identity federation instead. I suggest you have a look at this GitHub documentation page as well to better understand how it works but basically, you can remember the following:

• this mechanism relies on Open ID Connect and trust between Azure and GitHub

• the GitHub pipeline does not need an Azure AD application secret anymore to authenticate to Azure

• it's not an Azure thing only, it's an open standard that also works with other cloud providers and other platforms than Github

To establish the trust relationship between the Azure AD application and the GitHub repository, a Federated Identity Credential must be created in the Azure Active Directory. You can find how to do that manually from the portal in the documentation but we are going to directly automate that 😉.

The complete solution to implement

Why use Pulumi in that context?

You might wonder why I chose to automate this process using Pulumi instead of writing a Bash or PowerShell script that would execute commands from the GitHub CLI and the Azure CLI.

I think Pulumi is a better choice here because:

• a script is imperative by nature, but declarative infrastructure seems more suitable to avoid dealing with idempotency

• Pulumi can interact with both GitHub and Azure using its providers

• the code will be easier to write and maintain

• the code could be integrated into any application (including a future self-service infrastructure portal) using Pulumi Automation API

In this article, the Pulumi code will be in TypeScript but it would work in any language supported by Pulumi.

Automate the creation of the Azure-Ready GitHub Repository

Create the Pulumi project

Let's start by scaffolding a new Pulumi project using TypeScript:

pulumi new typescript -n AzureOIDC -s dev -d "A program to set up an Azure-Ready GitHub repository"

This command creates a new pulumi project and stack from the TypeScript template:

• The name of the project "AzureOIDC" is specified using the -n option

• The description of the project "A program to set up an Azure-Ready GitHub repository" is specified using the -d option

• The stack of the project "dev" is specified using the -s option

This project will need 3 different providers:

• the Azure Native provider

• the Azure Active Directory provider

• the GitHub provider

So we can add the following packages to our package.json file:

• @pulumi/azure-native

• @pulumi/azuread

• @pulumi/github

Create the repository on GitHub

To use the GitHub provider, we have to provide GitHub credentials. For that, we can create a personal access token (I prefer to create a fine-grained personal access token although a classic personal access token would also work). Next, we simply set the GitHub token in our Pulumi configuration, and the GitHub provider will automatically use it:

pulumi config set github:token XXXXXXXXXXXXXX --secret

Now, it's time to create our GitHub repository!

import * as github from "@pulumi/github";

const repository = new github.Repository("azure-ready-repository", {
  name: "azure-ready-repository",
  visibility: "public",
  autoInit: true
});

export const repositoryCloneUrl = repository.httpCloneUrl;

Pulumi has an auto-naming capability that is very convenient to prevent name collisions or to ensure zero-downtime resource updates. Yet, in this context, I prefer to avoid a random suffix in my GitHub repository name, that's why I am specifying the name property to override the auto-naming behavior.

The last line creates a stack output named repositoryCloneUrl so that we can easily get the URL to clone our newly created repository.

Create the identity in Azure Active Directory for the GitHub Actions workflow

Creating an Azure AD application and its service principal is not very complicated:

import * as azuread from "@pulumi/azuread";

const aadApplication = new azuread.Application("AzureReadyApp", { displayName: "Azure Ready App" });
const servicePrincipal = new azuread.ServicePrincipal("AzureReadServicePrincipal", {
  applicationId: aadApplication.applicationId,
});

The OIDC trust thing is a bit more complex. Fortunately, Microsoft's documentation has a detailed page Configuring an app to trust an external identity provider that explains everything and shows how to add a federated identity for GitHub Actions using the Azure Portal, Azure CLI, or Azure PowerShell.

Let's do the same thing using TypeScript and Pulumi Azure AD provider:

new azuread.ApplicationFederatedIdentityCredential("AzureReadyAppFederatedIdentityCredential", {
  applicationObjectId: aadApplication.objectId,
  displayName: "AzureReadyDeploys",
  description: "Deployments for azure-ready-repository",
  audiences: ["api://AzureADTokenExchange"],
  issuer: "https://token.actions.githubusercontent.com",
  subject: pulumi.interpolate`repo:${repository.fullName}:ref:refs/heads/main`,
});

The subject property is what identifies the repository where the GitHub Actions workflow will be authorized to exchange its GitHub token for an Azure access token. It's worth noting that it will only work if the GitHub Actions workflow is run on the git reference (branch or tag) or the environment you specify in subject. You can also specify that only workflows triggered by a pull request should be authorized. Here, I have used the main branch but I could create multiple Federated Identity Credentials with different subjects if needed.

With this configuration, the GitHub Actions workflow we create next will be able to obtain a valid Azure access token.

If you are interested in gaining a better understanding of how all this works, you can refer to this diagram from Microsoft's documentation (with GitHub serving as the external identity provider in our case).

Authorize the Service Principal to provision resources on the subscription

We have created everything we need to get a valid Azure access token, but we still have not authorized the application to provision resources on our subscription.

We can do that by giving the Contributor role to our service principal.

import * as authorization from "@pulumi/azure-native/authorization";
import { azureBuiltInRoles } from "./builtInRoles";

new authorization.RoleAssignment("contributor", {
  principalId: servicePrincipal.id,
  principalType: authorization.PrincipalType.ServicePrincipal,
  roleDefinitionId: azureBuiltInRoles.contributor,
  scope: pulumi.interpolate`/subscriptions/${subscriptionId}`,
});

I intentionally did not declare the variable subscriptionId in the code above. It's because it's up to you to choose how you will provide it. You may want to set it in the configuration and retrieve it from it :

const config = new pulumi.Config();
const subscriptionId = config.get("subscriptionId");

Or your might want to retrieve it from the current configuration of the Azure native provider :

const azureConfig = pulumi.output(authorization.getClientConfig());
const subscriptionId = azureConfig.subscriptionId;

Concerning, the contributor role definition identifier, I could have dynamically retrieved it using Azure APIs (like here). But honestly, as these identifiers don't change it's much easier to hardcode it in a dedicated builtInRoles.ts file.

export const azureBuiltInRoles = {
  contributor : "/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"
};

Add the configuration for the GitHub Actions workflow

The next step is to correctly set the configuration for the GitHub Actions of our Azure-Ready GitHub repository.

The workflow requires three pieces of information for the OIDC authentication to function properly:

1. The identifier of the Azure tenant

2. The identifier of the Azure subscription

3. The application identifier (also known as client ID) of the previously created Azure AD application

These identifiers are not secrets, they are just identifiers so we could directly set them as GitHub Actions variables like this:

new github.ActionsVariable("tenantId", {
  repository: repository.name,
  variableName: "ARM_TENANT_ID",
  value: azureConfig.tenantId,
});

However, I like to keep my tenant id and my subscription id private so we will store them in GitHub secrets but that's not mandatory at all.

const azureConfig = pulumi.output(authorization.getClientConfig());

new github.ActionsSecret("tenantId", {
  repository: repository.name,
  secretName: "ARM_TENANT_ID",
  plaintextValue: azureConfig.tenantId,
});

new github.ActionsSecret("subscriptionId", {
  repository: repository.name,
  secretName: "ARM_SUBSCRIPTION_ID",
  plaintextValue: azureConfig.subscriptionId,
});

new github.ActionsSecret("clientId", {
  repository: repository.name,
  secretName: "ARM_CLIENT_ID",
  plaintextValue: aadApplication.applicationId,
});

Create the GitHub Actions workflow

Everything seems to be properly configured to provision Azure resources from a GitHub Actions workflow in this new repository, except for the workflow itself. The goal here is to have a properly configured pipeline in the repository to get started provisioning Azure infrastructure.

Here is such a pipeline:

name: infra

on:
  workflow_dispatch:

permissions:
      id-token: write
      contents: read
jobs:
  provision-infra:
    runs-on: ubuntu-latest
    steps:
      - name: 'Az CLI login'
        uses: azure/login@v1
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

      - name: 'Run az commands'
        run: |
          az account show
          az group list

This workflow first authenticates to Azure using OIDC with the azure/login action and then performs some Azure CLI commands to interact with Azure resources. That's fine and probably enough to get you started but you surely want to provision your infrastructure using a more declarative solution than an Azure CLI script. So let's see a more interesting pipeline still authenticating via Azure OIDC but using Pulumi to provision the Azure resources.

name: infra

on:
  workflow_dispatch:

permissions:
  id-token: write   # required for OIDC auth
  contents: read    # required to perform a checkout

jobs:
  provision-infra:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Install pnpm
        uses: pnpm/action-setup@v2
        with:
          version: latest

      - name: Set node version to 18
        uses: actions/setup-node@v3
        with:
          node-version: 18
          cache: 'pnpm'

      - name: Install dependencies
        run: pnpm install

      - name: Provision infrastructure
        uses: pulumi/actions@v4.4.0
        id: pulumi
        with:
          command: up
          stack-name: dev
        env:
          ARM_USE_OIDC: true
          PULUMI_ACCESS_TOKEN: ${{ secrets.PULUMI_ACCESS_TOKEN }}
          ARM_CLIENT_ID: ${{ secrets.ARM_CLIENT_ID }}
          ARM_TENANT_ID: ${{ secrets.ARM_TENANT_ID }}
          ARM_SUBSCRIPTION_ID: ${{ secrets.ARM_SUBSCRIPTION_ID }}

A permission section is required with 2 settings (more details here):

• id-token: write ➡️ needed to request the OIDC token

• contents: read ➡️ needed to perform checkout action

The 3 steps following the checkout step are actions to specify the Node.js version to use, install and correctly configure pnpm. We assume here the infrastructure will be provisioned using TypeScript (and Pulumi of course) but there would have been similar steps with other runtimes/languages (a setup-dotnet and a dotnet retore action for .NET for instance).

The last action is the Pulumi action to provision the infrastructure by running the pulumi up on the dev stack. We can see that this action uses environment variables whose values are based on the GitHub Actions secrets we defined earlier. To tell Pulumi to use OIDC, we just have to set the ARM_USE_OIDC environment variable to true.

        env:
          ARM_USE_OIDC: true
          PULUMI_ACCESS_TOKEN: ${{ secrets.PULUMI_ACCESS_TOKEN }}
          ARM_CLIENT_ID: ${{ secrets.ARM_CLIENT_ID }}
          ARM_TENANT_ID: ${{ secrets.ARM_TENANT_ID }}
          ARM_SUBSCRIPTION_ID: ${{ secrets.ARM_SUBSCRIPTION_ID }}

A GitHub Actions secret we did not talk about is PULUMI_ACCESS_TOKEN that is a Pulumi access token to use Pulumi Cloud as our backend to store the infrastructure state and encrypt secrets. This token should be:

1. Created from Pulumi Cloud (following the documentation here)

2. Stored in the stack configuration using the following command pulumi config set pulumiTokenForRepository ******* --secret

3. Stored in a GitHub Actions secret using this code

    new github.ActionsSecret("pulumiAccessToken", {
      repository: repository.name,
      secretName: "PULUMI_ACCESS_TOKEN",
      plaintextValue: config.requireSecret("pulumiTokenForRepository"),
    });
   

The last thing to do is to add this workflow file to the GitHub repository:

import { readFileSync } from "fs";

const pipelineContent = readFileSync("main.yml", "utf-8");
new github.RepositoryFile("pipelineRepositoryFile", {
  repository: repository.name,
  branch: "main",
  file: ".github/workflows/main.yml",
  content: pipelineContent,
  commitMessage: "Add preconfigured pipeline file",
  commitAuthor: "Alexandre Nédélec",
  commitEmail: "15186176+TechWatching@users.noreply.github.com",
  overwriteOnCreate: true,
});

This code:

1. reads the main.yml file that contains the workflow we saw previously

2. creates a file with this content in the repository in the .github/workflows/ folder for the GitHub Actions workflows

3. makes a commit when creating the file (or modifying it)

Test the Azure-Ready GitHub Repository

Now that the infrastructure code to provision the Azure-Ready GitHub repository is written, let's run it with the pulumi up command and see if it works!

All the resources are correctly created and our new GitHub repository is ready to be used.

Let's clone it.

git clone https://github.com/TechWatching/azure-ready-repository; cd azure-ready-repository

We want to verify that the GitHub project is properly configured and can provision Azure resources from its GitHub Actions workflow.

Let's add some infrastructure code that provisions a few Azure resources to check that:

pulumi new azure-typescript -n "AzureReadyGitHuRepository" -y --force

The --force option allows us to create the code within a non-empty directory.

I used the azure-typescript template that creates a storage account and outputs retrieve its primary access key.

Let's run a pnpm install to install the dependencies and generate the pnpm-lock.yaml file. Then, we can push the code to GitHub and run the pipeline to see how it goes.

That's it, we succeeded to provision a storage account from our new GitHub repository whose creation and configuration were entirely automated using Pulumi.

To conclude

Additional information

There are different platforms you can use to host your Git repositories: GitHub, GitLab, and Azure DevOps to name a few. We use GitHub in this article but you can easily apply the same logic with other platforms (Pulumi has providers for GitLab and Azure DevOps as well).

Even though the Azure-Ready GitHub repository is provisioned using Pulumi, there's nothing stopping you from using another Infrastructure as Code solution that supports Azure OIDC (such as Azure CLI, which was mentioned in the article, Azure Bicep, or even Terraform) in the GitHub Actions workflow of the created repository. You don't even have to provision infrastructure; you can use this workflow to simply deploy an application to an existing Azure resource.

Potential Enhancements

There are many aspects that could be improved in the infrastructure code provisioning the Azure-Ready GitHub repository, but I believe the current solution serves as a good starting point. Nevertheless, here are some ideas for potential enhancements:

• make additional items, such as the commit author, configurable

• authorize an environment and not only a branch to retrieve an Azure token

• use environment variables/secrets instead of variable/secrets at the repository scope

I think it would be interesting as well to put that code behind an API or a Web application using Pulumi Automation API to have a self-service solution to create Azure-Ready GitHub repository on the fly.

Related articles

Here are some articles on the same topic I wanted to mention:

• Stop using static cloud credentials in GitHub Actions by Lee Briggs
  ➡️ This post provides examples for configuring OIDC authentication with GitHub Actions for AWS, Azure, and GCP. The code for Azure is quite similar to the code I showed here. Yet, it doesn't go so far as to initialize a pipeline ready to deploy resources with Pulumi. Anyway, it's awesome to have the code for all 3 major providers.

• Configuring GitHub Actions to Azure authentication with OIDC by Xavier Geerinck
  ➡️This post also shows how to configure OIDC authentication with GitHub Actions and Azure but using an Azure CLI script. Although the GitHub repository creation and configuration are done manually, automating the Azure part with a few lines of script is nice.

• Getting Rid of Passwords for Deployment with Pulumi OIDC Support by Sam Cogan
  ➡️ If you don't care about automating everything and simply want to configure OIDC authentication through the Azure portal, that's the post you will want to read. There is also an example of a pipeline to provision Azure infrastructure using a .NET Pulumi program.

Complete code solution

In this article, I aimed to provide a step-by-step explanation of how to automate the creation of a GitHub repository with a properly configured workflow to interact with Azure using OpenID Connect. Consequently, the article turned out to be quite lengthy. I apologize for that, but I didn't want to present the code without adequate explanation.

Anyway, now that we've covered everything, here is the complete code, which is just 75 lines long:

import * as pulumi from "@pulumi/pulumi";
import * as github from "@pulumi/github";
import * as azuread from "@pulumi/azuread";
import * as authorization from "@pulumi/azure-native/authorization";
import { azureBuiltInRoles } from "./builtInRoles";
import { readFileSync } from "fs";

const config = new pulumi.Config();

const repository = new github.Repository("azure-ready-repository", {
  name: "azure-ready-repository",
  visibility: "public",
  autoInit: true
});

export const repositoryCloneUrl = repository.httpCloneUrl;

const aadApplication = new azuread.Application("AzureReadyApp", { displayName: "Azure Ready App" });
const servicePrincipal = new azuread.ServicePrincipal("AzureReadyServicePrincipal", {
  applicationId: aadApplication.applicationId,
});
new azuread.ApplicationFederatedIdentityCredential("AzureReadyAppFederatedIdentityCredential", {
  applicationObjectId: aadApplication.objectId,
  displayName: "AzureReadyDeploys",
  description: "Deployments for azure-ready-repository",
  audiences: ["api://AzureADTokenExchange"],
  issuer: "https://token.actions.githubusercontent.com",
  subject: pulumi.interpolate`repo:${repository.fullName}:ref:refs/heads/main`,
});

const azureConfig = pulumi.output(authorization.getClientConfig());
const subscriptionId = azureConfig.subscriptionId;

new authorization.RoleAssignment("contributor", {
  principalId: servicePrincipal.id,
  principalType: authorization.PrincipalType.ServicePrincipal,
  roleDefinitionId: azureBuiltInRoles.contributor,
  scope: pulumi.interpolate`/subscriptions/${subscriptionId}`,
});

new github.ActionsSecret("tenantId", {
  repository: repository.name,
  secretName: "ARM_TENANT_ID",
  plaintextValue: azureConfig.tenantId,
});

new github.ActionsSecret("subscriptionId", {
  repository: repository.name,
  secretName: "ARM_SUBSCRIPTION_ID",
  plaintextValue: azureConfig.subscriptionId,
});

new github.ActionsSecret("clientId", {
  repository: repository.name,
  secretName: "ARM_CLIENT_ID",
  plaintextValue: aadApplication.applicationId,
});

new github.ActionsSecret("pulumiAccessToken", {
  repository: repository.name,
  secretName: "PULUMI_ACCESS_TOKEN",
  plaintextValue: config.requireSecret("pulumiTokenForRepository"),
});

const pipelineContent = readFileSync("main.yml", "utf-8");
new github.RepositoryFile("pipelineRepositoryFile", {
  repository: repository.name,
  branch: "main",
  file: ".github/workflows/main.yml",
  content: pipelineContent,
  commitMessage: "Add preconfigured pipeline file",
  commitAuthor: "Alexandre Nédélec",
  commitEmail: "15186176+TechWatching@users.noreply.github.com",
  overwriteOnCreate: true,
});

You can find the complete source code used for this article in this GitHub repository.

I hope you enjoyed this article. Please feel free to share your thoughts in the comments, ask questions, or make suggestions. Keep learning.

Checking for vulnerabilities

First, we have to identify if the project has any known vulnerabilities within its dependencies using the `audit` command.

pnpm audit

This command checks every package against the GitHub Advisory Database and indicates through a report which packages are currently carrying security issues and what is their level of threat.

Vulnerabilities resolution

If the audit command identifies some issues, you can try to automatically fix them by running the pnpm update command. This will try to update each vulnerable package to a safe version, without introducing breaking changes.

If there are still some vulnerabilities after running the update, you can try to use the overrides field.

Simply run the audit command with the fix option, and it will add a new section in the package.json file indicating the version of the packages to use whenever those packages and their dependency graph are resolved during the installation.

pnpm audit --fix

You can also specify a threat level while fixing the vulnerabilities, for instance, to only fix the critical ones first :

pnpm audit --audit-level critical

Good to know

If you are running the pnpm audit command in a CI pipeline, you can output the audit report as a JSON file thanks to the -json option. You can then make available this report as an artifact of your pipeline for future reference.

To maintain a secure development environment in the long run, it's crucial to regularly audit your project for vulnerabilities. You should consider running the audit command as part of your continuous integration process or at regular intervals during development.

However, you might wonder: who is actually using pnpm?

A growing popularity

At the time of writing, pnpm has over 24k stars on GitHub, and this number is rapidly increasing. The pnpm Twitter account maintains a thread that tracks the number of stars. Each time the GitHub repository gains 1k stars, a new tweet is posted. For quite some time now, it has been growing by 1K every two months.

Another indicator of its growing popularity is its number of downloads. If you go to npm stats you can see how this number evolved compared to npm and yarn.

I believe this diagram speaks for itself 🚀.

Which companies are using pnpm?

There is a page on pnpm's documentation about well-known companies using pnpm.

You can also see some other companies on the StackShare website (but it seems not many companies took the time to fill in the fact that they were using pnpm in their stack).

Which popular open-source projects are using pnpm?

If you see a pnpm-lock.yaml or a pnpm-workspace.yaml file in a GitHub repository, then that project is definitively using pnpm to manage its dependencies. You can use this technique to find GitHub projects using pnpm by querying them with GitHub code search.

I thought it would be interesting to explore which package managers are utilized in the development of popular JavaScript framework projects. And guess what? Many JavaScript frameworks are developed using pnpm 💖.

Here is a non-exhaustive list of popular JavaScript web frameworks that use pnpm as their package manager:

• Vue

• Nuxt

• Next.js

• SvelteKit

• SolidStart

• Astro

• Qwik

That's quite an impressive list: most modern JavaScript web frameworks seem to have chosen pnpm. That's also the case for popular frontend tooling projects like Vite or Turbo.

Should you use pnpm because others do?

Short answer: no.

Choosing a technology solely based on its popularity is not advisable. While popularity is a factor to consider, it should not be the only determining aspect. Thus, you should not use pnpm because well-known companies or popular open-source projects use it.

However (and here's the long answer 😉), you should consider exploring pnpm, as there must be a reason why all these intelligent individuals have chosen it over npm or yarn. Investigate the issues pnpm resolves for them; perhaps you face similar challenges in your projects. See what problems pnpm solves for them, maybe you have the same problems in your projects. You might not even be aware of certain problems (such as lengthy CI due to time-consuming package installations, excessive space occupied by node modules, or issues with hoisted node modules), but pnpm could potentially make some things easier. Nevertheless, if you are satisfied with your current package manager, there is no need to switch just to imitate the popular frameworks projects.

I believe people are familiar with npm since it is the default package manager for Node.js projects. They might also know about yarn because it was initially developed by Facebook (who created React) and addressed some issues with npm. However, people recognize and utilize pnpm due to its performance and ability to resolve the problems they might encounter with npm package management. That's also why I use pnpm; it does the job, and it does it quickly.

Now you know that you're not alone in using pnpm; from renowned companies to popular open-source projects, many people are utilizing it.

Why is it important to keep your dependencies up to date?

It could be tempting to just keep your whole project with its dependencies just as it is after submitting your pull request or deploying your new feature in production. It's currently compiling, the code has been tested on other environments, and everything's working just fine. So why should you bother spending more time later to check for updates, apply them and adjust your code accordingly? Well, there are a few reasons for that:

1. Security: Regularly updating dependencies ensures that security vulnerabilities are patched, keeping your application safe from potential exploits.

2. Bug Fixes and Stability: Updates to dependencies often include fixes for bugs, but also improve the stability and performance of your code.

3. New Features and Optimization: Updated dependencies may introduce new features and optimizations that can improve your application's functionality and performance.

4. Future Upgrade Simplification: It is much easier to regularly update dependencies and manage small changes than to perform large upgrades with breaking changes.

Exploring the "pnpm outdated" command

The pnpm oudated command simplifies the process of identifying outdated dependencies within your project.

pnpm outdated

By running this command, you'll get a list of dependencies that need to be updated, along with other information, such as the current version, the latest version available, and also any potential compatibility issues, in a friendly format. Here's an example of the output of the command:

Good to know

You can also use the pnpm outdated command for global packages on your machine with the -g option.

Another interesting possibility is to only check a subset of packages you are interested in like this:

pnpm outdated "@vue/*"

Here, we are only checking for outdated packages among those whose names start with @vue/.

Please have a look at the documentation page to see every option available.

When working on a project, you typically focus on a specific feature at a time, making changes on a dedicated branch for that feature. When it's time for you to integrate these modifications into the project's code base, the code base has likely evolved since you began working on your feature, as other team members have also pushed their work. That's why your code changes may introduce errors in the application you are developing.

Regardless of that, while implementing your feature you might have broken some tests, added a security vulnerability, reduced code quality, or simply not adhered to all code conventions used by your team. Even if your colleagues review the code of your Pull Request, they can miss some of these issues. Nonetheless, it would be more efficient for such errors to be detected automatically, enabling people to concentrate their feedback on other aspects.

Continuous Integration enables us to do precisely that: automatically identify potential issues and make the integration of new changes in a project's code base less error-prone.

According to Microsoft:

Continuous integration (CI) is the process of automatically building and testing code every time a team member commits code changes to version control.

What are the steps involved in a CI pipeline?

We often hear discussions about the "Build pipeline" and the "Release pipeline" as if building the application was the only task performed in a continuous integration pipeline. However, this is far from the truth; the "Build" is an important step, but not the only one.

Up until now, we have talked a lot about continuous integration for projects in general but nothing specific for Vue.js. Why is that? Because the steps for continuous integration of a Vue.js project are the same as for any other project:

• Install dependencies

• Build the application

• Perform code quality static analysis

• Perform security analysis

• Run tests

💬 It's good to know that, as part of the build step, an executable artifact is often generated, and then used (in the same pipeline or a CD pipeline) to deploy the application in an environment.

Depending on your project, preferences, and available services, your continuous integration process may vary, but it should include these steps, regardless of the tools you use within them.

There might be additional steps in your Continuous Integration pipeline, but the ones mentioned are the primary ones. Moreover, security is not an optional step; it should be an integral part of your continuous integration.

Leveraging package.json for your CI setup

When you create a Vue.js project using create-vue, the generated package.json file will contain several npm scripts:

You can observe that some of these scripts precisely correspond to the necessary steps for the continuous integration pipeline, such as build and unit tests. We will discuss each of them in future articles but the npm scripts in the default create-vue template are definitively a good starting point to set up your CI.

You can see that packages used in the npm scripts are specified in the devDependencies section of the package.json file. That means these packages will be available to use locally or in a CI server after executing the pnpm install command. As part of the CI, other packages may also be needed, so you should include them in the devDependencies section as well.

In your CI pipeline, I think it's a good idea to directly execute the npm scripts of the package.json file rather than specifying the packages you want to run along with their corresponding flags and parameters. You can accomplish this by using the pnpm run command like so: pnpm run build or pnpm build (all npm scripts are aliased by pnpm by default). Of course, you'll need to add any missing npm scripts required for your CI. There are several benefits to this approach:

• It simplifies the CI pipeline and makes it easier to read

• you won't have to modify your pipeline when you change something in an npm script (whether it's the package you use or just a parameter)

• the steps in your CI pipeline will be more consistent across projects (including both Vue.js and non-Vue.js projects) if you always use the same npm script names

• the same commands will be executed with the same parameters, whether locally or on a CI server

It's important to note that you should not wait for a CI pipeline execution to detect issues in your code. The sooner you identify and resolve problems, the better. Before pushing your changes, you should run the npm scripts that test your code and perform static analysis on it.

Wrapping it up

Setting up a Continuous Integration pipeline for your Vue.js project is essential for preventing issues, maintaining code quality, ensuring security, and streamlining the development process. By leveraging the npm scripts of the package.json file you can simplify your CI pipeline and ensure consistency both locally and on the CI server, as well as across your projects.

Future articles in this series will delve into the details of various stages of a continuous integration pipeline (such as using vue-tsc or eslint for static analysis) and their implementation in GitLab CI or GitHub Actions pipelines.

An example

 pnpm exec eslint . --ext .ts

Given that ESLint is a project dependency, this example shows how to use the pnpm exec command to run the ESLint tool on all TypeScript files within the project.

Some use cases

• You need to do a specific command that is not part of your npm scripts

• You want to execute a tool that is a dependency of your project without having to install it globally

• You need to execute a CLI package command in a CI pipeline, and this package is already included in the devDependencies of your project.

Good to know

If the command you are using does not conflict with a built-in pnpm command, there is no need to specify 'exec'. Referring to the previous example, you can simply run:

 pnpm eslint . --ext .ts

It's one of the small details that make using pnpm so pleasant.

Initializing a new project

pnpm init

This command creates a package.json file where each of the project's dependencies and scripts will be referenced.

Adding a package

pnpm add <package-name>

This command simply adds a new package to your project.

One of the main pnpm's benefits over npm or yarn is its disk space efficiency. While npm installs each package separately for every project, pnpm uses a different approach: packages are stored in a central location on the disk and shared across projects, resulting in significant disk space savings and faster installations.

Installing all dependencies

pnpm install

Run this command to install all dependencies for a project.

Updating packages

pnpm update <package-name>

Just like any package manager, this command allows you to specify a specific package version to update or update all packages in your project. With pnpm's shared store, updating packages becomes faster, as it can reuse packages already present on the disk.

Removing packages

pnpm remove <package-name>

To remove a package from your project, just run this command and specify the name of the package to be removed. Note that if you don't specify the -g option, your package will remain on your disk, ready to be reused within another project.

Running scripts

pnpm run <script-name>
pnpm <script-name>

Defining scripts within the package.json file allows you to have aliases that are easier to manipulate than excessively long CLI commands. You can run them by using the run command and the name of the script. One cool thing is that you can save a few keystrokes by omitting the run keyword, pnpm will automatically look for script aliases.

Why this series?

We delved deeply into CI/CD for Vue.js when preparing a DevOps practices course for students in engineering school. The course wasn't directly related to Vue.js; however, we chose to use a Vue.js application for hands-on exercises focused on implementing CI/CD pipelines. Through this process, we gained valuable insights that we now wish to share.

While there are numerous blog posts on Vue.js, not many articles specifically address setting up CI/CD pipelines for Vue.js projects. Yet, having proper continuous integration and automating deployments are two aspects that should not be neglected in a project. That's the main reason why we decided to write this Vue.js CI/CD series.

What are we going to talk about?

As you can expect, we will cover the usual topics:

• package management

• build & artifacts

• static analysis

• testing

• security

• deployment

Examples will be shown using different CI/CD platforms and cloud services.

CI/CD platforms

We can't cover all the CI/CD platforms so we will focus on GitHub Actions and GitLab CI.

Even though each platform has its unique features, the majority of the concepts we will discuss can be applied to other platforms as well. So, don't stop reading the series just because you are using a different platform 😉.

Cloud services

There are numerous hosting options for a Vue.js application, and we will demonstrate how to deploy an application on at least the following platforms:

• Azure Static Web App

• Vercel

• Netlify

Which sample application will we be using?

This series aims to discuss CI/CD for Vue.js applications so that anyone can learn how to set up a CI/CD pipeline for their Vue.js project. That's why we will use the sample code from the basic application generated when creating a new Vue.js project.

And to be clear, when you start a new Vue.js project you don't want to use the Vue CLI because it is in maintenance mode. Instead, you should use create-vue which is based on Vite and is the recommended way of scaffolding a Vue.js project.

💬 I think it's important to mention it because I still see new blog posts talking about creating new projects using Vue CLI.

So nothing specific in the code of the application we will build and deploy, just the basic things you get when you run the pnpm create vue@latest command with:

• TypeScript enabled ➡️ it's 2023, I don't see any valid reason why to choose Vanilla JS instead of TypeScript so if you are not using TypeScript you probably should

• Vitest enabled ➡️ the vite-native unit test framework you want to use to test your code

• ESLint enabled ➡️ because static analysis should be part of your Continuous Integration pipeline

The last thing to mention: we will use the latest version of pnpm to manage dependencies. Our preferred package manager is pnpm for various reasons, but the primary one is its remarkable speed!

💬 You can check the pnpm website to read more about pnpm or have a look at our pnpm 101 series.

We hope you will have a great time learning about CI/CD for Vue.js application. See you in the next article.

You might not know it, but managing multiple Node.js versions is something you can do with pnpm, using the pnpm env command.

An example

pnpm env use -g lts

This example demonstrates how to install the LTS version of Node.js.

Additionally, you can install specific versions of Node.js, view the versions already present on your computer, or remove one.

Why use pnpm as your Node version manager?

Because managing your Node.js version is built into pnpm: if you already use pnpm as your npm package manager, you don't need to install another tool.

But there is absolutely nothing wrong with using another Node version manager if you prefer. I was using nvm-windows before and I was happy with it. I just don't see the point of installing it anymore as similar functionality is already available in pnpm.

Good to know

To specify a Node.js version to use in a project/folder, you can add an .npmrc file use-node-version​ setting, like that:

use-node-version=16.16.0

That's what you can do with pnpm dlx.

An example

pnpm dlx vercel deploy

This example shows how to use the vercel CLI package without having to install it thanks to pnpm dlx.

In this example, pnpm downloads the vercel package, and executes it with the command deploy (that deploys a project to the Vercel platform).

Some use cases

• You don't want to install globally a package because you only need to execute its binary script once

• You don't want a package to be a dev dependency of your project, or you are not using it in the context of a Node project

• You need to execute a CLI package command from a CI pipeline

• You want to ensure you use the latest version of a package (useful for starter kits like create-vite, or create-vue)

Good to know

For starter kits, you can use pnpm create instead of pnpm dlx. For instance, executing pnpm create vue is equivalent to executing pnpm dlx create-vue.