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

Adding more commands #50

Open
mralj opened this issue Mar 8, 2021 · 2 comments
Open

Adding more commands #50

mralj opened this issue Mar 8, 2021 · 2 comments

Comments

@mralj
Copy link

mralj commented Mar 8, 2021

Hi,

Internally we have a couple of scripts for cleaning RN projects, and since we were not aware of this project, I mentioned those scripts in react-native-community/releases (link), where it was suggested to me that I should add some of those here :)

Here is C/P of what we are using:

{
    "clear-cache": "npm run clear-xcode-cache && watchman watch-del-all && rm -rf $TMPDIR/react-* && npm cache verify && rm -rf node_modules/ && npm run clear-npm-pod-cache && rm -rf ios/build/ && cd android && ./gradlew clean && cd .. && npm run start-no-cache",
    "clear-xcode-cache": "cd ios && bash ../resetXcode.sh && cd ..",
    "clear-npm-pod-cache": "rm -rf ios/Podfile.lock && rm -rf package-lock.json && npm run npm-pod-install",
    "npm-pod-install": "npm install && npm run pod-install",
    "pod-install": "cd ios/ && pod install && cd ..",
    "start-no-cache": "npm start -- --reset-cache",
}

And here is resetXcode.sh:

#!/bin/sh
killall Xcode
xcrun -k
xcodebuild -alltargets clean
rm -rf "$(getconf DARWIN_USER_CACHE_DIR)/org.llvm.clang/ModuleCache"
rm -rf "$(getconf DARWIN_USER_CACHE_DIR)/org.llvm.clang.$(whoami)/ModuleCache"
rm -rf ~/Library/Developer/Xcode/DerivedData/*
rm -rf ~/Library/Caches/com.apple.dt.Xcode/*

As far as I can see from reading this project's code there are actually only 3 differences:

1. deleting Podifle.lock

We are deleting this, and there is no command here for that.

2. deleting package-lock.json

Not sure if it would be a good idea to add this one here, since npm install runs npm ci which requires package-lock.json to be present

3. pod install

There is only pod update command here, and we are using pod install

@pmadruga I can open PR if you think adding either one of these (or all 3) commands to this project would be valuable, so please let me know :)

Why pod install & deleting lock files?

We are using this approach because we, as a team, agreed to "lock" versions in package.json, ie. we don't allow either ~ or ^ when installing deps. This way we are sure that everyone in the team has "the same stuff"

So when running pod install without Pofile.lock, as far as I am understanding Pods docs, it is basically same as pod update

For pods not listed in the Podfile.lock yet, it searches for the version that matches what is described in the Podfile (like in pod 'MyPod', '~>1.2')

And if Podile.lockis not deleted it just installs the missing pods :)

When you run pod install, it only resolves dependencies for pods that are not already listed in the Podfile.lock

P.S.

I've double-checked and I think those 3 are only differences, but maybe I missed something.

@mralj mralj changed the title Deleting Podfile.lock Adding more commands Mar 8, 2021
@pmadruga
Copy link
Owner

I think it's a good idea. It really resonates with the clean part. It may sound too aggressive for some, so I'd really like some input on the community on this.

Out of curiosity, which use-case made the pod install necessary?

Nonetheless, if they are optional commands, then please fire away a PR.

@FilDevTronic
Copy link

Deleting package-lock.json and Podfile.lock should ABSOLUTELY NOT be the default or part of the -auto command.

Both files exist specifically to lock down the versions of packages being used, and the OP's team's approach is both questionable and non-standard. Adding these options as defaults would not only be aggressive, it would be unwanted in the vast majority of cases.

Furthermore, with regards to pod install, if preserving the versions of packages being used matters, then Bundler should be used to run bundle exec pod install and not pod install directly.

These commands would be fine to add, optionally, or as part of a "nuclear option" as it would be very rare to need to completely delete either a NPM or CocoaPods lock file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants