search

react-native-community / releases

React Native releases
https://github.com/facebook/react-native/
1.5k stars 405 forks source link

v0.63.0 Discussion #186

Closed TheSavior closed 4 years ago

TheSavior commented 4 years ago

Highlighted Changes

Work Required

Click to expand! - [x] facebook/react-native#28776 - [x] Fix [`scrollResponderScrollNativeHandleToKeyboard` warnings](https://github.com/facebook/react-native/issues/28203#issuecomment-592973087). Fix [here](https://github.com/facebook/react-native/commit/3246f68952c8fe065367ef8d2cdf7da5dfff78e4) - [x] [A new Image Prop `analyticTag` was accidentally landed. This needs to get prefixed as `internal`](https://github.com/facebook/react-native/commit/1c10568967231cce2be01d2341f4edb79d57ec48) @dvacca. Fix [here](https://github.com/facebook/react-native/commit/8e48dc0555e0c3432a77d421b1e535d17f5933c8) - [x] [Android doesn't build due to missing `cliPath`](https://github.com/facebook/react-native/issues/28466) - [x] [Android doesn't build due to incorrect Kotlin version](https://github.com/facebook/react-native/pull/28626)

Non-Blocking

Click to expand! - [x] Bump Flipper to v0.41 - [x] Documentation for Pressable @kikisaints / @rachelnabors - [x] Rename Pressable `pressRectOffset` prop to `pressRetentionOffset`. @TheSavior - [x] [Make sure PlatformColor ESLint rule is enabled on new projects](https://github.com/facebook/react-native/commit/602070f44b02220aeb036a7b3c26dad5c611b636) (might require publishing a new package) - [x] [Remove ColorAndroid method](https://github.com/facebook/react-native-website/pull/1813#issuecomment-609962877) @tom-un - [x] [Documentation for PlatformColor](https://github.com/facebook/react-native-website/pull/1813) @kikisaints / @rachelnabors - [x] [Documentation for DynamicColorIOS](https://github.com/facebook/react-native-website/pull/1813) @kikisaints / @rachelnabors - [x] [Fix Pressable's Android ripple with `borderless`](https://github.com/facebook/react-native/pull/28526) @vonovak. Fix [here](https://github.com/facebook/react-native/commit/44ec762e41029bf43530b1ff9b36ca3512c526e2) - [x] [Fix Podfile paths to React Native in monorepos and non-standard structures](https://github.com/facebook/react-native/pull/28572) @grabbou - [x] Ensure Hermes is on 0.5.0 @willholen (https://github.com/facebook/react-native/commit/4305a291a94) - [x] Cherry-pick [Podfile cleanup](https://github.com/facebook/react-native/pull/28651#issuecomment-614663967) - [x] Allow iOS PlatformColor strings to be ObjC or Swift UIColor selectors https://github.com/facebook/react-native/commit/25793eab56217a9961620761ea65ec2fcb97dcb0 - [x] facebook/react-native@d06ee3d

Hopeful Dates

We can never commit to the dates involved in a release as many things are out of our control. However, we are thinking about these rough dates for this release.

TheSavior commented 4 years ago

@danielgindi, as that PR hasn't landed, it won't be a part of 0.63.

gaodeng commented 4 years ago

react native 0.63.0-rc.1 enableHermes: true, As soon as bluebird is imported, an unknown error occurs https://github.com/facebook/hermes/issues/241

danielgindi commented 4 years ago

@gaodeng bluebird should not be used anymore, as Promise is native to any modern ES engine. on the other hand, hermes is a crippled engine, and probably does not follow the spec, so bluebird's Promise-like objects probably confuses it. You could switch to v8 engine, at least for Android, to get better performance. I got no idea why are they promoting hermes.

TheSavior commented 4 years ago

@danielgindi, as far as is known, Hermes is spec compliant on the features that it implements. It verifies against the same spec test suite as other engines. Any non compliance is a bug that should be reported to the Hermes repo.

As for Hermes being slower than V8, these are the results of some experiments Microsoft ran comparing V8 against Hermes on one of their production apps. On all of these metrics Hermes outperforms v8.

66255648_893501134346100_8745316183667900416_n

Here is a comment from @acoates-ms on that topic who works on Office: https://news.ycombinator.com/item?id=20413046

We are "pushing" Hermes because it helps people get a better user experience from applications using React Native.

danielgindi commented 4 years ago

@TheSavior

Hermes is spec compliant on the features that it implements. It verifies against the same spec test suite as other engines. Any non compliance is a bug that should be reported to the Hermes repo. Then there might be a bug with Promises there. Also when Hermes was first paired with RN, there was a lot of talk about so many ES features not supported, so babel is needed to bloat everything.

Also - how is that size reasonable if it's spec compliant, and let's say - supports Intl?.. Apps these days need Intl as everything is global now.

As for Hermes being slower than V8, these are the results of some experiments Microsoft ran comparing V8 against Hermes on one of their production apps. On all of these metrics Hermes outperforms v8.

Have you seen these benchmarks? https://github.com/Kudo/react-native-js-benchmark https://docs.google.com/spreadsheets/d/1uce3WZ9IaAEUu6Owj3eXEuZb25PDi6ZcgUVV2i500S0/edit#gid=1258377944

https://medium.com/walmartlabs/react-native-memory-profiling-jsc-vs-v8-vs-hermes-1626949a653b

It's not only about having a smaller footprint or 10ms less in boot. It's about the runtime itself that should be faster and consume less memory.

TheSavior commented 4 years ago

This isn't the place for this conversation. This thread is specifically focused on the release process for 0.63. If you have additional questions about Hermes and the things it supports, an issue on the Hermes repo is a good choice.

TheSavior commented 4 years ago

@rachelnabors noticed that the Pressable prop pressRectOffset isn't consistent with other touchables. I'm making a change to rename that prop and we should pick that change once it lands.

Edit: This has landed in https://github.com/facebook/react-native/commit/66103277d289da5ab2c68389b56327316e69dcb3

fkgozali commented 4 years ago

Might want to pick https://github.com/facebook/react-native/commit/e5a6655e71d41a58ce0e51d37aa9fb8792e37dd5, that should fix long-standing iOS crashes: https://github.com/facebook/react-native/issues/27463

TheSavior commented 4 years ago

I think we should pick https://github.com/facebook/react-native/commit/8ac467c51b94c82d81930b4802b2978c85539925 as well. We forgot to make Pressable have the same debug helper as the existing Touchables.

rachelnabors commented 4 years ago

Docs are ready to be cut. We have Pressable and DynamicColors ready to go!

peter-mach commented 4 years ago

For me upgrading to the latest release (0.63.0-rc.1) with Podfile cleanup approach resulted in adding user specific, absolute paths to RN modules in Podfile.lock instead of relative ones.

Does anyone experience this behavior?

So instead of

React-Core (from `../node_modules/react-native/`)

I get

React-Core (from `/Users/pmachowski/Work/Mobile/Project/node_modules/react-native/`)
grabbou commented 4 years ago

Just heads up - I am back from holidays and looking into the state of the release. I will be back with updates.

grabbou commented 4 years ago

All commits cherry-picked. Working on the release now.

pvinis commented 4 years ago

@pmachowski would you mind telling us how did you upgrade, and where did you see these paths? thank you.

peter-mach commented 4 years ago

@pvinis Sure. I've upgraded using the React Native Upgrade Helper. But you can reproduce the issue with clean install: npx react-native init ProjectName --version 0.63.0-rc.1. Absolute paths are located in ProjectName/ios/Podfile.lock

cc/ @grabbou

danielgindi commented 4 years ago

@pmachowski I think that cocoapods version is relevant here

lukebars commented 4 years ago

@danielgindi I was able to reproduce absolute paths in Podfile.lock with COCOAPODS: 1.9.1, same goes with 1.9.2

grabbou commented 4 years ago

We're working on the changelog/blog post now, the release is ready from the code perspective. The ETA is next Monday/Tuesday.

The original issue has been updated to reflect the date.

alloy commented 4 years ago

@grabbou With a new v0.63.0-rc.1 application and using CocoaPods v1.8.4 I can reproduce the same absolute path issue. Did the way we provide the paths to the podspecs change?

peter-mach commented 4 years ago

@danielgindi @pvinis For me the Cocoapods version affected is 1.9.2

alexwasner commented 4 years ago

Looks like the release is right around the corner, but I upgraded to from 62.2 to rc1 and all my tests are failing. 

 FAIL  __tests__/Menu.test.tsx
  ● Test suite failed to run
    TypeError: Cannot convert undefined or null to object
        at assign (<anonymous>)
      at _extends (node_modules/@babel/runtime/helpers/extends.js:16:19)
      at node_modules/@testing-library/react-native/dist/preset/mock-modules.js:41:25
      at Object.require (node_modules/react-native/Libraries/Image/Image.ios.js:15:21)

I have upgraded all of the jest and babel versions from the helper. Any insight into the specifics around the jest updates?

TheSavior commented 4 years ago

@alexwasner, the changelog (in progress) is here: https://github.com/react-native-community/releases/pull/198 You can see the changes from Jest in there. There isn't enough information here to debug your problem so it is hard to tell. I'd recommend trying to create repro in a new project on 0.63.0-rc1 to narrow it down and create a new issue on the main React Native repo with that info.

nonewcode commented 4 years ago

With the cleanup of the podfile in 0.63.0, how would one pass an updated version number through to use_flipper!? I think currently RN uses 0.33 but flipper is at 0.44.1 right now.

kelset commented 4 years ago

@codecog I'm not sure if that's the case, but my guess would be that it's the same thing that happens with the React and Flow versions: they are "bound" to that version of React Native, so you shouldn't upgrade to latest unless RN explicitly supports it.

That said, probably cocoapods has some resolution mechanism if you were to define the Pod for flipper anyway in your podfile? (again, not sure)

alexwasner commented 4 years ago

Per my testing issue, I've narrowed it down to @testing-library/react-native and have replaced it with react-native-testing-library for now. For any future dev reading this, I've opened a ticket with them with an example repo if you'd like to follow along. I can also open one with RN core if that'd be helpful

nicoburns commented 4 years ago

With the cleanup of the podfile in 0.63.0, how would one pass an updated version number through to use_flipper!? I think currently RN uses 0.33 but flipper is at 0.44.1 right now.

A related question: we currently have multiple "debug" configurations (one for our production environment, one for our dev environment). We had to alter our Podfile like so:

project 'marketplace',
  'Dev.Debug' => :debug,
  'Dev.Release' => :release,
  'Prod.Debug' => :debug,
  'Prod.Release' => :release

def add_flipper_pods!(versions = {})
  versions['Flipper'] ||= '~> 0.33.1'
  versions['DoubleConversion'] ||= '1.1.7'
  versions['Flipper-Folly'] ||= '~> 2.1'
  versions['Flipper-Glog'] ||= '0.3.6'
  versions['Flipper-PeerTalk'] ||= '~> 0.0.4'
  versions['Flipper-RSocket'] ||= '~> 1.0'
  pod 'FlipperKit', versions['Flipper'], :configurations => ['Dev.Debug', 'Prod.Debug']
  pod 'FlipperKit/FlipperKitLayoutPlugin', versions['Flipper'], :configurations => ['Dev.Debug', 'Prod.Debug']
  pod 'FlipperKit/SKIOSNetworkPlugin', versions['Flipper'], :configurations => ['Dev.Debug', 'Prod.Debug']
  pod 'FlipperKit/FlipperKitUserDefaultsPlugin', versions['Flipper'], :configurations => ['Dev.Debug', 'Prod.Debug']
  pod 'FlipperKit/FlipperKitReactPlugin', versions['Flipper'], :configurations => ['Dev.Debug', 'Prod.Debug']
  # List all transitive dependencies for FlipperKit pods
  # to avoid them being linked in Release builds
  pod 'Flipper', versions['Flipper'], :configurations => ['Dev.Debug', 'Prod.Debug']
  pod 'Flipper-DoubleConversion', versions['DoubleConversion'], :configurations => ['Dev.Debug', 'Prod.Debug']
  pod 'Flipper-Folly', versions['Flipper-Folly'], :configurations => ['Dev.Debug', 'Prod.Debug']
  pod 'Flipper-Glog', versions['Flipper-Glog'], :configurations => ['Dev.Debug', 'Prod.Debug']
  pod 'Flipper-PeerTalk', versions['Flipper-PeerTalk'], :configurations => ['Dev.Debug', 'Prod.Debug']
  pod 'Flipper-RSocket', versions['Flipper-RSocket'], :configurations => ['Dev.Debug', 'Prod.Debug']
  pod 'FlipperKit/Core', versions['Flipper'], :configurations => ['Dev.Debug', 'Prod.Debug']
  pod 'FlipperKit/CppBridge', versions['Flipper'], :configurations => ['Dev.Debug', 'Prod.Debug']
  pod 'FlipperKit/FBCxxFollyDynamicConvert', versions['Flipper'], :configurations => ['Dev.Debug', 'Prod.Debug']
  pod 'FlipperKit/FBDefines', versions['Flipper'], :configurations => ['Dev.Debug', 'Prod.Debug']
  pod 'FlipperKit/FKPortForwarding', versions['Flipper'], :configurations => ['Dev.Debug', 'Prod.Debug']
  pod 'FlipperKit/FlipperKitHighlightOverlay', versions['Flipper'], :configurations => ['Dev.Debug', 'Prod.Debug']
  pod 'FlipperKit/FlipperKitLayoutTextSearchable', versions['Flipper'], :configurations => ['Dev.Debug', 'Prod.Debug']
  pod 'FlipperKit/FlipperKitNetworkPlugin', versions['Flipper'], :configurations => ['Dev.Debug', 'Prod.Debug']
end
# Post Install processing for Flipper
def flipper_post_install(installer)
  installer.pods_project.targets.each do |target|
    if target.name == 'YogaKit'
      target.build_configurations.each do |config|
        config.build_settings['SWIFT_VERSION'] = '4.1'
      end
    end
  end
end

Is there a way to set up custom configurations like this with use_flipper!?

alloy commented 4 years ago

@nicoburns Adding an additional parameter to use_flipper! that takes a list of configurations and defaults to just Debug seems like a good change to me 👍 Please send a PR for that 🙏

nicoburns commented 4 years ago

@alloy PR here https://github.com/facebook/react-native/pull/29074. Allows:

use_flipper!(configurations: ['Dev.Debug', 'Prod.Debug'])

@codecog I'm not sure how advisable it is to use a non-sanctioned version of Flipper, but it looks like use_flipper! does have a version parameter which you can use like so:

use_flipper!({
    'Flipper' ='~> 0.41.1',
    'Flipper-DoubleConversion' = '1.1.7',
    'Flipper-Folly' = '~> 2.2',
    'Flipper-Glog' = '0.3.6',
    'Flipper-PeerTalk' = '~> 0.0.4',
    'Flipper-RSocket' = '~> 1.1'
});
TheSavior commented 4 years ago

@alloy Is the issue in the pod lockfiles with absolute paths a launch blocker?

grabbou commented 4 years ago

@TheSavior, my understanding is that this is not an issue as it affects paths in a lockfile generated on a post-install. But I'd love confirmation from @alloy just to make sure I am not getting something wrong.

lukebars commented 4 years ago

@grabbou Wouldn't it result in Podfile.lock changes every time someone else installs pods, even if Pods aren't changed? I would imagine that being quite an issue for PR's and commits on bigger projects.

TheSavior commented 4 years ago

Yeah, it seems like you wouldn’t be able to check in a lock file for a team for example

Ashoat commented 4 years ago

Wanted to chime in that I do believe this issue should be launch-blocking. cocoapods recommends checking in the Podfile.lock, similar to how yarn.lock works.

nonewcode commented 4 years ago

Is there anything on v0.63.0 that I could potentially help with to get it closer to release?

kesha-antonov commented 4 years ago

How to use relative paths in Podfile:

use_native_modules!
use_react_native!(path: '../node_modules/react-native')

I hope this helps to push the release

Not like this:

config = use_native_modules!
use_react_native!(:path => config["reactNativePath"])

Seems like simple issue

grabbou commented 4 years ago

@kesha-antonov going to address that within CLI soon and cherry-pick to 0.63.

grabbou commented 4 years ago

Update: Together with the React Native team at Facebook, we have decided that last week was not the right timing for a stable React Native release. We want to step back and make space for more important voices to be heard.

I will update this issue when the new date is set at a more appropriate time.

In the meantime, we encourage you to visit https://blacklivesmatter.com/ and learn more about how you can help.

reimertz commented 4 years ago

Thanks @grabbou for the hard work and agreed regarding the timing. <3

heroic commented 4 years ago

Not sure who has issues with the delay of the release. Is there something more important?

raajnadar commented 4 years ago

Delay in release = more tests = less bugs

Gustash commented 4 years ago

Can we cherry-pick https://github.com/facebook/react-native/pull/29072?

This fixes a security issue on a dependency from react-native-cli.

nelsonprsousa commented 4 years ago

Can we cherry-pick facebook/react-native#29072?

This fixes a security issue on a dependency from react-native-cli.

I am using 0.62.2 and got rid of that security issue by deleting yarn.lock and run yarn again. 0.7.1 seems to be compatible and it's working as expected.

Gustash commented 4 years ago

Can we cherry-pick facebook/react-native#29072?

This fixes a security issue on a dependency from react-native-cli.

I am using 0.62.2 and got rid of that security issue by deleting yarn.lock and run yarn again. 0.7.1 seems to be compatible and it's working as expected.

Yeah mate, I'm sorry but deleting a lock file really isn't an ideal solution. There's a reason they exist

Bardiamist commented 4 years ago

@Gustash You can delete yarn.lock only once. Then yarn will create new yarn.lock with latest @react-native-community/cli (4.10.0)

Gustash commented 4 years ago

@Gustash You can delete yarn.lock only once. Then yarn will create new yarn.lock with latest @react-native-community/cli (4.10.0)

The problem isn't that the lock file won't regenerate, it's that it'll literally bring the latest version of all your dependencies, and you can't trust all of them to not have breaking changes.

Therefore, for big projects, deleting a lock file is a big no-no

kelset commented 4 years ago

 @Gustash while in line of principle, yes, you shouldn't remove a yarn.lock, there are actually 2 different work arounds that won't require the cherry pick (that said I think it should be cherry picked).

  1. go in the yarn lock and delete manually only the entries around rn-cli (the 4 packages indicated above), then do a yarn and it will pull down the latest 4.x

  2. use yarn resolutions to set the RN-cli dependencies to the desired version.

Gustash commented 4 years ago

@kelset do those versions of the cli work properly with 0.62.2? I'm weary of using cli versions not set by RN because I've had build issues before

kelset commented 4 years ago

@Gustash since the commit you propose to cherry pick is from 4.7 to 4.10 I'd say it's safe to "manually upgrade" those packs on the side anyway. The release notes don't indicate any breaking changes / minimum version either.

Gustash commented 4 years ago

Thanks @kelset, that's a much more sensible solution.

I would still argue for cherry-picking this though

grabbou commented 4 years ago

Fix for the Podfile.lock paths issue (based on @kesha-antonov workaround) is here: https://github.com/react-native-community/cli/pull/1203

CC: @alloy