Ship a yarn.lock - WIP

[Conrad2134]

For #1551: Tried wrapping my head around this, and I'm stuck on how exactly we can generate a true lockfile since we're not testing a "released" version of react-scripts.

If anyone has a better grip on this than me, I'd love for you to set me straight!

[facebook-github-bot]

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at [email protected]. Thanks!

If you are contributing on behalf of someone else (eg your employer): the individual CLA is not sufficient - use https://developers.facebook.com/opensource/cla?type=company instead. Contact [email protected] if you have any questions.

[Conrad2134]

@Timer @gaearon - this is for #1551. Any ideas? I started to look at it and then started to question how exactly we'd be able to generate a true lockfile referencing something that hasn't been released yet.

[facebook-github-bot]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

[Timer]

The yarn.lock will probably need to be handled completely by create-react-app (the CLI). We can probably generate one post-release and attach it to the release (on GH), then downloading it on app creation.

I don't think we can just toss it in template because it'd be outdated and not supported by older CLI versions (to update the versions for the release).

[Conrad2134]

Ah okay - I think I get that.

So whoever is releasing it would generate the yarn.lock manually (post-npm run publish) and attach it to the Github release? Is there a good way to link to the downloads of the latest release on GitHub? The releases API is my only guess.

Right now it publishes one after another, but I don't suppose there's a good way to release react-scripts and then stick a yarn.lock file in the CLI package before publishing it? That way it wouldn't have to go out and download something - it would already have it from the moment it gets published.

[Timer]

I'm not sure if lerna is pluggable enough to let us do that step without a release of create-react-app after normal release. I'm not sure which would be better. But ideally we'd have a postpublish script that does this automatically.

[Conrad2134]

This is what I have so far. It's a little messy, but I'll clean it up. I think this is sort of what we were getting at, but let me know if you had a different vision for it.

If we're going to download a yarn.lock, we'll also want to download the package.json that goes with it, since we need to make sure what's in the yarn.lock satisfies what's in the package.json.

[gaearon]

I'm worried GH API might rate limit our users, no?
Is there a more stable way to do this?

[Timer]

https://developer.github.com/v3/#rate-limiting

For unauthenticated requests, the rate limit allows you to make up to 60 requests per hour.

[Timer]

We could use some sort of mirroring service; though as long as we handle this gracefully it shouldn't matter -- providing the yarn.lock isn't critical -- just nice to have.

[gaearon]

I think I might feel more comfortable relying on something like unpkg.com here, e.g. https://unpkg.com/[email protected]/README.md.
Also I think it is important to try to provide Yarn users with a consistent experience.

[Conrad2134]

We wouldn't be able to publish the updated yarn.lock (and package.json) with react-scripts though, since we'd want the yarn.lock to reflect the latest react-scripts (we'd only be able to generate it properly after react-scripts was published.. And we wouldn't publish it within the CLI since you'd need to have the latest CLI to use the latest react-scripts when bootstrapping.

It is a nice to have - if it starts to get too complex / too difficult to maintain, I don't want to force it.

[gaearon]

This might be a problem: yarnpkg/yarn#1435 (comment)

[Conrad2134]

Looking at this more, and having sat on it for a while, I'm not sure exactly how we'd go about accomplishing this (even forgetting the optional dependency / platform issue - which is already or is about fixed, I think). Honestly, I think the complexity that it would add (assuming there was an acceptable way of doing it) wouldn't be worth the value added. It can be done, sure, but I don't see a simple solution that I feel comfortable with.

If someone has a specific vision and knows how to accomplish it, I think that would be great, but I don't see this as a good fit as I have it sketched out now. If y'all agree, we can close this. But, if you have some ideas let's talk about it.