Failure to cleanup masks real error when creating new project

[Genteure]

Astro Info

Astro                    v3.2.3
Node                     v20.6.1
System                   Windows (x64)
Package Manager          pnpm
Output                   static
Adapter                  none
Integrations             none

If this issue only occurs in one browser, which browser is a problem?

No response

Describe the Bug

My workflow for creating new projects is:

1. Create a new folder
2. Open VSCode at the location
3. Run scaffolding command in VSCode Terminal.

When pnpm create astro@latest fails to download the template, it throws a unhelpful error:

      ▲  error EBUSY: resource busy or locked, rmdir '.'

This error is not the real reason why it failed, it also brings question of "why are you trying to delete my directory?"

Reproduction steps:

1. mkdir repro && code repro && cd repro, code repro can also be any other ways to lock the directory.
2. Add 127.0.0.1 api.github.com to your hosts file, OR $env:HTTPS_PROXY="http://127.0.0.1:123456789", OR unplug your ethernet cable.
3. Run pnpm create astro or it's equivalent.
4. Type . when answering "Where should we create your new project?"

What's the expected result?

I would expect failure to cleanup be ignored, and the real reason it failed is written to the terminal.

astro/packages/create-astro/src/actions/template.ts

Lines 88 to 102 in 90d70eb

	try {
	await downloadTemplate(templateTarget, {
	force: true,
	provider: 'github',
	cwd: ctx.cwd,
	dir: '.',
	});
	} catch (err: any) {
	fs.rmdirSync(ctx.cwd);
	if (err.message.includes('404')) {
	throw new Error(`Template ${color.reset(tmpl)} ${color.dim('does not exist!')}`);
	} else {
	throw new Error(err.message);
	}
	}

Link to Minimal Reproducible Example

N/A

Participation

• I am willing to submit a pull request for this issue.

[lilnasy]

create-astro attempts to delete the folder it created when copying template fails. That is expected behavior. However, it might be assuming it had created the folder in this case.

Do you think it will be enough if it did not attempt deleting the folder when user input was .?

[Genteure]

Ohh that's a good idea, did not think of that. The user input could also be ./ so comparing current directory with the resolved path might be even better.

I still think the original error should be visible to the end user regardless whether rmdirSync failed or not. "Failed to delete directory" could be printed to the terminal in addition to the original error, if that's preferable.

[bluwy]

I think we can skip if ctx.cwd is ., ./, or startsWith ../, which should cover most of the common cases. Adding error handling for rmdirSync would also be nice.

EDIT: it looks like logging an error for rmdirSync is a little tricky, so not doing that for now is fine by me.

[Genteure]

I have added path check to PR #8841 and it's ready for review.