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.

▲

eterm 10 months ago | parent | next [-]

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 10 months ago \| parent [-]
		It's the JS equivalent of allowing native bindings (like JNI in Java).

▲

graypegg 10 months ago | parent | prev | next [-]

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 10 months ago \| parent \| next [-]
		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 10 months ago \| parent \| prev [-]
		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

▲

trinix912 10 months ago | parent | prev | next [-]

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 10 months ago | parent | prev [-]

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 10 months ago | parent | next [-]

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 10 months ago | parent [-]

if only integrating keycloak was simple eh?

	▲	speedgoose 10 months ago \| parent [-]
		If you are dealing with argon2 and bcrypt, I think you coud manage some JWT hell.

▲

itsjzt 10 months ago | parent | prev [-]

Use bcryptjs https://www.npmjs.com/package/bcryptjs

▲

vivzkestrel 10 months ago | parent [-]

i did mention "and while pure js alternatives are available, they run terribly"

	▲	incrudible 10 months ago \| parent [-]
		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.