**fix** findComponentDescriptors should look in codegenConfig/jsSrcsDir

[mfazekas]

only and it should look into components starging with Native or ending with NativeComponent

Fixes: #2455

Summary:

findComponentDescriptors looks in all javascript files for regex codegenNativeComponent.... And android build uses that for autolinking.

Note that this is not 100% solution, as we still use regex parsing instead of parsing typescript and we also duplicate the logic from codegen. A better solution could be using codegen schema to parse for components.

Test Plan:

git clone https://github.com/mfazekas/rn-075-autolink
cd rn-075-autolink
git checkout autolink-wrong-files
cd ReproducerApp

node $RNCLI/packages/cli/build/bin.js config | grep componentDescriptors -A 3
          "componentDescriptors": [
            "RTNCenteredTextComponentDescriptor"
          ],

Works with .android platform extension

mv ../RTNCenteredText/js/RTNCenteredTextNativeComponent.ts ../RTNCenteredText/js/RTNCenteredTextNativeComponent.android.ts
node $RNCLI/packages/cli/build/bin.js config | grep componentDescriptors -A 3
          "componentDescriptors": [
            "RTNCenteredTextComponentDescriptor"
          ],

File matching Native*

echo 'codegenNativeComponent<NativeProps>("Foo")' > ../RTNCenteredText/js/NativeFoo.jsx
node $RNCLI/packages/cli/build/bin.js config | grep componentDescriptors -A 3
          "componentDescriptors": [
            "FooComponentDescriptor",
            "RTNCenteredTextComponentDescriptor"
          ],

File not matching Native* or NativeComponent

echo 'codegenNativeComponent<NativeProps>("Bar")' > ../RTNCenteredText/js/_Bar.jsx
node $RNCLI/packages/cli/build/bin.js config | grep componentDescriptors -A 3
          "componentDescriptors": [
            "FooComponentDescriptor",
            "RTNCenteredTextComponentDescriptor"
          ],

Checklist

[cortinico]

only and it should look into components starging with Native or ending with NativeComponent

I believe that's not a correct fix. In theory users could device to don't use codegen (so you won't have codegenConfig/jsSrcsDir at all) but still have component descriptors that needs to be linked against

[mfazekas]

I believe that's not a correct fix. In theory users could device to don't use codegen (so you won't have codegenConfig/jsSrcsDir at all) but still have component descriptors that needs to be linked against

Thanks for looking into it.

So the use case I've faced was that I've had a spec which I hasn't finished, so I've moved it away into temp/TODOComponent.ts. But auto linking was picking it up, which I've assumed must have been some stale cache from previous runs so it took me a while to figure out what's going on.

Another issue is an iOS only component - like src/specs/AppleOnlyNativceComponent.ios.ts will be picked up by auto link.

I'm not sure about the use case you've mentioned, where there is no codegen used, yet user want autolink to be generated. Based on javascript code spec. I guess one would need to create Specs.h or similar on its own. This change could definitely break such use cases.

https://github.com/react-native-community/cli/blob/main/docs/autolinking.md

So some of the possible steps:
1.) Improve only docs to describe what's going on
2.) Ignore files with .ios extension only
3.) only restrict the search to codegenConfig/jsSrcsDir if that's defined. So there is codegen config.

What do you think?

[cortinico]

I'm not sure about the use case you've mentioned, where there is no codegen used, yet user want autolink to be generated. Based on javascript code spec. I guess one would need to create Specs.h or similar on its own. This change could definitely break such use cases.

You can always provide your own react-native.config.js and circumvent this logic alltoghether

[github-actions]

There hasn't been any activity on this pull request in the past 3 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 7 days.