Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Variable Substitution in package.json #16

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

jordwalke
Copy link

No description provided.

@ForbesLindesay
Copy link

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
Copy link

ljharb commented Nov 1, 2016

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
Copy link
Contributor

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
Copy link
Contributor

@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
Copy link

ljharb commented Nov 1, 2016

@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
Copy link
Contributor

@ljharb https://discord.gg/yarnpkg

@bestander
Copy link
Member

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
Copy link

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
Copy link

ljharb commented Nov 1, 2016

@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
Copy link
Contributor

@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
Copy link

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.

@bestander bestander self-assigned this Jan 19, 2017
@BYK BYK self-assigned this Sep 29, 2017
@BYK BYK removed their assignment Oct 6, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants