Node on Brandon Pugh's Blog

NPM 11.10.0 adds `min-release-age`

Thu, 21 May 2026 00:00:00 +0000

You can now specify a minimum age for installing package versions in NPM.

This is a concept known as dependency cooldowns that has gained popularity with the rise in supply chain attacks.

You need to be running at least v11.10.0 of npm but then you can add the following to your .npmrc file:

min-release-age=7

or set it globally with:

npm config set min-release-age=7

Now NPM won’t install any package version that was released less than 7 days ago.

If you don’t specify a version, i.e. npm install vite, then it will install the most recent version that satisfies the age requirement.

If you specify a version that doesn’t meet the age requirement then it will error out.

Note: if you’re running a version of NPM older than 11.10 then it will silently ignore the new config value.

Thank you for keeping RSS alive. You're awesome.

Reply by email

List installed node versions with Volta

Tue, 12 May 2026 00:00:00 +0000

Volta is my preferred node version manager these days but the commands are a bit different to what I’m used to.

volta list - show the current tool versions in use
volta list node - show all the versions of node downloaded to the machine
volta install node@version - use the specified version of node. It will download and install it if hasn’t before otherwise it will just select it (there is no separate use command).

Thank you for keeping RSS alive. You're awesome.

Reply by email

Run old versions of Angular

Thu, 20 Mar 2025 00:00:00 +0000

Today I learned how to get a very old Angular project running locally. Even though it was Angular in this case, the steps are likely to be similar for most aging node based projects.

First I had to go to the Version compatibility page for Angular and find the required version of node. In my case it was Angular v7 so I needed Node v10.

Next, you’ll want to use a version manager for node.
nvm is the most well known but you have to run it in bash on Windows and I find Volta much nicer to use.

I ran volta pin node@10 in the project directory. This will add a volta config section to the package.json so that whenever you’re in that directory, you’ll automatically use the correct version of node and npm.

Best of all though, it won’t affect the default version of node that get’s run everywhere else.

Also make sure you run npm install after the above command so that it’s the correct version of npm.

If you already tried to run npm i with a different version of node then you’ll probably need to blow away your node_modules folder and try again (ask me how I know).

Thank you for keeping RSS alive. You're awesome.

Reply by email

npmpackage.info

Thu, 30 Jan 2025 00:00:00 +0000

I recently discovered this handy site that aggregates all usual info I tend to look at when deciding whether or not I want to pull in an NPM package as a dependency.

npmpackage.info

Some things I tend to look at:

When was the last version published?
How many sub-dependencies does it have?
- With the rise in supply chain attacks, newer packages try to minimize these with some advertising zero dependencies
How much will it add to bundle size?
- I usually check Bundlephobia and this displays the stats from there along with everything else
How widely used is it?

Thank you for keeping RSS alive. You're awesome.

Reply by email

Fix package-lock.json merge conflicts

Tue, 16 Jan 2024 00:00:00 +0000

Today I learned that npm can handle merge conflicts in your package-lock.json file for you.

After you resolve any merge conflicts in your package.json, you can just run npm install [--package-lock-only] and npm will resolve the conflicts in the lock file. If --package-lock-only is provided, it will do this without also modifying your local node_modules/.

Solving conflicts in package-lock.json

Thank you for keeping RSS alive. You're awesome.

Reply by email

Native node import path aliases

Wed, 08 Nov 2023 00:00:00 +0000

Today I learned that node natively supports import path aliases with the imports field in package.json.

The nice thing about this is that they’re supported by most node tools now so you don’t need to configure your aliases separately in different tools like eslint, webpack, vite, etc…

If you’re not familiar with import aliases, they’re a handy way to avoid unwieldy relative import paths.

instead of:

import utils from '../../../../shared/utils';

you can have:

import utils from '#shared/utils';

A nice config to start with is something similar to:

"imports": {
    "#*": "./*"
  },

which lets you import anything from the root of your project.

I actually discovered this from looking through the decision log of the epic-stack react project.

Unfortunately typescript doesn’t support it yet (though it’s planned), so you’d still need to update tsconfig.json with:

"paths": {
      "#*": ["./*"],
},

Thank you for keeping RSS alive. You're awesome.

Reply by email

Override nested dependencies with npm

Mon, 06 Nov 2023 00:00:00 +0000

Today I learned that as of npm cli v8.3.0 (2021-12-09), you can use the overrides field in package.json to “override” nested dependency versions.

This is handy for several scenarios, but for me I used for a third-party react component that has a peerDependency on v16 of react even though it works just fine with v18 but it isn’t under active development at the moment so I had to override the version it accepts:

  "overrides": {
    "react-input-range": {
      "react-dom": "^18.2.0",
      "react": "^18.2.0"
    }
  },

Yarn has similar functionality that it calls resolutions.

Thank you for keeping RSS alive. You're awesome.

Reply by email