Support yarn/npm link'ed packages by default

[stristr]

This PR contains a simple update to the dev/prod webpack configurations that enables yarn link and npm link to work out of the box with react-scripts.

Background

Webpack provides a resolve.symlinks configuration option, and the documentation states:

this may cause module resolution to fail when using tools that symlink packages (like npm link)

…and it does. A basic failing use case is:

# /some/local/directory/foo/package.json

{
  "name": "foo",
  "main": "index.js",
  "dependencies": {"react" : "..."},
  ...
}

# /some/local/directory/foo/index.js

const react = require('react');
// ...

If I run yarn link foo inside a react-scripts project, the resolve.symlinks option will tell webpack to resolve ./node_modules/foo -> /some/local/directory/foo with Node module resolution applied to all the require(...)s therein. In particular, this means that inside this symlinked module, require('react') will do one of two things:

1. Resolve to whatever version has been installed locally (e.g. /some/local/directory/foo/node_modules/react instead of ./node_modules/react)
2. Fail to resolve at all if I haven't run [yarn|npm] install in /some/local/directory/foo yet.

Clearly neither of these is desirable—the typical use case for yarn link is to shim an in-development library into another project exactly as if it had been installed via yarn, except possibly with local modifications. I have even worked with teams that deploy from codebases with yarn link'ed dependencies.

Rationale

I'm proposing this change because I think supporting yarn link and npm link is a relatively common use case (see #3547 and the various associated issues), and that the use cases in which we would want to resolve symlinks to their actual locations are far more advanced than the use cases in which we wouldn't. So this seems to meet the needs of the pre-ejection CRA target audience better than the default webpack symlink resolution behavior.

[stristr]

Prior art: #3695

[stale]

This pull request has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

[stristr]

Keep alive!

[stale]

This pull request has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

[stristr]

Keep alive!

[yhnavein]

@stristr Can you check if other approach from my PR (#6207) works for your case?

[stristr]

Closing in favor of #6207.