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

Closed
kelset opened this issue May 23, 2018 · 5 comments
Closed

React Native and tooling: a round up #370

kelset opened this issue May 23, 2018 · 5 comments
Labels
Stale Issues/PR that are not getting much activity and are closer to be closed

Comments

@kelset
Copy link
Contributor

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:

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
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
Copy link
Contributor Author

kelset commented May 25, 2018

Thanks for the feedback Gant!

@GantMan
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).

@stale
Copy link

stale bot commented Aug 16, 2020

👋 Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the Stale Issues/PR that are not getting much activity and are closer to be closed label Aug 16, 2020
@kelset
Copy link
Contributor Author

kelset commented Aug 17, 2020

ok I think this one can be closed

@kelset kelset closed this as completed Aug 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Stale Issues/PR that are not getting much activity and are closer to be closed
Projects
None yet
Development

No branches or pull requests

2 participants