azure – koala-moon

September 13, 2024September 13, 2024

NPM Dependency Notation – idiots guide

Image from ChatGPT

Dependency notation in the package.json file influences how npm handles version installations, and this affects whether npm install may update the package-lock.json file.

Here’s how it works based on different notations:

Version Notations and Their Meanings:

Exact Version (“4.19.2”):

Notation: “4.19.2”
Meaning: Install exactly version 4.19.2 of the package.
Effect on npm install:
When this version is specified, npm will always install version 4.19.2, regardless of whether newer minor or patch versions are available. The package-lock.json will not be updated unless you manually change the version in package.json.
Example: If version 4.19.3 is available, npm will not install it.

2. Caret (^) Notation (“^4.19.2”):

Notation: “^4.19.2”
Meaning: Install any compatible version according to semver rules, meaning any version >=4.19.2 and <5.0.0.
Effect on npm install:
With ^, npm allows updates to the minor and patch versions, but not the major version. This means if a newer patch version (like 4.19.3) or minor version (like 4.20.0) is available, npm will install it. If an update is installed, the package-lock.json will be updated to reflect the new version.
Example: If 4.20.1 is available, npm install will update package-lock.json to install 4.20.1.

3. Tilde (~) Notation (“~4.19.2”):

Notation: “~4.19.2”
Meaning: Install the most recent patch version that matches the specified minor version, meaning any version >=4.19.2 and <4.20.0.
Effect on npm install:
With ~, npm will allow updates to the patch version but not the minor version. If a newer patch version is available (e.g., 4.19.3), npm will install it, and the package-lock.json will be updated.
Example: If version 4.19.5 is available, npm will install that, but it will not install version 4.20.0.

4. Major Version (“4.19”):

Notation: “4.19”
Meaning: This implies “4.19.x”, which means install the latest available patch version within the 4.19.x range.
Effect on npm install:
This is similar to using ~4.19.0 but more permissive. It allows updates within the minor version and to any patch version (e.g., 4.19.2 → 4.19.5).
Example: If version 4.19.3 or 4.19.5 is available, npm will install it and update package-lock.json.

Impact on npm install and package-lock.json:

Exact version (“4.19.2”): No updates will occur unless you change the version manually in package.json.
Caret (^4.19.2) or Major version (“4.19”): Newer patch or minor versions will be installed automatically, and this will update package-lock.json with the exact version.
Tilde (~4.19.2): Only patch updates are allowed, and package-lock.json will reflect those updates when they occur.

How This Affects npm install:

If you use npm install (as opposed to npm ci), and the notation in your package.json allows for updates (like ^4.19.2), npm may install a newer version within the range, and as a result, the package-lock.json file will be updated with this new version.

On the other hand, if the package-lock.json specifies a version (say 4.19.2), and your package.json allows updates (^4.19.2), running npm install could still install a newer version (like 4.19.3), which would then update the lock file.

This flexibility is a double-edged sword: it allows for automatic updates of patches and minor versions, but if not managed well, it can lead to differences in installed versions across environments, which is why many teams prefer using npm ci in CI/CD pipelines for consistency.

September 13, 2024September 13, 2024

NPM install, ci and audit

Image created by ChatGPT

I needed to take a step back and fully understand this issue so I could explain it clearly to both new and experienced developers. The problem surfaced because our deployment pipelines run npm audit, which became a bottleneck in our process. We kept seeing the same vulnerabilities flagged repeatedly, even though they had been fixed multiple times.

Here we go, npm instal, ci and audit

Here’s an overview of the flow from installing a new package with npm to running npm install or npm ci in a pipeline, along with details on how vulnerabilities may resurface through npm audit.

Flow from Installing a Package to CI/CD

Installing a Package:

When you install a new package locally (e.g., npm install package-name), npm adds the package to the node_modules directory and updates your package.json and package-lock.json files (or yarn.lock if you use Yarn).
package.json specifies the declared dependencies and their versions.
package-lock.json contains the exact versions of the installed packages and their entire dependency tree (including transitive dependencies). This ensures that everyone who installs your project gets the same versions of dependencies.

2. Pushing to Version Control:

Once you are satisfied with your code, including the new dependency, you push the changes to version control (e.g., Git). It’s important that both the package.json and package-lock.json files are committed to ensure consistency across environments.

3. Pipeline – npm install vs npm ci:

