Variable Substitution in package.json

[jordwalke]

No description provided.

[ForbesLindesay]

I'm confused as to why this keeps talking about git tags rather than just npm packages. I don't think we should encourage people to use git rather than the npm registry.

I do think it's better for the package you depend on to specify how to get the prebuilt binaries. Ideally I think the package should just be able to specify some kind of "cache-builds" flag and a benevolent third party could run & host the build for yarn. Setting up cross platform CI and deployment is still a PITA.

[ljharb]

It would be very bad for yarn to support any format in package.json that would break npm. Any yarn-specific info should go in new package.json keys - the format of deps/devDeps/etc is fixed.

[jamiebuilds]

I'm just going to drop this in here to make a note of it, I don't actually want to discuss it here because it detracts from the actual issue.

Features that are targeting support for other languages shouldn't restrain themselves too much to remain compatible with the npm client. They should try for it if possible, but if getting Language X users to adopt Yarn requires a feature that is incompatible with the npm client we shouldn't treat that as an absolute blocker to getting something in. I don't see a world where Language X users adopt Yarn and suddenly want to use the npm client, and so I don't think that the npm client should dictate how features should be built.

[jamiebuilds]

@jordwalke It seems to be that the control should be inverted. Rather than having the variables in the "dependencies" of each dependent. It should be in the package itself to dictate where the builds for each platform is.

[ljharb]

@thejameskyle i think that when it would affect published packages - ie the ecosystem - where consumers will be using npm to consume it, I think it's critical to remain compliant with npm. Can you point me to where a better place to discuss this would be?

[jamiebuilds]

@ljharb https://discord.gg/yarnpkg

[bestander]

I think this can be rather useful for Node.js ecosystem as well so npm compatibility would be a huge bonus.
@thejameskyle and @ForbesLindesay have good points

[ForbesLindesay]

I don't think this feature requires any incompatibility with npm. The goal here that both @jordwalke and I seem keen on (unless I'm mis-reading something here) is that we should design this such that npm simply builds modules from source, but yarn can occasionally be smarter.

[ljharb]

@ForbesLindesay that would be a wonderful improvement, as long as npm can still build from source :-) i was mostly cautioning against the breaking change to a key in dependencies.

[jamiebuilds]

@ForbesLindesay That would be nice, but in it's current form this RFC does not do that.

1. npm won't be able to install the dependency: "ourGitUrl#0.4.4.(anyOs).(anyCpu)"
2. many of the dependencies needed to build from source would belong in devDependencies which is currently not installed by npm.

For # 1 we could invert the control as I suggested above, but for # 2 you'd need a new type of dependency in npm like buildDependencies which npm could use to build from source and yarn could ignore. We can but we don't want people shoving everything in "dependencies" because that just makes yarn install a bunch of potentially huge dependencies for no reason

[ForbesLindesay]

For 1 I thought the whole point was that because parenthesis are allowed, npm would work. If not we could pick a different delimiter. Anyway, with our new approach this is redundant.

For 2, the post install script could install the build dependencies before doing the build. Alternatively we could put those deps in the normal dependencies (or maybe optionalDependencies) slot and still support listing does that yarn should ignore if a prebuilt binary is available. Yarn will still need to be able to build from source anyway.