Can't install module with Yarn 3.x (berry) about node-bin-gen HOT 8 OPEN

Probably it would help to switch to the approach which esbuild uses and instead of using a post-install script, using the optionalDependencies: evanw/esbuild#1621

Maybe this could prevent a lot of edge cases?

But then the different node packages (operating-systems, CPU combinations) must be available on npm as seperate packages...

from node-bin-gen.

Yeah, this sounds like a bug in yarn. They've changed the order of scripts to not be compatible with existing packages.

I urge you to open a bug report there.

from node-bin-gen.

I think they are pushing toward more deterministic packages that don't rely on so many scripts during installation.

Do you think the node npm package could come with everything pre-built to simplify the process?

from node-bin-gen.

Not likely. Not unless all architectures (and OSes supported) of node packages were known at the build time of that node release and were included. that'd be > 1GB installed for a node version.

If someone thinks of a clever way to do it I'm all ears.

from node-bin-gen.

Could the package depend on an optionalDependency that would be compatible only for the specific architecture? So the node package would list several optional deps, one for each architecture, and npm/yarn would only download the compatible one.

from node-bin-gen.

That doesn't work very well with package-lock.json, because then you end up with the specific architecture locked.

from node-bin-gen.

That doesn't work very well with package-lock.json, because then you end up with the specific architecture locked.

Would this recent addition help?

https://dev.to/arcanis/yarn-31-corepack-esm-pnpm-optional-packages--3hak (conditional packages)

Of course it would mean a Yarn-specific version would be needed. But TBH the Yarn approach seems more reliable

from node-bin-gen.

@FezVrasta It might! How does one use such a thing? What file does that stuff that they're describing go into?

from node-bin-gen.