Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at cla@fb.com. Thanks!

If you are contributing on behalf of someone else (eg your employer): the individual CLA is not sufficient - use https://developers.facebook.com/opensource/cla?type=company instead. Contact cla@fb.com if you have any questions.

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

Hmm, ignore for now? I can't get this build failure to repro locally :(

EDIT: Fixed build issues. Apologies for the spam.

with this change, are the scoped package steps still needed if you're not making a long running fork?

I want to be able to take my existing app, pull someone's branch for an open PR, run npm link react-scripts, and see how those changes work in my app. And then npm unlink react-scripts once I've gotten to test. This simple flow works with most other dependencies... can it work with react-scripts?

Yep, should work. Running npm link <react-script-module-name> from your app should change the path under node_modules to pick up the local dependency. The original issue (and my particular set up) were based on longer term forks.

Could you write up another explanation about why this works and solves that use case?
I read the comments but I still don’t get it. (Sorry!)

When you try to use npm link to reference a forked version of react-scripts, the original logic of paths.js uses the template from the react-scripts module (i.e. packages/react-scripts/template) instead of the app itself (e.g. src). You can see this by following the repro steps in the initial comment. After a ton of trial and error, I came up with a set of conditions for when to use the template, and when to use local source files of the app referencing react-scripts. There are effectively three cases to look for, so I'll walk through each one.

1. isRunningFromOwn: this is actually preserving the case noted by this comment.
2. isSmokeTest: this is a special case that I wasn't able to work around in a more elegant way. I'll talk about this one in the next case.
3. isRunningFromAppUsingLink: when using npm link, the current dir contains packages/react-scripts/template, which when using the current implementation, resolves the paths to point to the template in react-scripts instead of the source files in the app referencing react-scripts. When trying to separate this case out, I ran into two additional conditions I need to check for where it is valid to keep using the template:
   a. process.env.npm_lifecycle_event === 'start': by checking for this, we ensure that we don't clobber the existing cases for build, publish, etc. where we don't want to look at an invalid path for the template. In other words, it's still correct to look for the template at packages/react-scripts/template.
   b. !isSmokeTest: without checking for this case, the tests would break since they'd look at the wrong path for the template. I borrowed the special check for a smoke test from here.

With the special logic to track isRunningFromAppUsingLink, I refactored the existing usages of resolveApp and resolveOwn to handle this special case.

Tagging as 0.9.1 as I'd like us to understand what's the problem here, and maybe merge this in some form.

I believe that this is trying to accomplish what #1356 does, but in a much more convoluted way.

I appreciate all your hard work and explanations @tabrezm, but I'm going to close this in favor of #1356 since it is a more straightforward modification.

Please do not hesitate to reach out to us if this does not resolve your use case.
It will be available when 0.9.1 is released, or you can test it manually sooner. 😄