add support for installing react-scripts using npm link

[tabrezm]

When using npm link to depend on a forked version of react-scripts, the paths are set up incorrectly such that the source files in the react-scripts template get used instead of the actual source files from the app.

Repro steps:

1. Create a package using the public version of create-react-app.
2. Clone create-react-app from GitHub and convert packages/react-scripts to a scoped package. For example, change this:

  "name": "react-scripts",
  "version": "0.7.0",

to this:

  "name": "@tabrezm/react-scripts",
  "version": "0.0.0",

3. Run npm link from packages/react-scripts.
4. Run npm link @tabrezm/react-scripts from the folder for the package created in step 1. Also, change the following lines in package.json from this:

  "devDependencies": {
    "react-scripts": "0.7.0"
  },

to this

  "devDependencies": {
    "@tabrezm/react-scripts": "0.0.0"
  },

5. Change something in App.js and run npm start.

Expected: see new content
Actual: see content from template in react-scripts instead

Full discussion: #682 (comment)

[facebook-github-bot]

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.

[facebook-github-bot]

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

[tabrezm]

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

EDIT: Fixed build issues. Apologies for the spam.

[raycohen]

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?

[tabrezm]

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.

[gaearon]

What is special about start? I don't understand this.

[tabrezm]

Without including the check for start, (i.e. only checking isRunningFromOwn && !isSmokeTest), the tests fail because those conditions are both true for other events like build. At first glance, it may be assuming too much, as it's entirely possible that someone will write an app that has other start-like events, but are named something else. But they should be able to handle their own custom cases since they'll be forking react-scripts in the first place.

[gaearon]

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!)

[tabrezm]

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.

[gaearon]

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

[Timer]

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. 😄