poor UX when resetting lockfiles

[aep-sunlife]

Hi,

yarn overcomplicates the process of resetting all lockfiles, junkfiles, etc.

• When I remove .yarn, .pnp.*, and yarn.lock, then the next yarn install fails. This command should understand how to regenerate everything again, like npm install, based on an existing package.json file. Instead, it bails with an assortment of confusing options.
• yarn init always forcibly overwrites existing package.json files. Instead, it should first check whether the file exists. Only overwrite if the file definitely does not exist.

So the workaround workflow involves manually backing up my package.json file, running yarn init, and replacing the stub package.json file from my backup. That's risky, manual, and unintuitive. We're moving backwards from npm capabilities.

[clemyan]

yarn.lock

The lockfile is your known good state. By throwing that away and resolving everything again you get a different set of packages, so breakage is a definite possibility.

Yarn curates the .yarn/cache (if you use a local cache), .yarn/install-state.tgz, and .pnp.* for you. Just make sure your package.jsons and yarn.lock is in a good state and those will generated in a repeatable manner.

yarn install fails
Instead, it bails with an assortment of confusing options.

It'd be nice if you had included details on that so we can determine if there is an actual bug

npm install

npm will do the same thing. Delete package-lock.json and npm install will potentially give you a different set of packages, and potentially hoisted differently than before

yarn init always forcibly overwrites existing package.json files. Instead, it should first check whether the file exists. Only overwrite if the file definitely does not exist.

That'd be a good feature request