regression: require.resolve() caches package.json when it shouldn't

[andreialecu]

• Version: 12+
• Platform: any
• Subsystem: any

What steps will reproduce the bug?

Repro at:
https://runkit.com/andreialecu/5f4a0a45b7d56e001a469c1e

const {readFileSync, writeFileSync, mkdirSync} = require(`fs`);
const {join} = require(`path`);
//const rimraf = require(`rimraf`);

//rimraf.sync("./node_modules/foo");
mkdirSync("./node_modules");
mkdirSync("./node_modules/foo");
writeFileSync("./node_modules/foo/bad.js", "module.exports = 'WRONG'");
writeFileSync("./node_modules/foo/good.js", "module.exports = 'CORRECT'");

writeFileSync(`./node_modules/foo/package.json`, JSON.stringify({
  name: 'foo',
  main: "bad.js",
}, null, 2));

// this caches the entry file and it cannot be updated
// comment it out for different output:
console.log(require.resolve(`foo/package.json`));

writeFileSync(`./node_modules/foo/package.json`, JSON.stringify({
  name: 'foo',
  main: "good.js",
}, null, 2));

console.log(require.resolve(`foo`));
console.log(require(`foo`));

How often does it reproduce? Is there a required condition?

Always.

What is the expected behavior?

I think require.resolve should not commit anything to cache (as opposed to require()). On node versions <12 this problem didn't exist, so it may be a regression.

What do you see instead?

The main entry point of the resolved dependency is cached and sticks for the duration of the process.

Additional information

The use case is checking whether the version of a dependency needs updating, and if it does, run npm/yarn install to update it (as part of a cli tool, @angular/cli in this case).

After the update finishes, the package would still load as the old version. I expect require() to cache it, but not require.resolve(). It resulted in a very hard to track bug while working on an issue in the @angular/cli repository. Additional info in: angular/angular-cli#18610

[andreialecu]

I think it's possible this may have been introduced in #29492 /cc @guybedford

Also this comment seems to have been ignored: #29492 (review)