duplicate symbol _OBJC_IVAR_$_SSZipArchive._zip in:

[chirag04]

I get the above issue when configuring codepush. We are also using https://github.com/plrthink/react-native-zip-archive which also rely on SSZipArchive.

cc @lostintangent

[geof90]

Hi @chirag04 (and anyone else who could be hitting this issue),

The full workaround is to

1. Delete SSZipArchive from the CodePush library project
   
2. Update the Header Search Paths of the CodePush library project to point at the version of SSZipArchive that is bundled together with the react-native-zip-archive plugin.
   

Closing this, feel free to reopen if this does not work for you.

[chirag04]

@geof90 well this work but everytime i npm install i would need to delete the folder and set the path again. Can we do one time setup?

[geof90]

@chirag04 Sorry for the late reply, I somehow missed this. The best way I see to prevent having the manual deletion step is to make a fork of our project, delete the folder in that fork, and then specify your fork's github URL as a dependency in your package.json.

[cancan101]

This solution seems less than ideal. Why does this project need to vendor SSZipArchive? Is there no way to handle this dependency in a smarter fashion that does not conflict with other npm packages?

ie some equivalent of NoZip.

[lostintangent]

@cancan101 It's definitely non-ideal. Unfortunately, react-native-zip-archive also bundles a copy of SSZipArchive with it, so we couldn't easily share a common dependency from CocoaPods/etc. with that package, if both it and CodePush were installed.

Which NPM package is creating the conflict for you? Are you also trying to use react-native-zip-archive? I'll give some thought to this issue today since I agree it needs to be addressed.

[cancan101]

Yes, am trying to use react-native-zip-archive and I do see they are vendoring as well. I suppose you are both doing so to solve the problem of dependency management in the case where the user is not using Cocoapods.

The reason that I don't want to install react-native-code-push using cocoapods is the requirement to then install RN using cocoapods which I do not want to do.

[plrthink]

I'm the author of react-native-zip-archive. I'm also facing this problem today since we are integrating CodePush to our own app.

Honestly, I'm not familiar with native development and I don't know how cocoapod solve this dependency so is there anything I can do with that? I'm so willing to fix this with codepush team.

[itinance]

From the codepush-docs:

CodePush depends on an internal copy of the SSZipArchive library, so if your project already includes it (either directly or via a transitive dependency), then you can install a version of CodePush which excludes it by depending specifically on the Core subspec:

pod 'CodePush', :path => './node_modules/react-native-code-push', :subspecs => ['Core']
NOTE: The above paths needs to be relative to your app’s Podfile, so adjust it as nec cessary.

Have you tried this out?

[plrthink]

@itinance I haven't tried that approach yet. But I think not every rn users use cocoapod, so I still want to try some other solutions.

My colleague told me that since the linker in xcode identifies code by its class names so I changed the class name of SSZipArchive to RNSSZipArchive and this solved the problem. But it still not a perfect way to do that.

If any user is facing the same issue then you can install react-native-zip-archive via github with custom-ssziparchive branch now.

Still trying to find a better solution...

[RoosterKelly]

@geof90 This is still a significant problem. Is there yet a good solution that does not require constant management of this package just so it does not conflict with other react native modules?
Solutions found so far:

Delete the SSZipArchive and update the search path, which gets overwritten on ever npm install

Create fork, do your own builds. When keep track of updates to parent get and merge changes any time you need them.

Both solutions incur significant cost on any team that runs into this issue.

@plrthink Have you had any success on finding a work around on your end?

[plrthink]

@RoosterKelly I have just pushed the next branch which should fix this issue. You can install it via "react-native-zip-archive": "mockingbot/react-native-zip-archive#next" to test it out. If it works on your side, I would publish a version to npm ASAP