3 ms·

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 packag

by jadbox 4y ago

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.

robertlagrant 4y ago
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.
- eropple 4y ago
  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.)
  - robertlagrant 4y ago
    I wonder if npm for Windows just installing a wrapper for GNU Make, made available as npm run make, would solve that.
  - 9dev 4y ago
    Tangent - Why hasn't anyone ported make to windows yet? Isn't it "just" a task runner at the end of the day?
    - eropple 4y ago
      `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.
johannes1234321 4y ago
... 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.

by jadbox 4y ago

robertlagrant 4y ago

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.

eropple 4y ago
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.)
- robertlagrant 4y ago
  I wonder if npm for Windows just installing a wrapper for GNU Make, made available as npm run make, would solve that.
- 9dev 4y ago
  Tangent - Why hasn't anyone ported make to windows yet? Isn't it "just" a task runner at the end of the day?
  - eropple 4y ago
    `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.

johannes1234321 4y ago

... 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.