Remix clone Hacker News

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

▲

graypegg 7 days 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 7 days 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 6 days 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 6 days 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 6 days 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

▲

itsjzt 5 days ago | parent | next [-]

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

▲

vivzkestrel 5 days ago | parent [-]

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

	▲	incrudible 4 days 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.

▲

speedgoose 6 days ago | parent | prev [-]

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 6 days ago | parent [-]

if only integrating keycloak was simple eh?

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