Workflow disruption

[Timer]

Between 8:15 PM - 9:15 PM (EST) newly created applications could not be started with npm run start.

Failed to compile.

Error in ./src/index.js
Module build failed: TypeError: /Users/joe/Desktop/testing/src/index.js: Cannot read property 'scope' of undefined
  @ multi main

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 and yarn.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? 🤷‍♀️

[Conrad2134]

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.

[Timer]

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 react-scripts.

[Conrad2134]

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.

[Timer]

We'd probably just push the responsibility of publishing onto our CI server which would generate a lockfile and run tests against it.

[wtgtybhertgeghgtwtg]

Wouldn't that still break when the user runs yarn upgrade or installs a dependency?

[gaearon]

bundledDependencies likely won't get better because they are a fringe feature. They cause other problems, are buggy, and Yarn doesn't support them either.

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”).

[Conrad2134]

@wtgtybhertgeghgtwtg - yes and yes, but that's on the user. yarn add shouldn't have much of an impact compared to yarn upgrade (although it could, someone better versed in the ways of Yarn can speak to that).

[Timer]

@wtgtybhertgeghgtwtg I don't believe yarn add upgrades anything unintentionally, but the benefit here is that they can rollback their yarn.lock file (if source controlled) and have a working project instead of manually trying to diagnose and fix errors.

[Timer]

@gaearon adding docs will go a far way, but it still doesn't solve fresh installs unless if we add the yarn.lock to the template

[gaearon]

but it still doesn't solve fresh installs unless if we add the yarn.lock to the template

If user doesn't have Yarn then lockfile wouldn't be useful anyway.
If user has Yarn then yarn.lock will get created automatically in the project folder (I just tried it).

[Timer]

The lock file generated on install wont be of use to them if the registry has a bad published version.
The case you described enables rollbacks for upgrades and unintended breaks when switching machines, but not the initial install.

[gaearon]

Ah, I get it now. Maybe we could bundle last known good yarn.lock for Yarn users?

[Timer]

That's what I was thinking, we can detect if they have yarn and include a yarn.lock file. Should we do the same for npm-shrinkwrap.json?