Hacker News Reader

Comment by goodoldneon | Hacker News Reader

The anti package.json sentiment seems too puritanical. Sure there are downsides to it but I've rarely had a negative experience with it

View on HN

Npm has had such a rocky marginal existence for so many years, getting bought out & passed around, getting random-ish backing & support to stay afloat. Now Microsoft owns Npm package repo & seems like a trustworthy-ish benevolent dictator & stable, but it's more than just ideologically gross to have all the tens of millions of eggs in one basket, it's a constraint on exploration & growth & trying other paths.

I think simply being free to try for better is a necessary & obvious step for js. It's not puritanical at all, it's embracing a lost freedom, to improve & figure stuff out.

It is fairly bad. The scripts section, which can't call other scripts sections neatly, is the worst.

Tbh, i think the scripts section is what makes package.json become a mess. It's the #1 reason why packages break and why it takes forever to install some packages. If your package requires building, it's better to just create NPM/package build artifacts ahead of time.

Agree. Other than that it's decent. I say package.json with a minimal scripts section (so you can run dependency commands) and pop the composition of those commands in a Makefile.

One of the tricky things, and one of the reasons everybody reinvents the wheel, is that Makefiles aren't portable to Windows, which is a first-class platform for these runtimes. So you get a lot of second-system effect as a sidecar to "runs on Windows".

(I don't think you as an individual should worry about Windows if that isn't a platform you care about, of course. But they have to.)

Tangent - Why hasn't anyone ported make to windows yet? Isn't it "just" a task runner at the end of the day?

`make` has been ported long ago! The problem is that almost every Makefile wants a reasonably large subset of POSIX stuff, when it doesn't want specifically GNU stuff. (And like, I write specifically GNUmakefiles because I don't care about those platforms.)

`make` being portable doesn't help that `mv` and `cp` and all that don't port amazingly well. You can write binaries for them that take POSIX flags, of course, and people have, but now, to replace package.scripts with a Makefile, you have to pack a whole bootleg quasi-POSIX environment alongside your JS interpreter? That's not really going to fly with most people. But assuming you do that--how do you write a loop that works in sh, cmd.exe, and PowerShell?

You get the idea. The only way to make a Makefile a real, cross-platform tool is to bring a Unix with it. And that's not super practical in a lot of places! So instead Node (or Ruby/Rake, etc.) converge to a point where libraries like `rimraf` are both really annoying and kind of essential for building an adequate cross-platform dev experience.

Again: not endorsing. But it is why it's the way it is.

I wonder if npm for Windows just installing a wrapper for GNU Make, made available as npm run make, would solve that.

... and where you can't provide ready packages (native (C++ etc.) modules) easily it is still a bad idea to have scripts run automatically by default. Foreign code should only be run after (a chance for) review on request.

You can use a Makefile instead, package.json doesn't really need this section tbh

As mentioned elsewhere, you cannot reliably use a Makefile on Windows. A Makefile also is not aware of things like Node execution paths, the way `yarn exec` is. You're then pushing more stuff down to the writer of the package.json file, who is more likely to make mistakes in retail then you as a platform designer are likely to make in wholesale.

There are good reasons for things to converge the way they have. [EDIT: removed uncharitable reading]

I offered an alternative for the frustrated and did not make any such "just use X" claim

Converge is a weird word to use, given the OP is about a project that creates divergence, now having to add support for other parts of the ecosystem

Sorry. That was uncharitable of me. You did not make a "just use X" claim. But your suggestion does elide the significant difficulties in doing as you suggest. It's an alternative that will lead to more frustration due to the tons of design decisions wrapped up in package.scripts. And asserting that because you can do this, package.json "doesn't need this section tbh" is misleading and a recipe for further frustration for people who listen to your advice.

And yes, Deno not literally being Node is in fact its problem. I've shipped stuff using Deno--and I don't hate it, and I did use Makefiles--but yeah, that's the actual problem here. Node conventions are the ones everyone expects and every tool expects, and Deno does not have a unique selling point to it that makes using it more reasonable than just using Node.

yup, I've personally stopped worrying about Windows support since WSL-2. It makes things much simpler for most people / projects.

The idea that dependencies can run any script at install time has always seemed problematic to me. Node seems to have many less than ideal design decisions that we are now stuck with

I use scripty for this and it’s been pretty good so far:

https://www.npmjs.com/package/scripty

agreed, they got rid of package.json just for them to rediscover its convenience and reinvent it later

> I've rarely had a negative experience with it

We all bury bad memories. Feels like yesterday TypeScript couldn’t resolve a package because I set “moduleResolution: node16”

Oh wait, that’s still happening, because a dependency does not use the correct package.json exports setup.

Reply on news.ycombinator.com