-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
Comments
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?
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! |
Thanks for the feedback Gant! |
Let's definitely discuss. If react-native rolled out with a |
👋 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. |
ok I think this one can be closed |
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: React Native apps fail to build since NDK update to r17 (due to removed support for ARMv5/armeabi) react-native#19321
the Overlord rollout: some external tool gets 'force updated' / a new minimum version gets enforced and hell breaks lose.
example: React Native version mismatch (on app that was working a couple of hours ago) - Android 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:
Does this reasoning make sense?
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".
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:
The text was updated successfully, but these errors were encountered: