Phillip Luther’s Frontend Developer Experience Blog

That Moment When You Finally Set npm Init's Default Values

Published on

Tired of updating the author, version, and license fields in every new project's package.json file? Me too; here's how to set npm init's default values.

tl;dr

npm init’s defaults are npm config settings. Update them with npm config set <key> <val>.

$ npm config set init-author-name "Phillip Luther" -g
$ npm config set init-author-email dev@phillipluther.com -g
$ npm config set init-author-url https://phillipluther.dev -g
$ npm config set init-version 0.0.0 -g
$ npm config set init-license MIT -g

I find it easier to set my defaults globally, hence the -g flag flying. Not an npm user? Check out the mightily similar process for pnpm and Yarn.

Now that that’s out of the way, lemme say …

npm’s Default Defaults Are Just Plain Bad

When an idea for a new JavaScript project pops into my head and I npm init the thing, because I npm init all the things, I get some real head-scratchers in the resulting package.json file.

Here are npm’s default defaults for init-related values:

KeyDefault Value
init-author-name""
init-author-email""
init-author-url""
init-version1.0.0
init-licenseISC

Those Init Author Values

I won’t fault npm for not knowing who I am. Nobody knows who I am.

Blank values for the init-author* keys make sense, but I’ll update those defaults so I don’t need to manually tweak every new package.json between now and time’s end.

$ npm config set init-author-name "Phillip Luther" -g
$ npm config set init-author-email dev@phillipluther.com -g
$ npm config set init-author-url https://phillipluther.dev -g

Setting the three together results in a handy little author entry in your package.json akin to:

{
  "author": "Phillip Luther <dev@phillipluther.com> (https://phillipluther.dev/)"
}

And npm’s Baffling Default Version?

I’m a massive fan of sensible defaults. I’m a huge fan of semantic versioning. Ergo, I am not a fan of 1.0.0 as init’s default version.

Following SemVer, a 1.0.0 application is stable. Following npm init, my freshly minted little stub of what might someday be a Node.js app is not stable. Ergo, it is not at version 1.0.0.

All due love and respect to the Node/npm crew, but 1.0.0 as the default version is straight-up madness. It bothers me more than it should. It bothers me enough to often wonder what I’m missing, thinking there must be some reason why it makes sense to call an application “stable” when you haven’t written a single line of code for it yet. It bothers me enough to invoke double ergos!

It also bothers me enough to change its value.

A Less Baffling Default Version for npm Init

I think of versioning in terms of releases. That’s not just me; that’s part of semantic versioning (tenet 3). With a newborn Node.js app, I haven’t published/released anything. The app doesn’t exist. That’s why I default my init version to 0.0.0.

On the application’s first release, I’ll bump the version to 0.1.0 or 1.0.0 or whatever’s appropriate.

Hence:

$ npm config set init-version 0.0.0 -g

npm’s Default License: Maybe Not Baffling, but Eyebrow-Raising

All new Node.js applications bootstrapped by npm come equipped with the ISC license.

Pausing for a beat.

”What the bleep is the ISC license?” you might ask. That’s a tremendous question you’d be right in asking.

I’ve never shipped anything using the ISC license; no npm modules I use regularly ship with the ISC license. In fact, the company behind the ISC license doesn’t use it and doesn’t recommend using it anymore. I’ll heed that recommendation and not use it.

I ship most of my Node.js packages with the MIT license, so I default to that:

$ npm config set init-license MIT -g

Set Your Own Defaults

I’m not trying to convince you to use the MIT license. I’m not trying to convince you to adopt 0.0.0 as the initial version for all your new Node.js projects. I’m not trying to convince you to use my name, email addy, and blog URL as default author info.

However, I am trying to convince you to give it some thought and set npm’s init values to whatever makes sense for you. Summing up, you can do that via:

$ npm config set <Key> <Value>

The sky’s not gonna fall if you don’t, but you might find yourself less bothered and less hassled and editing a tiny bit less JSON.

Setting pnpm Default Values

I use pnpm, too. It’ll pick up your values from npm, so if you’ve already got things configured how you like for npm, you’re good with pnpm.

Or, set them exactly the same way described above, swapping npm for pnpm. pnpm uses npm config formats.

$ npm config set init-author-name "Phillip Luther" -g

Setting Yarn Default Values

Yarn picks up your config values from npm, but (I think) overrides them with its own defaults. Your author values will be fine because Yarn doesn’t know who you are, but it’ll clobber npm’s version and license values, for example.

Beyond that, everything above using yarn instead of npm or pnpm.

$ yarn config set init-author-name "Phillip Luther" -g

Here’s all the yarn configuration you could ever dream of.