Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

React Native and tooling: a round up #370

Open
kelset opened this Issue May 23, 2018 · 3 comments

Comments

Projects
None yet
2 participants
@kelset
Copy link
Collaborator

kelset commented May 23, 2018

I feel like (from looking at the issues that get open constantly) there is an overall incomprehension/misunderstanding of how many moving parts are interconnected to make a React Native app project run.

In particular, there are two kinds of issues I see appearing every now and then:

  • the FOMO effect: people see a new version of a tool, install it right away without any necessary reason (but simply because it's the latest) and then flip tables because their app breaks.
    example: facebook/react-native#19321

  • the Overlord rollout: some external tool gets 'force updated' / a new minimum version gets enforced and hell breaks lose.
    example: facebook/react-native#19259

IMHO, a way to potentially decrease / reduce these effects - which go beyond the control of react native - is to better communicate and educate developers about the existence of these tools and the overall approach to them. In particular, I think it would be a good start to add a table with the 'we know this version of this tool works' approach (ex. tool / creator / latest know version to work well) and a page in the docs with a brief description of each one (or a mix of both?).

So I decided to open this issue - Here is what I would like to discuss:

  1. Does this reasoning make sense?

  2. What approach should we communicate as the 'best/safest/approved'?

I think the overall reasoning should be "don't update unless necessary, and before upgrading run a search on open issues".

  1. What tools should the list comprehend?

My current take of this is 'all of the ones we can think of' - and here's a list of the ones that come into my mind at the moment:

@GantMan

This comment has been minimized.

Copy link
Contributor

GantMan commented May 25, 2018

Here's an interesting part to add. Some of those tools are optional. Like XCode... though it's at the core, if you're doing Android dev on a Windows machine you should never see watchman or Xcode!

I found this problem difficult to solve, but do a pretty ok job for my solidarity plugin for react native.

Things my plugin has noticed that I see missing above are the following. Even though many of these might be optional, they could be essential if a team is using them. That's the funny part isn't it?

  • Node - yes some people don't have it
  • yarn - optional
  • mobileCenter - optional
  • codePush - optional
  • pod - optional
  • detox - optional
  • typescript - optional

I'd love to have solidarity be a tool we could use for our reports if possible. It supports plugins, so it can do anything we need it to. I'm just not always familiar with each person's problem to prescribe it.

I hope this list and offer to extend with plugins helps!

@kelset

This comment has been minimized.

Copy link
Collaborator Author

kelset commented May 25, 2018

Thanks for the feedback Gant!

@GantMan

This comment has been minimized.

Copy link
Contributor

GantMan commented May 25, 2018

Let's definitely discuss. If react-native rolled out with a .solidarity file it's a few bytes. They could then optionally install solidarity and take advantage of it if they have problems. It wouldn't increase the bundle size. Or go full-awesome and bring it in as a dev dependency to work hand in hand with envinfo (which it already does).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.