Skip to content

Don't crash if users mistakingly install babel, webpack, jest, loaders, etc, at the top level #1795

Closed

Description

@gaearon

I’ve seen this issue multiple times. For some reason people don’t believe react-scripts is enough and try to install Babel, Webpack, and friends themselves. This can break things.

We need to mitigate this somehow.

Activity

  1. gaearon commented on Mar 17, 2017

    @gaearon
    ContributorAuthor

    @anyayunli If you’d like control over configs, run npm run eject and you have it. This issue is not related to that.

  2. langpavel commented on Mar 17, 2017

    @langpavel

    This is about inexperienced developers. It can be limited only by more educational examples and strict rules for opening issues.

  3. langpavel commented on Mar 17, 2017

    @langpavel

    And more visible dedicated site for users, stack overflow is not enough

  4. Timer commented on Mar 17, 2017

    @Timer
    Contributor

    Is there anything wrong with us showing a nasty-looking warning when people do this?

  5. langpavel commented on Mar 17, 2017

    @langpavel

    No, really not. You are experiencing success, you only need way to fastly redirect people from Github to more general discussion about when they should eject!

  6. Timer commented on Mar 17, 2017

    @Timer
    Contributor

    Optimally, we want people not to eject. I feel like there's way too many small things people eject for that's accomplishable without ejecting (e.g. using sass-loader).

  7. langpavel commented on Mar 17, 2017

    @langpavel

    So, this can be statistically observed. You can inject some questionary into eject command with helpful links. This is task for @cpojer like person:-)

  8. Timer commented on Mar 17, 2017

    @Timer
    Contributor

    @gaearon what about something like this?

  9. langpavel commented on Mar 17, 2017

    @langpavel

    Nice, but not enough. It will works BUT you are not providing hint. When you run eject, it should ask you why you need eject providing most relevant information. No way back after. That's ok, but warn about they are not supported by this awesome toolkit any more..

  10. gaearon commented on Mar 17, 2017

    @gaearon
    ContributorAuthor

    I’d like us to first look into why this breaks CRA. If there's a version conflict, react-scripts should use its own version of webpack. We should fix whatever breaks so that outer version of webpack is just ignored. We can optionally warn on top of that but first we should fix the breakage.

  11. langpavel commented on Mar 17, 2017

    @langpavel

    Different idea. Can you hook yarn with CRA? For example as preinstall, pre-add in package.json. I know, this is something new! But this is in your possibilities!
    Or you can create recommended way to install new dependencies with CRA specific cli tool, promote it and drive mainstream. This will give you less observable force than patching yarn. Controversial but, hey, look at real people!

  12. gaearon commented on Mar 17, 2017

    @gaearon
    ContributorAuthor

    We already use Yarn when it’s installed. It doesn’t solve the problem though.

  13. langpavel commented on Mar 17, 2017

    @langpavel

    Yarn hook which will dog watching what you want add

  14. langpavel commented on Mar 17, 2017

    @langpavel

    It's entire new space not possible today. Yes you can give recommendations only..:
    You just installed package xyz. Did you consider this way? Http....

  15. 5 remaining items

  16. gaearon commented on Jan 8, 2018

    @gaearon
    ContributorAuthor

    No idea, but if you can create one that would be great. My impression is you need to create a project and then install eslint@4, babel@5, jest@16, etc, and try to trigger it this way.

  17. gaearon commented on Jan 8, 2018

    @gaearon
    ContributorAuthor

    Here is an example, updating jest to 22 might reproduce this.
    jestjs/jest#5119 (comment)

  18. omeid commented on Jan 8, 2018

    @omeid

    Any solution to this would require CRA to work around how the package manager works, which in my opinion is not the right thing. A package should not override the package manager rules.

    I am okay with a mechanism that detects wrong versions of the packages and warn, or at worst, just give up.

  19. viankakrisna commented on Jan 8, 2018

    @viankakrisna
    Contributor

    experimented using pkg to package react-scripts as an executable: https://github.com/viankakrisna/react-scripts-packaged/releases/tag/0.0.1

  20. jlongster commented on Jan 9, 2018

    @jlongster

    I personally think Jest should be excluded from this list. Using testing through CRA is optional. I'd like to use CRA for all the tooling to setup and run and app, but do testing myself (I like to interact with jest directly).

    Maybe the create-react-app script to run tests could do this check, so you would only fail if you locally had jest installed and tried to run tests through CRA. Maybe that's how it's intended to work and I missed that point. :) If so, that sounds great.

  21. gaearon commented on Jan 9, 2018

    @gaearon
    ContributorAuthor

    I think we keep talking past each other. Sorry if I'm being confusing.

    I don't propose to forbid using your own version. (Early wording says that but my more recent comments don't.)

    What I'm saying is we should make sure that installing arbitrary Jest/Babel/Whatever version at top level does not break any of built-in react-scripts functionality. So you should be able to use them side by side if you know what you're doing. In fact that's how I'd expect it to already work—I have no idea why it breaks (according to reports).

    Does this clarify things? That's the only problem I'm referring to in this issue.

  22. jlongster commented on Jan 9, 2018

    @jlongster

    I may have missed a reply, especially since there were two threads that got merged. Sounds great. Sorry if I didn't read the original description well enough.

  23. gaearon commented on Jan 12, 2018

    @gaearon
    ContributorAuthor

    I did some debugging. The Jest issue is caused by how Jest packages communicate: jestjs/jest#5294.

  24. changed the title [-]People try to install babel, webpack, loaders, etc, at top level[/-] [+]Don't crash if users mistakingly install babel, webpack, jest, loaders, etc, at the top level[/+] on Jan 12, 2018
  25. gaearon commented on Jan 12, 2018

    @gaearon
    ContributorAuthor

    For Webpack, this happens (at least with npm) because:

    • node_modules/react-scripts imports node_modules/html-webpack-plugin (which npm hoists at the top for some reason)
    • node_modules/html-webpack-plugin imports webpack and gets the top-level "wrong" node_modules/webpack rather than the intended node_modules/react-scripts/node_modules/webpack

    I don't know why html-webpack-plugin gets hoisted but I also don't quite see how to avoid it. For example in monorepos it's expected more things get hoisted.

  26. gaearon commented on Jan 13, 2018

    @gaearon
    ContributorAuthor

    I chatted to npm folks about #1795 (comment) — it is a known npm issue. Yarn doesn't have it. They tried to fix it in 5.x but that created other issues so they're holding off until future majors.

  27. gaearon commented on Jan 13, 2018

    @gaearon
    ContributorAuthor
  28. gaearon commented on Jan 13, 2018

    @gaearon
    ContributorAuthor

    Fixed by #3771.

    There is a way to opt out of the preflight check for those who know what they're doing (it's mentioned at the end of the displayed message).

  29. locked and limited conversation to collaborators on Jan 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions