Issue 1:
Is there an existing issue for this?

I have searched the existing issues

Current Behavior

peer-test/package.json

{
"name": "peer-test",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"dependencies": {
"peertest-a": "^1.0.0",
"peertest-b": "^1.0.0"
},
"keywords": [],
"author": "",
"license": "ISC"
}

peertest-a have 1.0.0 and 2.0.0(latest) all of them have dependencies and peerDependencies are empty

peertest-b/package.json 1.0.0(latest)

{
"name": "peertest-b",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"dependencies": {
"peertest-c": "^1.0.0"
},
"keywords": [],
"author": "",
"license": "ISC"
}

peertest-c/package.json(latest)

{
"name": "peertest-c",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"peerDependencies": {
"peertest-a": ">=1.0.0"
},
"keywords": [],
"author": "",
"license": "ISC"
}

Expected Behavior

cd peer-test
npm i

expect peer-test/node_modules

node_modules
-peertest-a 1.0.0
-peertest-b 1.0.0
-peertest-c 1.0.0

but the fact is

node_modules
-peertest-a 1.0.0
-peertest-b 1.0.0
-node_modules
-peertest-c 1.0.0

so , I want to know why peertest-c can not move to ROOT.

But, I change peertest-c peerDependencies to ^1.0.0，the result is true.

Steps To Reproduce

cd peer-test
npm i

Environment

OS: win10

Node: v14.17.5

npm: 8.0.0

Issue 2:
Is there an existing issue for this?

I have searched the existing issues

Current Behavior

Currently all of our open source projects and many of our non-open source projects are unable to build because npm 7+ is reifying different file trees based on the publish event of an unrelated module. This meant that all of our builds that were working suddenly stopped working even though no dependencies changed on our side.

Here's a reduced test case repo with detailed explanation and steps to repro: https://github.com/ryanblock/npm-time-based-dependency-graph

Summary:

This project has two dependencies: eslint@7 (which has many subdependencies) + @architect/eslint-config, which has 3 subdependencies:

eslint-plugin-filenames

eslint-plugin-fp

eslint-plugin-import

When deps before 2021-10-09T20:46:00.000Z are installed:

The 3 eslint-plugin-$name dependencies above are installed flatly into node_modules/ (e.g. node_modules/eslint-plugin/filenames)

When deps before 2021-10-09T20:47:00.000Z are installed (one minute later):

The 2 of 3 plugins are installed into node_modules/@architect/eslint-config/node_modules/ (specifically eslint-plugin-filenames, eslint-plugin-fp)

The 3rd plugin is still installed flatly into node_modules/

eslint then runs, and cannot find eslint-plugin-filenames (nor eslint-plugin-fp, but it fails on the first plugin) because they are both installed in node_modules/@architect/eslint-config/node_modules/, away from the reach of Node's module resolution

Note: eslint@8 DOES NOT appear in this dependency tree anywhere, however it was published at 2021-10-09T20:46:13.874Z

This implies that Arborist / npm is reifying module locations based on the existence of a package that is not even in use in this project

Expected Behavior

No matter when npm i is run in a project with identical dependencies, the filesystem results should be the same.

Steps To Reproduce

Steps to reproduce can be found at the following reduced test case repo: https://github.com/ryanblock/npm-time-based-dependency-graph

Environment

OS: macOS 11.6

Node: 16.10, 16.11

npm: 7, 8 (does not reproduce in npm 6)