"Breaking - remove unused registration of JS modules" really breaks stuff

Is this a bug report?

no. but as already discussd below this can lead to mayn bug reports in downstream projects

Have you read the Bugs section of the How to Contribute guide?

yes

Environment

1. react-native -v: v0.47.0-rc.5
2. node -v: v7.0.0
3. npm -v: 3.10.9

• Target Platform: Android
• Development Operating System: Win 10
• Build tools: command line

Steps to Reproduce

Create a RN 0.47rc-5 project that uses https://github.com/ideacreation/react-native-barcodescanner or one of many other 3rd-party libs. Try to compile and run.

Expected Behavior

App will run as in 0.46

Actual Behavior

Compile error.

D:\Work\835a948d\0\products\msu.Reading\node_modules\react-native-barcodescanner\android\src\main\java\com\eguma\barcodescanner\BarcodeScannerPackage.java:20: error: method does not override or implement a method from a supertype
    @Override
    ^
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
1 error
:react-native-barcodescanner:compileReleaseJavaWithJavac FAILED

FAILURE: Build failed with an exception.

Background

In https://github.com/facebook/react-native/commit/ce6fb337a146e6f261f2afb564aa19363774a7a8 @javache removed the JS registration because it’s now unnecessary. The issue is that a lot of the RN third-party components now need recompilation or just break (see https://github.com/ideacreation/react-native-barcodescanner/issues/79 for one example but quick google search shows more). That alone is not a problem but some components didn’t have updates dor a long time and maybe authors are hard to reach.

The question is: Is this really needed? What if we keep the abstract method is still there and just doesn’t call anymore. Then components wouldn’t need to recompile, right? This could save a lot of trouble in the ecosystem.

[ujwal-setlur]

It is unfortunate that this has to be done in a breaking manner.A lot of third party packages are affected. I understand the technical issue, and while I don’t want to come across whining, it does seem that every release of react-native has some issue or another that prevents upgrading. 0.46 for example was unbuildable on iOS devices in the first release. Now this. It does create quite a bit of friction in the developer experience unfortunately 😦

These days, I dread doing a react-native upgrade…

[ujwal-setlur]

@hramos, I understand the challenges. I really love react-native and want to see it get even more awesome. Some thoughts:

1. I think you guys need to have a more formal ecosystem partnership with third party package providers so that they understand what’s coming down the pipe. A lot of packages are slow to catch up to changes to react-native interfaces. For example, your own react-native-fbsdk oAuth module itself had not caught up with this change. I had to pull from master. If this mechanism is already in place, it needs to get better.

2. Some packages seem just abandoned, things that are quite critical to a modern app. This is the dark side of open source. A proliferation of forks come about because the package maintainer is MIA. I myself have forked a few because I needed critical fixes. I don’t know what the solution to this is, but maybe Facebook can take more ownership of some critical native modules.

3. All the issues that I found, Facebook should have found too given that you consume this for your apps. I have been been regularly upgrading to official releases, but have stayed away from rc-releases. I am building a production app and am nervous about switching to non official releases, but I am willing to try on some of myth other projects.

All in all, I want my developer experience to improve, and I am willing to help. I now have modified my build system by creating a script that patches third party boo-boos post npm install 😃