feat(cli) check and warn if npx react-native version is using an old cached version

[blakef]

Summary:

Currently npx has a variety of caching strategies to avoid having to pull a version of the package from a registry. These are often unexpected to our users, who may fall behind. After looking at a variety of fancy approaches to dealing with this (the high end of which was intelligently forking npx to run npx react-native@latest <args>, the best possible tradeoff for time and simplicity was to warn the user when they weren't running the latest release:

Problem Details

On my laptop when you run npx <package> <arguments> this it eventually calls libnpmexec, which applies this lookup algorithm for package@version:

• is package available in local modules (npm root → ~/project/node_modules/<package>)?. Importantly it will walk all the way down to / looking for node_modules/<package>.
• is package available in global modules (npm root -g → /Users/blakef/.nvm/versions/node/v17.9.0/lib/node_modules)?
• is package available in npx cache (~/.npm/_npx)?
• is package available in your registry? Download to the npx cache ~/.npm/_npx/<hash>/
  At this point you'll have a cached copy, which then has its bin script run with the arguments you originally provided.

How this works against React-Native users

Users can get their development environment into a persistent pickle with a bunch of unintended side-effects of npx / npm exec’s caching model:

• It matters where you run npx react-native, since it’ll default to the version of react-native in a node package's folder. This works well for us in a React Native project, but not when initializing a project outside of a package folder.
• Global and relative node_modules really matter. If your users runs npx react-native init and they have a version of react-native installed globally, it’ll use that version.
• If the user has a node_modules/react-native installation anywhere in the directory hierarchy it’ll be used. For example if I run npx react-native init Foobar in /home/blakef/src/example , npx will look for versions of react-native like this before searching globals or the npx cache:
  • /home/blakef/src/example/node_modules
  • /home/blakef/src/node_modules
  • /home/blakef/node_modules
  • /home/node_modules
  • /node_modules
    nvm just makes things harder if your user switches between versions of node it can be hard to determine if they're affected by a globally installed version. Examples include having a .nvmrc file in the directory they run the command which transparently switches node version (and globals location).

Changelog:

[General][Added] - Log a warning if npx react-native uses old cached version

Test Plan:

Ran this directly from the project, defining the npm_lifecycle_event=npx to mock directly running using npx.

[facebook-github-bot]

@blakef has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

[analysis-bot]

Platform	Engine	Arch	Size (bytes)	Diff
android	hermes	arm64-v8a	8,733,278	-94
android	hermes	armeabi-v7a	8,044,461	-97
android	hermes	x86	9,223,383	-97
android	hermes	x86_64	9,075,371	-90
android	jsc	arm64-v8a	9,298,078	-103
android	jsc	armeabi-v7a	8,486,814	-100
android	jsc	x86	9,359,240	-109
android	jsc	x86_64	9,615,336	-91

Base commit: 92c7219
Branch: main

[facebook-github-bot]

@blakef merged this pull request in bfca23a.