pmadruga / react-native-clean-project

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

Feedback needed for version 4 #43

Closed pmadruga closed 3 years ago

pmadruga commented 4 years ago

I'm thinking of rewriting the entire script from the ground up. After having read your feedback, there's a couple of things that I'd like to implement:

  1. This script has to be CI friendly. One command should be enough to wipe the entire application.
  2. (Goes without saying but) existing issues must be solved. Especially the android one.

But the greatest question I'm facing is: should this script be customizable to the point where you'd have something like npm run clean --keep-node_modules --keep-brew --keep-... or should be a complete wipe of the applications artifacts?

When I started version 1, I only wanted to have a single command to reset the application. But then users have different needs and along came the options. I would really like your feedback to rethink this, now that I have more time.

Your thoughts?

(PS: @mikehardy, I would love your input)

mikehardy commented 4 years ago

Hey @pmadruga - yeah the options are not the most cohesive at the moment

But I really do like that each specific command has a toggle, because they do each have a different purpose and they have varying "costs" (some will incur a massive network hit if you do them, some a big CPU time hit, etc etc)

And in CI it does not matter if a command is long, it only matters that it is proven

In practice I have a couple of different calls to react-native-clean-project with different toggles set and I think of them as different sized "hammers" to hit the project with in order to get it working again (there is an old joke about "percussive maintenance" - hitting things with hammers to make them work - that I mentally map the idea to)

So I really like the toggles

But it would be great if they were uniform set of "--enable-" or "--disable-"

Perhaps the cleanest would be a default that was "everything, it's heavy but predictable..." that was careful about what operating system it was on (to handle brew for instance) and whether things were even installed (watchman) but tried everything it could

So on startup it would populate the "commands to run" with the full set, then you could -- start specifying disable-- which would knock out just the ones you did not want -- start specifying enable-- which would clear the set and just start adding the enables

I am just brainstorming though ?

wolffan commented 3 years ago

@pmadruga lmk if you want any help with this! having more granular commands for cli and CI would really help! Maybe offer support for workspaces? (now we run the script on a package.json inside, so we still clean node modules from outside)

SrBrahma commented 3 years ago

Customization is always good! It allows automatizing to our needs.

I usually do npm run clean (which calls npx thisPackage) and select all android stuff, it usually fixes most bugs I face.

This package could print the final code it will execute, with the flags, so I could just copy paste into my package.json and I wouldn't need to select the options every time. It's not a problem at all, but, would simplify stuff hehe.

Thanks for the package! I already use it for some months.

pmadruga commented 3 years ago

Thanks @wolffan , I might take your help on this. I think the best solution would be to store the configuration in a file. The user runs it once, and the rest would be automatic. What's your input on this?