pmadruga / react-native-clean-project

Automating the clean up of a React Native project
MIT License
1.21k stars 53 forks source link

Adding more commands #50

Open mralj opened 3 years ago

mralj commented 3 years ago

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.

pmadruga commented 3 years ago

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 commented 2 years ago

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.