Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update iOS library + Potential CI fixes #609

Merged
merged 4 commits into from Jan 11, 2020
Merged

Conversation

kristfal
Copy link
Member

Update iOS SDK to latest version.

Regenerate yarn.lock for main repo to fix CI issues with yarn and add lock file for example project.

…to fix CI issues with yarn and add lock file for example project
@kristfal
Copy link
Member Author

Closes #592

@ferdicus
Copy link
Member

ferdicus commented Jan 10, 2020

@kristfal, I actually have a question about npm vs yarn:
Why do we use two package managers to begin with?
Locally everything seems to use npm however on travis we're using yarn.

I've to admit, that I've also added to the confusion by adding yarn.lock files into the mix. 😞

@mfazekas
Copy link
Contributor

@ferdicus we're using yarn on travis as there were some caching related issues on travis with npm i was not able to solve, and could work around by going with yarn.
I think the issue was that because of npm package caching the example app used the old version of the local rnmbgl, so we was not testing the latest version but some older one. I think other alternative would have been to remove full cache of npm which was slow. But not 100% about the details.

react-native-mapbox-gl/maps@6c20c48

@kristfal
Copy link
Member Author

kristfal commented Jan 10, 2020

That pretty much summarizes the issue. I generally have less issues with yarn, so adopted it across most of my work.

Btw, I just double checked that we need to run the example repo without a yarn lock file due to sha integrity issues between published and locally build rnmgl package. This shouldn’t be an issue since the distributed build doesn’t depend on anything in the example folder.

Also removed NPM lock file to avoid confusion. I’ll add package lock to gitignore to prevent future issues/confusion with NPM and yarn.

@kristfal kristfal merged commit 5e4fb24 into master Jan 11, 2020
@ferdicus
Copy link
Member

That pretty much summarizes the issue. I generally have less issues with yarn, so adopted it across most of my work.

Btw, I just double checked that we need to run the example repo without a yarn lock file due to sha integrity issues between published and locally build rnmgl package. This shouldn’t be an issue since the distributed build doesn’t depend on anything in the example folder.

Also removed NPM lock file to avoid confusion. I’ll add package lock to gitignore to prevent future issues/confusion with NPM and yarn.

Agreed. Does this mean, that we're going to be opinionated towards yarn.
If so, I would switch uses from npm to yarn -> package.json scripts for example

@kristfal
Copy link
Member Author

It doesn’t really matter much for consumers, and not really for contributors either. Feel free to use whatever you prefer.

The most important thing is that if you use yarn, the lock file guarantees that what you install locally will be installed identical on the CI. Not using a lock file may (under very special circumstances) produce different versions of dependency installs.

@ferdicus ferdicus deleted the regenerate-yarn-lock branch October 2, 2020 15:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

An unexpected error occurred: "https://registry.yarnpkg.com/<package>: Not found"
3 participants