Currently the package graph ordering is defined in

and only takes dependencies into account, and not peerDependencies. This means it is possible to publish a module with a peerDependency on a specific version that you are publishing at the same time, and the version with the peerDependency may be published before the version that it depends on.

Expected Behavior

Ideally the version ranges in the peerDependencies should be validated, and if the range is only satisfied by the version you are just about to publish, it should publish it later, after the dependency is publishes.

Context

Just noticed on Babel that @babel/cli was being published before @babel/core which means there is a period (which on this publish was about 4.5 minutes, since we publish a LOT of packages), where the CLI depends on a non-existent version of @babel/core because during our beta phase we're using specific non-range peerDependencies. That gets extra dangerous once you take caching registry mirrors into account.

Your Environment

Executable	Version
lerna --version	2.0.0
npm --version	VERSION
yarn --version	1.6
node --version	6.12.3