-
-
Notifications
You must be signed in to change notification settings - Fork 26.8k
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
Workflow disruption #1551
Comments
Yarn only uses the top-level yarn.lock - but that should be enough, right? The lockfile includes direct and transitive dependencies. If you package a version that works, it'll work on the client until they run an upgrade. |
That might work if we ship it as part of our template, which seems a bit finicky. Maybe we could detect Yarn on the system and copy it from |
Keeping a lockfile up to date would be a manual process, right? Each release someone would have to regenerate an up-to-date lockfile if it were being shipped with the template. |
We'd probably just push the responsibility of publishing onto our CI server which would generate a lockfile and run tests against it. |
Wouldn't that still break when the user runs |
Shrinkwrap only works on npm but not Yarn. I think we should just teach people about setting up Yarn and using a lockfile. That solves all problems. We can include this in the User Guide (e.g. “Ensuring Deterministic Builds”). |
@wtgtybhertgeghgtwtg - yes and yes, but that's on the user. |
@wtgtybhertgeghgtwtg I don't believe |
@gaearon adding docs will go a far way, but it still doesn't solve fresh installs unless if we add the |
If user doesn't have Yarn then lockfile wouldn't be useful anyway. |
The lock file generated on install wont be of use to them if the registry has a bad published version. |
Ah, I get it now. Maybe we could bundle last known good |
That's what I was thinking, we can detect if they have yarn and include a |
Shrinkwraps are a pain to deal with so I don't want to create one by default. |
It's odd, npm advises to ship |
Could we have edit: or even package.json has a |
It doesn't make sense to ship |
Ah, that's right -- that makes more sense. But yes, we'd be making the top-level |
Then it wouldn't have any effect because the next person to clone the project (e.g. teammate) will use the regular resolution mechanism. So we can't ship a shrinkwrap unless we actually ask people to use it (which I'm not recommending). |
Mmm yeah you're right, the next teammate would potentially have a problem then. Sounds like a yarn-only solution for now if we go through with it. 👍 We can wait to see if anyone else provides some feedback. |
Want to send a PR for Yarn-only solution? We can also leave it for contributors if we explain in more detail how it's supposed to work. |
I probably wont have time to work on this until the weekend. We could add the I'd be more than happy to answer any questions for someone who'd like to do this. |
Would that get rid of the There'd have to be a CI specific process then - CI does like it does now, but for a normal user it would just run I'm happy to take a stab at it if I can wrap my head around what all needs done :) |
Yes. We might want to do it after #1253 which also groups |
Per our quick discussion on #1253 - I'll wait until that lands to start the PR for this, if that works. |
Closing this as I believe it's pretty inactionable by us. |
Between 8:15 PM - 9:15 PM (EST) newly created applications could not be started with
npm run start
.One of our dependencies released a backwards incompatible change in a minor release.
We typically try to avoid this by pinning our package versions, but we currently have no way of ensuring deterministic builds.
Few users were affected, but situations like these raise questions about how we can prevent this from happening in the future.
We want to ensure we keep our users' trust in our reliability, and I think this deserves some discussion about what can be done.
Is there anything that prevents us from shipping releases with
npm-shrinkwrap.json
andyarn.lock
files (does yarn try use dependents lock files?)?Should we start bundling dependencies again? There seems to be hard feelings about them: #1068. Are they better in NPM 4? Can we push to make them better?
Or should we live with that accidents happen? 🤷♀️
The text was updated successfully, but these errors were encountered: