Can't install module with Yarn 3.x (berry)

[FezVrasta]

We have #44 but it's about Yarn 1 I think.

yarn add node results in an error with the following logs:

# This file contains the result of Yarn building a package (node@npm:14.18.1)
# Script name: preinstall

internal/modules/cjs/loader.js:818
  throw err;
  ^

Error: Cannot find module '/Users/federicozivolo/Projects/app/node_modules/node/bin/node'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:815:15)
    at Function.Module._load (internal/modules/cjs/loader.js:667:27)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:60:12)
    at internal/main/run_main_module.js:17:47 {
  code: 'MODULE_NOT_FOUND',
  requireStack: []
}

I think the problem is that Yarn 3.x runs preinstall hooks as part of the postinstall cycle.

https://yarnpkg.com/advanced/lifecycle-scripts#:~:text=For%20backwards%20compatibility%2C-,preinstall,-and%20install%20are

I'm on macOS 11.6 running Node.js 14.18.1

[aredridel]

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.

[FezVrasta]

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?

[aredridel]

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.

[FezVrasta]

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.

[aredridel]

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

[FezVrasta]

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

[aredridel]

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

[zauni]

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

[manoraj]

I also have this issue in the yarn repository I am working on. For my use case, I had to use https://dotslash-cli.com/ instead of this package.

Considering yarn is the popular package manager, not a bad idea to support this to increase adoption.

[aredridel]

Yeah, the reason I haven't done what esbuild does is that adding more architectures or OSes later is impossible, since they have to be listed.

[aredridel]

Considering yarn is the popular package manager, not a bad idea to support this to increase adoption.

Increasing adoption for increasing adoption's sake is a non-goal.