Fixes virtual resolution

[arcanis]

This diff fixes a problem where the virtual packages aren't generated until after a full resolution pass got triggered. This was causing issue with for example yarn pack, which doesn't initiate any resolution pass.

To fix that, multiple actions have been taken:

• First, the Project.find method will automatically resolve the virtual packages. This ensures that at the very least, the information obtained from the lockfile are in a usable state even without new resolution pass.

• Second, a bug got fixed so that we properly reset the virtual packages before starting a new resolution pass (otherwise we'd end up virtualizing them multiple times).

• Third, the pack command now triggers a resolution pass when initializing.

This last point may look curious given I just said that the Project.find method will automatically resolve the virtual packages. This is because there's a subtle difference depending on whether or not you trigger a full resolution pass:

• If you don't trigger a resolution pass, and only rely on the virtual package resolution, the dependency tree will get its information from the exact state of the lockfile, without looking at the filesystem at all (not even for workspaces).

• If you trigger a resolution pass, the dependency tree will update its information based on the updated filesystem.

So for example, let's say you add a new binary to one of your packages, you'd need to run yarn install in order to update the lockfile metadata before this binary is made available (this only affect binaries; scripts are always detected at runtime).

That being said, I'm not entirely sure which of the two behaviors is the most consistent: full resolution pass for every command that may happen to run scripts, or not? ...

[arcanis]

I removed the resolutions passes; commands will instead rely on the automatic virtual resolution as much as possible (it implies that they will not automatically find newly added binaries).

The reason for this change is that Yarn 1 already required yarn install to be run to take new dependencies or binaries into account (otherwise they wouldn't have been linked into the .bin folders), and it seemed to work back then. Don't fix what ain't broke 🙂