Feature react native tracer provider

[jpmunz]

Feature branch for the react-native-tracer-provider package

Before merging:

• make sure the package versions in this PR match main
• add to packages list on README.md

After merging:

• create a release branch and release a 5.x version of this tracer provider package

[codecov]

Codecov Report

Attention: Patch coverage is 88.31169% with 27 lines in your changes missing coverage. Please review.

Project coverage is 80.36%. Comparing base (fb82075) to head (02aa89e).

Files with missing lines	Patch %	Lines
...-native-tracer-provider/src/StackContextManager.ts	51.51%	16 Missing ⚠️
...-native-tracer-provider/src/EmbraceNativeTracer.ts	89.47%	4 Missing ⚠️
...native-tracer-provider/src/TracerProviderModule.ts	50.00%	3 Missing and 1 partial ⚠️
...ct-native-tracer-provider/src/EmbraceNativeSpan.ts	97.36%	2 Missing ⚠️
packages/react-native-tracer-provider/src/util.ts	95.23%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #53      +/-   ##
==========================================
+ Coverage   78.95%   80.36%   +1.40%     
==========================================
  Files          29       36       +7     
  Lines        1307     1538     +231     
  Branches      113      142      +29     
==========================================
+ Hits         1032     1236     +204     
- Misses        275      301      +26     
- Partials        0        1       +1     

Files with missing lines	Coverage Δ
...tracer-provider/src/EmbraceNativeTracerProvider.ts	100.00% <100.00%> (ø)
packages/react-native-tracer-provider/src/index.ts	100.00% <100.00%> (ø)
packages/react-native-tracer-provider/src/util.ts	95.23% <95.23%> (ø)
...ct-native-tracer-provider/src/EmbraceNativeSpan.ts	97.36% <97.36%> (ø)
...-native-tracer-provider/src/EmbraceNativeTracer.ts	89.47% <89.47%> (ø)
...native-tracer-provider/src/TracerProviderModule.ts	50.00% <50.00%> (ø)
...-native-tracer-provider/src/StackContextManager.ts	51.51% <51.51%> (ø)

[github-actions]

Dependency Review

The following issues were found:

• ❌ 6 vulnerable package(s)
• ✅ 0 package(s) with incompatible licenses
• ✅ 0 package(s) with invalid SPDX license definitions
• ⚠️ 2 package(s) with unknown licenses.
• ⚠️ 41 packages with OpenSSF Scorecard issues.

View full job summary

[facostaembrace]

is there a reason why we need a prefix here? TracerProvider_

[jpmunz]

I had copied and pasted this from another example, I believe the reasoning is to distinguish it from another "kotlinVersion" property that may have been defined by the app that uses this package, e.g. in packages/react-native-tracer-provider/android/build.gradle we have:

def kotlin_version = rootProject.ext.has("kotlinVersion") ? rootProject.ext.get("kotlinVersion") : project.properties["TracerProvider_kotlinVersion"]

So we use a bare "kotlinVersion" property if it's available and then only fallback to this "TracerProvider_kotlinVersion" if it's not

[facostaembrace]

do we want to update this version manually here in the future?

[jpmunz]

this ends up getting rewritten by the update_android_version.ts script

[facostaembrace]

maybe we can cleanup all these files, I think everything into this mipmap-hdpi was auto generated, right?

[jpmunz]

yep they were all created when I initialized the react native app, I can double-check what happens if I delete the folder, not sure if any are required

[jpmunz]

looks like most aren't required, deleted

[facostaembrace]

in my react-native-otlp package I ended up creating a file called RNEmbraceOTLP.podspec. maybe we can agree on a naming convention for this type of files

[jpmunz]

ya let's discuss this one a bit more, I when with the react-native-tracer-provider.podspec to better match the package name though since we have RNEmbrace.podspec in core it is a bit inconsistent

[facostaembrace]

can we move the hook into a different place? as per the name of this file (EmbraceNativeTracerProvider) I though I was going to see only a class but it is also containing the hook. I would suggest to move the hook to its own place useEmbraceNativeTracerProvider

[jpmunz]

makes sense, moved to its own useEmbraceNativeTracerProvider.ts file

[facostaembrace]

can we remove the Use prefix from the name for this interface?

[jpmunz]

I wasn't sure about the convention here, this is the type of the return value of useEmbraceNativeTracerProvider so I was naming it to match, what do you think?