npm install:
- During a build or deployment pipeline, running npm install will install dependencies based on the package.json and update the node_modules directory.
- If a package-lock.json file exists, npm tries to install exact versions from the lock file, but if it detects any changes (e.g., new versions of dependencies or conflicts), it may update the lock file. (See dependency notation)
npm ci:
- In a CI/CD pipeline, npm ci is preferred as it is faster and more deterministic.
- It strictly adheres to the versions specified in package-lock.json. If any discrepancies (such as missing or extra dependencies) are found, the entire node_modules directory is deleted, and the exact dependencies from the package-lock.json are installed.
- npm ci does not update package-lock.json, making it ideal for CI environments where reproducibility is critical.

4. npm audit:

During or after the install process, npm may run npm audit to check for security vulnerabilities in your dependencies. It compares the installed packages against a database of known vulnerabilities and flags any risks.
npm audit fix can automatically update vulnerable dependencies to the latest non-breaking versions (as defined by semver).

How Do npm audit Problems Reappear?

Indirect Dependencies (Transitive Dependencies):

Most npm packages rely on other packages (dependencies of dependencies), and vulnerabilities often arise in these indirect dependencies.
Even if you’ve addressed an issue by updating your direct dependencies, some transitive dependencies may still have unresolved issues. This happens because they may not have yet released a fixed version.

2. New Vulnerabilities Discovered:

Sometimes, new vulnerabilities are discovered in packages that were previously considered safe. When npm’s vulnerability database is updated, a previously resolved issue may reappear if it’s related to a newly discovered flaw.

3. Out-of-Date Dependencies:

When the package-lock.json or a specific package hasn’t been updated for a while, and a vulnerability was later fixed in a newer version, your audit might flag the outdated dependency.
Running npm audit regularly (especially on pipelines) will catch such vulnerabilities, but sometimes an older transitive dependency may bring back the issue.

4. Partial Fixes:

Sometimes, packages release partial fixes, where only certain issues are resolved. If the fix doesn’t cover all security concerns, npm audit may still flag the package.

5. Conflicts Between Versions:

Certain updates may not be backward compatible with your project’s current environment or with other dependencies. This can lead to situations where you are unable to fully update vulnerable dependencies without breaking something else in your codebase.

Dealing with Persistent npm audit Problems:

Explicit Version Control: Sometimes you may have to manually control the versions in package-lock.json by using specific version ranges or resolutions (in tools like Yarn) to enforce the use of patched versions.
Selective Fixing: If you know a particular vulnerability doesn’t affect your project (e.g., it only impacts a feature you don’t use), you can audit it with exceptions.
Monitor Transitive Dependencies: Regularly check your dependency tree to monitor transitive dependencies and see if any have lagging versions. This can be done using tools like npm ls or through dependency-checking platforms.

March 26, 2024March 26, 2024

Azure AppInsights with Nodejs adding operation id to response

I needed to add an additional response header to my requests to aid in tracking errors.

Here is my solution. A middleware that will add the AppInsights Operation ID to the response. The Operation ID is unique to each request so searching for it is simple.

import { Request, Response, NextFunction } from 'express';
import appInsights from '../../lib/appInsights';

export default (req: Request, res: Response, next: NextFunction) => {          
    const { operation } = appInsights.getCorrelationContext();    
    
    res.setHeader('X-Operation-ID', operation.id);
    
    next();
};

June 18, 2020

Vue.js – Azure Pipelines

I had a requirement to automate the CI/CD pipeline of an existing Vue.js project.

What was asked…

On any merge into the branch “releases/dev
Run all unit tests
Build for the development/staging environment
Copy the files to Azure Blob storage so they can be used as a SPA

The project repo was already in Azure Dev Ops

trigger:
  - releases/dev

pool:
  vmImage: "ubuntu-latest"

steps:
  - task: NodeTool@0
    inputs:
      versionSpec: "12.x"
    displayName: "Install Node.js"

- script: |
    npm install
    npm run test:unit
  displayName: "npm install"

- script: |
    npm run test:unit
  displayName: "npm run test:unit"

- script: |
    npm run build:dev
  displayName: "npm run build:dev"

- task: AzureCLI@2
  displayName: "Copy files to blob storage"
  inputs:
    azureSubscription: 'Faux-Development-ltd'
    scriptType: 'bash'
    scriptLocation: 'inlineScript'
    inlineScript: 'az storage blob upload-batch -d \$web --account-   name "blobStoreName" -s "dist" --connection-string "DefaultEndpointsProtocol=https;AccountName=xxxxxx;AccountKey=123456789123456789/qwerty/qwertybangbang==;EndpointSuffix=core.windows.net"'

The only sticking points where.

The blob store container is called $web which look like a variable in the shell script so I had to use \$web