Package variants

[arcanis]

Hi 👋

I've opened an RFC on Yarn to discuss a potential builtin (hopefully cross-package-manager) way to manage prebuilt packages. If you're interested to take a look (and check if it would be compatible with ESBuild) it would be much appreciated 😃

Relevant issue: yarnpkg/berry#2751

[evanw]

Thanks for trying to solve this. I looked at that issue and it seems like this could be made to work with esbuild.

However, I'd prefer to avoid esbuild having an entirely separate package installation strategy just for Yarn. My preference would be to move forward with optionalDependencies instead which is something that npm supports. There is a discussion about changing esbuild to use optionalDependencies here in case you find it interesting: #789.

How is your solution different than optionalDependencies and why not just use optionalDependencies instead? Also, is there interest from other bundlers about a variants feature too?

[arcanis]

How is your solution different than optionalDependencies and why not just use optionalDependencies instead?

Optional dependencies can meet some of the same needs, but have their limits:

• They don't supported anything else than platform / cpu. The proposal lists NAPI as a useful parameter for native packages. The maintainer from sharp also makes a good point about the machine libc.
• It also requires to know the packages beforehand. Should you want to provide a prebuilt version for a new supported architecture, you'll have to add it as an optional dependencies. With variants, syntax could exist to defer this check to the resolution (if the pattern variant is a 404, then use the fallback).
• Parameters outside of the native world don't make a good fit for the engines field, or optionalDependencies. For instance, the RFC mentions the case where you want to differentiate between esm and cjs packages. There would be no way to represent that. In a similar way, it could be interesting to experiment with packages pre-transpiled for sets of browsers.
• The concept of inheritance is important for the esm / cjs use case. If you define that you want the ESM version for package X, then you'll also want the ESM version of its dependencies.

That said it's worth mentioning them as an alternative. Will add a section accordingly. And of course there's nothing that would prevent the two from working together.

Also, is there interest from other bundlers about a variants feature too?

I pinged you not because you're a bundler but because esbuild is now a recognized native but cross-platform package in the ecosystem (so you might be interested in a similar feature to distribute your own work). The feature itself would be mostly transparent to bundlers, just like the resolutions field or the link: / patch: protocols.

[evanw]

I'm going to close this since this isn't an issue with esbuild. Thanks for the heads-up though. I'll be following along on yarnpkg/berry#2751.