Zac Anger's Blog

package.json is just fine


Tags: javascript, npm

Quick response to this nonsense, section by section, because it's highly upvoted on Hacker News and is a load of bullshit.

Semver is good, actually, and if you never hit v1, that's a you problem. Not even really a problem, just a thing that is.

The browser field in package.json was never really heavily used. I've never in 8 years of working in the Node ecosystem actually seen it in the wild. And if you did try to require a Node builtin in your browser bundle, chances are your bundler fixed that for you.

Sure you've got type: module. This is because the language spec didn't have modules originally. No we all just use type: module, mostly, unless you have old packages you haven't bothered to update (like me). You don't have to care about it. Set it in your init options and don't worry about it. And it's not a big deal to use ESM in CJS (require('foo').default) or vice versa (it literally just works).

Your npm scripts are a mess? Again, that's a you problem. Stop jumping between package managers and just use npm. If you have more than, maybe, 10 scripts, you probably need to rethink how you're testing and building.

You're still using watchman. Again, guess what, that's a you problem. If you don't ever bother dealing with tech debt, you don't deserve to whine about you have tech debt. Gulp is actually still around, but I haven't seen anyone using it in a few years.

You're using a bunch of deps, some of which are obsolete (str.padStart exists). Guess what? That's a you problem. Who's the person who ran npm i every damn package they saw in a tutorial and never bothered to clean things up later on? Use npm-check-updates to keep your deps current, use grep -r package-name . to see if you're actually using a module, and once in a while actually deal with your tech debt.

If you don't want to see donation messages, change your log level. If you don't want to see deprecation notices, update your packages and deal with your tech debt. Simple as.

If you choose libraries based on opinions you saw on Twitter, you're in for a bad time. Moment is fine, though not really actively maintained. There are others that are also fine. Lots of libs are bloated and full of bad code. Just pick something that works, is popular, and is active.

Again, use ncu. Update to the top of the current semver major range, then walk through updating each one until you're current. It might take a couple of hours, but after that you can just do it routinely, once every sprint or whatever. It's really not that big of a deal. Call me when you have to deal with an emergency kernel update across hundreds of servers that potentially degrades IO perf. Wimp.

What the hell is resolutions? That's not a thing. You're making that up. (Oh, I see it's a yarn thing. Don't use yarn, just use the standard, that's your problem.)

devDependencies are so you don't have to ship shit to your package's users. Do you need Webpack or Babel or your personal crappy ESLint config to head over to someone installing your package? You do not. If you don't know what devDeps are for, go read the docs.

If your lint config is so strict that you can't work effectively, change it. If you have so many errors that it's a distraction, maybe try fixing some of them? Invest time in taking care of this shit so you have a nice codebase. Why are you whining about it when they're your rules to begin with?

If you have PostCSS explicitly installed but it's a peerDep, let it be a peerDep, that's how it works these days. Also there's no native extension in PostCSS or its deps. You might be thinking of an old SASS package from years ago.

It takes about 4 lines of config and one extra package to get Jest working with TS. Easy stuff. But if you don't like that, good news, you can pick from one of hundreds of other test runners. Personally I'm a big fan of node-tap.

If you have multiple tools that serve the same purpose, again, that's your problem. Delete them. You don't need esbuild and swc and TypeScript and Babel. If you're writing TS, just use TS. Don't use Rollup and Webpack on the same codebase, just pick one. Terser is a minifier, usually a plugin for an actual build tool, so now you're just being silly.

Of course engines lists Node. The purpose of engines is really to tell consumers of your package their requirements. Node 10? Node 16? That actually does matter, and it's a programmatic way of explaining requirements.

Final note: your package.json is in a weird order. npx sortpack to fix that.