Fix new codegen API disabling behaviour of the old one

[kkafar]

Summary:

Hey, I'm bumping react-native-screens to 0.80.0-rc.4 right now & noticed that codegen does not work as expected. It crawls whole library, file by file (when working on a library it also includes nodemodules etc), despite componentProvider field being defined in codegenConfig in package.json.

Namely #49941 introduced a regression for libraries that stick to the old codegen config format due to compatibility reasons. Take a look at this code. We first do a pass for "old API", removing libraries with componentProvider in their codegen config from librariesToCrawl, just to later add ALL libraries that do not support new codegen config format back again to librariesToCrawl.

This PR improves the filtering condition, to parse codegen annotations only for libraries that have defined any of the fields from the new config format (opted in for new system).

I want to emphasise that this is a significant regression, because it ruins experience of library maintenance, vastly increasing pods installation time.

Changelog:

[IOS] [FIXED] - Fix codegen crawling all library code with componentProvider defined in config

Test Plan:

1. Setup an application with any third party library, that uses "old" codegen config format, e.g. [email protected]
2. cd ios && bundle exec pod install
3. Observe the codegen logs - it crawles the library instead of using provided information.

[cortinico]

I believe this same issue is already addressed by reactwg/react-native-releases#974 (and linked PR). RC5 should fix this issue for react-native-screens

[kkafar]

That's great then, thanks for the heads up

[kkafar]

Edit: just checked the PR you linked - I believe these to be separate issues

[cipolleschi]

Yeah, those are separate issues. I think the code makes sense.

If you can fix the js_test red signal and set it as ready to be reviewed, I can import and land it.

[kkafar]

I'm not convinced of this code yet, I've opened the PR a bit prematurely.

At the moment I've managed to work around this issue (prevent codegen from crawling) by duplicating component descriptions in my codegen config

This PR in current state not only fixes the issue of overeager crawling, but also changes the behaviour. If this is merged then the library can either use old API or new API - they can not be mixed. Current implementation allows for mixing these two APIs (exactly what I've done in the commit ☝️)

The ability to mix these is kinda nice, because it'll allow us to keep the backward compat a bit longer in case the "old config" is removed in 0.81 or 0.82

The golden solution here would be to allow for mixing, but also avoid crawling.

So my proposal is as follows:

1. detect whether new API is in usage, is so ignore "old" fields if present,
2. if there are no new API fields in usage, try to look for "old" fields
3. if there are no "old" & no "new" fields - only then crawl.

I'll rewrite this in couple of minutes

[cipolleschi]

thanks for being thorough.

At the moment I've managed to work around this issue (prevent codegen from crawling) by duplicating component descriptions in my codegen config

This is actually the right fix, with the new API and the proper way to declare which native components the library exposes.

But to keep backward compatibility, we should fix codegen.

[kkafar]

@cipolleschi I've updated the code & snapshots

Now:

👉🏻 If the componentLibrary uses new api or does not specify anything it
is processed in a new way.

👉🏻 Otherwise (when it specifies only old API fields) it is considered to
use old API.

[cipolleschi]

amazing, thanks for fixing this and also for working on the tests!

[facebook-github-bot]

@cipolleschi has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

[facebook-github-bot]

@cipolleschi merged this pull request in 65aa819.

[react-native-bot]

This pull request was successfully merged by @kkafar in 65aa819

^{When will my fix make it into a release? | How to file a pick request?}

[react-native-bot]

This pull request was successfully merged by @kkafar in 4b65d0e

^{When will my fix make it into a release? | How to file a pick request?}