Remove new project folder if new_project.kts fails

[toby-thanathip]

When running new_project.kts, it runs a series of steps:

1. Verify arguments
2. Initialize new project folder
3. Clean new project folder
4. Rename package name folders
5. Rename package name within files
6. Rename application class
7. Rename app name
8. Build and run tests

Let's say one of the tests failed in step 8, then the new project folder is currently not removed.

Disadvantage?
If the developer didn't look at the logs, it could give the wrong impression that the project was generated without any error.

Advantage?
On the flip side, a developer is not blocked to generate a new project if any of the steps fails.

[lydiasama]

After I used this script to generate a new project so far, I found that sometimes it errors with completed generating. So I'd like to keep the new project folder so that there's no blocker to use the new project further.

[toby-thanathip]

@hoangnguyen92dn @lydiasama

I still believe it's better to remove the project in case the script failed, otherwise it might lead to unexpected issues later on.

What if we add a flag to the script force=true to prevent any blockers (for emergencies)? 💭

cc @ryan-conway

[hoangnguyen92dn]

@Tuubz 🤔 Could we consider which error causing of build failure on generated projects? If the generated project can not be used after generating, I agree that we should remove it, otherwise we could print as warning message and the project can be ready for development. So the expectation is

• if the generated project can be ready for development -> Don't remove
• if the generated project needs to be re-generating -> Remove the failed one

cc @lydiasama

[toby-thanathip]

@hoangnguyen92dn It's worth considering, but I think we're overcomplicating it this way.

Ex: The project is ready for development, but the test cases failed.

This means we need to check case by case whether to remove it or not, easiest would be to add a flag IMO 💭

[hoangnguyen92dn]

@Tuubz Hmmm...So it makes sense tho. We can't make sure the generated project is usable so simply remove it.

[lydiasama]

@Tuubz @hoangnguyen92dn I agreed with adding a flag. Users can consider by themselves that there will be a risk in case something goes wrong. But we should not block the user from generating the project because there are some chances that it will be a false-negative error. 🤔

[lydiasama]

From this comment, I would vote for adding a flag force=true/false to let the user decide if it will delete the repo if generating script is failed.

[kaungkhantsoe]

@Tuubz When I first use the template, there was a time when the process failed at building the project. But that was because of my sdk path problem in the terminal. I could build the generated project successfully with AS. At that time, I generate the project and build with AS until I can fix my sdk path. So I would like to keep the options open by adding a flag.

[toby-thanathip]

@kaungkhantsoe I think we should remove the generated project by default, regardless of what error, it's safer this way.

That's why, we'll have an option flag, which is force=true if the developer really wants to take the risk 💪

Let's say, next time, you're sure that it's not caused by the template's error, then we can simply force it.

What do you think? 🙏

[kaungkhantsoe]

@Tuubz I agree with you on adding the flag. 👍

[toby-thanathip]

@ryan-conway Shall I go ahead and create an RFC for this? 🙏

[ryan-conway]

@Tuubz another RFC might be redundant, let's create in issue instead 😉

[toby-thanathip]

Oh, hahah, my bad. Yes, I'll create an issue 😂

[toby-thanathip]

Issue created: #433

Locking & resolving discussion 🔒