4 ms·

I would heavily recommend to avoid NodeJS packages that depend on node-gyp. Node-gyp powered dependencies are very seldomly worth the hassle. If you must depen

I would heavily recommend to avoid NodeJS packages that depend on node-gyp. Node-gyp powered dependencies are very seldomly worth the hassle. If you must depend on node-gyp, perhaps use dev containers so at least every developer in your team can work most of the time.

graypegg 2y ago
So I'm pretty uninformed about the guts of node-gyp, and why it's used, but if people need to bring in dependancies from outside javascript... could WASM be a good fit there? Could store the binaries instead, and ship those... and in theory (correct me if I'm wrong) that shouldn't be much of a security issue due to the security model of WASM modules... or at least equal to the risk of running arbitrary build commands on your machine from a random node package.
- int_19h 2y ago
  In principle, yes. In practice, the problem is that getting some random native library or tool compile with wasm as a target is not always easy. E.g. anything that relied on pthreads was out until fairly recently.
- _fat_santa 2y ago
  In practice you're just kinda stuck with it because whatever NPM package you're using is using that under the hood. One of my project depends on it because of postgres DB bindings, there would be no easy way for me to get rid of it without either finding another binding (which that is the official one) or rebuilding it myself which will just take too much time and effort for what it's worth
eterm 2y ago
I don't even know what node-gyp is, but I know it appears regularly in error messages to know it causes problems. I don't even develop against Node, it has just crept into our front-end build toolchain.
- philipwhiuk 2y ago
  It's the JS equivalent of allowing native bindings (like JNI in Java).
trinix912 2y ago
Pardon my ignorance, but wouldn’t that rule out most image processing packages that depend on (and often build during install) imagemagick as the backend? A long time ago I tried to avoid it in a project but really couldn’t find any decent node image processing package that wouldn’t at some point depend on it. Maybe I just didn’t look far enough?
vivzkestrel 2y ago
one of the most crucial packages that use node-gyp are bcrypt and argon2. Both are needed heavily for password hashing while implementing authentication and while pure js alternatives are available, they run terribly
- speedgoose 2y ago
  That would be a good argument to not implement authentication again and go with a solid authentication and authorisation software like Keycloak, Zitadel, or Ory Kratos.
  - vivzkestrel 2y ago
    if only integrating keycloak was simple eh?
    - speedgoose 2y ago
      If you are dealing with argon2 and bcrypt, I think you coud manage some JWT hell.
- itsjzt 2y ago
  Use bcryptjs https://www.npmjs.com/package/bcryptjs https://www.npmjs.com/package/bcryptjs
  - vivzkestrel 2y ago
    i did mention "and while pure js alternatives are available, they run terribly"
    - incrudible 2y ago
      Slow is much faster than it not working at all. If this is a project that you might not touch for months or years, perhaps having fast bcrypt is not that important.

graypegg 2y ago

So I'm pretty uninformed about the guts of node-gyp, and why it's used, but if people need to bring in dependancies from outside javascript... could WASM be a good fit there? Could store the binaries instead, and ship those... and in theory (correct me if I'm wrong) that shouldn't be much of a security issue due to the security model of WASM modules... or at least equal to the risk of running arbitrary build commands on your machine from a random node package.

int_19h 2y ago
In principle, yes. In practice, the problem is that getting some random native library or tool compile with wasm as a target is not always easy. E.g. anything that relied on pthreads was out until fairly recently.
_fat_santa 2y ago
In practice you're just kinda stuck with it because whatever NPM package you're using is using that under the hood. One of my project depends on it because of postgres DB bindings, there would be no easy way for me to get rid of it without either finding another binding (which that is the official one) or rebuilding it myself which will just take too much time and effort for what it's worth

eterm 2y ago

I don't even know what node-gyp is, but I know it appears regularly in error messages to know it causes problems. I don't even develop against Node, it has just crept into our front-end build toolchain.

philipwhiuk 2y ago
It's the JS equivalent of allowing native bindings (like JNI in Java).

trinix912 2y ago

Pardon my ignorance, but wouldn’t that rule out most image processing packages that depend on (and often build during install) imagemagick as the backend? A long time ago I tried to avoid it in a project but really couldn’t find any decent node image processing package that wouldn’t at some point depend on it. Maybe I just didn’t look far enough?

vivzkestrel 2y ago

one of the most crucial packages that use node-gyp are bcrypt and argon2. Both are needed heavily for password hashing while implementing authentication and while pure js alternatives are available, they run terribly

speedgoose 2y ago
That would be a good argument to not implement authentication again and go with a solid authentication and authorisation software like Keycloak, Zitadel, or Ory Kratos.
- vivzkestrel 2y ago
  if only integrating keycloak was simple eh?
  - speedgoose 2y ago
    If you are dealing with argon2 and bcrypt, I think you coud manage some JWT hell.
itsjzt 2y ago
Use bcryptjs https://www.npmjs.com/package/bcryptjs https://www.npmjs.com/package/bcryptjs
- vivzkestrel 2y ago
  i did mention "and while pure js alternatives are available, they run terribly"
  - incrudible 2y ago
    Slow is much faster than it not working at all. If this is a project that you might not touch for months or years, perhaps having fast bcrypt is not that important.