WatermelonDB: Doesn't work with use_frameworks! / Include of non-modular header

This solution worked for me https://github.com/react-native-maps/react-native-maps/issues/3597#issuecomment-1168582636

$static_framework = [ 
    'WatermelonDB',
      'simdjson',
  ]
  pre_install do |installer|
    Pod::Installer::Xcode::TargetValidator.send(:define_method, :verify_no_static_framework_transitive_dependencies) {}
      installer.pod_targets.each do |pod|
        if $static_framework.include?(pod.name)
          def pod.build_type;
          Pod::BuildType.static_library # >= 1.9
        end
      end
    end
  end

Update: The preferred, less complicated fix is now @johnf’s below. Note that if you’re using RN 0.71+, you’ll also need to be on at least Watermelon v0.25.1+, in order to also fix #1469 .

= = = original post for nostalgia = = =

There’s a way to get this all working with react-native-firebase and use_frameworks!. It took me a while, but here’s how to do it (@scob7).

• Follow @johnmikel 's approach above by modifying WatermelonDB.podspec. For clarity, here’s the specific edit:

diff --git a/node_modules/@nozbe/watermelondb/WatermelonDB.podspec b/node_modules/@nozbe/watermelondb/WatermelonDB.podspec
index 1f3af50..5518167 100644
--- a/node_modules/@nozbe/watermelondb/WatermelonDB.podspec
+++ b/node_modules/@nozbe/watermelondb/WatermelonDB.podspec
@@ -13,7 +13,7 @@ Pod::Spec.new do |s|
   s.platforms    = { :ios => "9.0", :tvos => "9.0" }
   s.source = { :git => "https://github.com/Nozbe/WatermelonDB.git", :tag => "v#{s.version}" }
   s.source_files = "native/ios/**/*.{h,m,mm,swift,c,cpp}", "native/shared/**/*.{h,c,cpp}"
-  s.public_header_files = 'native/ios/WatermelonDB/SupportingFiles/Bridging.h'
+  s.public_header_files = 'native/ios/**/*.h'
   s.requires_arc = true
   # simdjson is annoyingly slow without compiler optimization, disable for debugging
   s.compiler_flags = '-Os'

To save yourself the trouble of reapplying this patch every time manually, consider using something like patch-package, which will automatically apply this patch for you every time.

• Next, if you have issues with "simdjson.h" missing, follow @renatobentorocha’s instructions here: https://github.com/Nozbe/WatermelonDB/issues/1078#issuecomment-1286157927. This copies simdjson.h/cpp into WatermelonDB’s native/shared directory to avoid linking problems.
• Importantly, build now for one failure. This first build will fail, but the point is to get the pre-build step to copy the simdjson files, so it’s expected.
• Next, pod install from your project’s ios directory. This will eventually run WatermelonDB’s podspec, which you modified above, and importantly, also capture the fact that the copied simdjson.cpp needs to be linked.
• Now finally build again, for sweet, sweet success.

Sorry, I had to temporarily revert the fix, because it causes some new issues in some other configurations (possibly related to Expo and interactions with RN66)…

Forcing WatermelonDB to build as a static library as per https://github.com/Nozbe/WatermelonDB/issues/1285#issuecomment-1381323060 is currently the official/recommended way of dealing with this issue 😃

I do have another idea for a much more reliable, long-term fix, but it will take me more time to develop.

@Dallas62 Hmm, you put GitHub path in package.json? If you used 0.26.0-2, this should just work

@johnf’s fix works for me as well, and I verified by backing out my recommended changes, deleting node_modules and ios/Pods, and rebuilding everything. In my case, I had moved to RN 0.71, so also needed to upgrade to Watermelon v0.25.1 (see #1469).

I’ve edited my original comment above to now recommend @johnf’s fix instead. Thank you all!

@radex you should take a look to this one if you find some times, I know there is a lot of work in other issues, but this one could block developers at installation step.

@radex Tested it without the static workaround and it seems to work great!

@rafaellupo wow, thanks so much. I’m still on Managed Expo and I’ve just been reading through this thread starting to fret reverting to bare. I installed your plugin and swapped it out in my app.js and it worked like a charm. Appreciate you making that 👍

@fivecar @KrisLau @Dallas62 @johnf Hi, check out 0.26.0-2 prerelease. Two extra steps need to be done:

• you should now delete the Bridging.h import from your Bridging header
• in your Podfile, modify the simdjson dependency so it looks like this: pod 'simdjson', path: '../node_modules/@nozbe/simdjson', modular_headers: true

I tested on this demo project (RN 0.71) to confirm that it really works: https://github.com/radex/WatermelonDB_tester

Before I checked on 🍉’s internal project where due to different project structure the simdjson issue didn’t occur

Hi @radex, The v0.26.0-1 partially solve some imports since Bridging.h is not imported. But for simdjson.h still got an issue.

Copy and paste simdjson.h into shared folder solve the issue, but not the optimal solution.

@fivecar @KrisLau @Dallas62 @johnf Hi, check out 0.26.0-1 prerelease, I think Watermelon should work there in the use_frameworks! mode. Please note that you should now delete the Bridging.h import from your Bridging header.

Please do confirm/deny if this works for you

Yes, of course. I’m all for making 🍉 work with use_frameworks!, it’s just that I think public_header_files = everything is a workaround, not the right fix, since internal headers shouldn’t be needed for the user app. I’m very much interested in PRs fixing this once and for all

Ok so for anyone who might find themselves in a similar position, the difference for me is that I had an Expo workaround applied too so for the WatermelonDB.podspec file I had to change this:

s.public_header_files = [
  'native/ios/**/*.h',
  'native/ios/*/*.h',
]

Then I had to do step 1 & 2 only from the comment that @fivecar linked before: https://github.com/Nozbe/WatermelonDB/issues/1078#issuecomment-1286157927

Re run patch-package @nozbe/watermelondb

Cleaned the pod cache using pod cache clean --all, deleted the .xcworkspace folder, closed Xcode, pod update, reopened XCode. I had some other packages that caused issues as well but those were separate from this issue haha

@fivecar I tried following your steps but i keep running into:

Sorry to hear that, @KrisLau . I unfortunately don’t have any insight into what’s causing your specific error. I can only report what worked for me — and it took hours to get it working, and I still don’t fully have confidence it’ll hold together.

As a workaround, I run a ruby script that modifies the .podspec file of this library, changing the public headers from

/native/ios/WatermelonDB/SupportingFiles/Bridging.h/

to

native/ios/**/*.h

This ruby script is ran before doing pod install. Afterwards, proper public headers are exposed for a successful build.