5 ms·

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

rektide 4y ago
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.
rilut 4y ago
agreed, they got rid of package.json just for them to rediscover its convenience and reinvent it later
robertlagrant 4y ago
It is fairly bad. The scripts section, which can't call other scripts sections neatly, is the worst.
- 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.
- verdverm 4y ago
  You can use a Makefile instead, package.json doesn't really need this section tbh
  - eropple 4y ago
    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]
    - verdverm 4y ago
      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
      - eropple 4y ago
        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.
        verdverm 4y ago
        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
- r3trohack3r 4y ago
  I use scripty for this and it’s been pretty good so far: https://www.npmjs.com/package/scripty https://www.npmjs.com/package/scripty
HeavyFeather 4y ago
> 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.

rektide 4y ago

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.

rilut 4y ago

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

robertlagrant 4y ago

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

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.
verdverm 4y ago
You can use a Makefile instead, package.json doesn't really need this section tbh
- eropple 4y ago
  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]
  - verdverm 4y ago
    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
    - eropple 4y ago
      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.
      - verdverm 4y ago
        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
r3trohack3r 4y ago
I use scripty for this and it’s been pretty good so far: https://www.npmjs.com/package/scripty https://www.npmjs.com/package/scripty

HeavyFeather 4y ago

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