Package Name vs Directory Handling

[whitigol]

Hey!

First off, this package has been great to work with. However, with some of the recent changes, I’ve run into a small workflow inconvenience.

In PR #226, project name validation was added. That definitely helps avoid invalid names and edge cases. Before that change, I would usually run the command with the project name set to . which I know is not a valid package name, but it let me create the project in the current directory.

I understand that, as mentioned in issue #157, . is not a valid package name and the CLI argument is intended to be a package name, not a path. My point here is more about workflow convenience: it would be helpful if using . could create the project in the current directory and automatically use that directory’s name as the package name. This would make the experience smoother without changing the intended semantics of the CLI argument.

I also think this would pair nicely with PR #244, which adds the --git option and defaults to not creating a git repository. Often, when creating a project directly in the current directory, that directory is already in a git repo, so supporting . in this way would improve the workflow.

My normal process is to create a directory, open it in my editor, then use the editor’s terminal to run the command. With the new validation, I have to cd back one level and run the command from there with the directory name I want. Many other create tools support . and use the folder’s name for the project, which is a convenient pattern.

I’m mostly looking for feedback on whether this concern makes sense and if others would find this helpful as well.

[jherr]

You can use --no-git to turn off git, and --target-dir . to create the project in the current directory.

[whitigol]

Thanks for the clarification! I wasn't aware of the --target-dir flag.

I guess my point was more about workflow convenience and intuition. From my experience, many popular project scaffolding tools treat the first argument as the target directory, not strictly as a package name (e.g. next, vite, cra, vue, etc.). Maybe I'm wrong?

Wouldn’t it make more sense to use the argument as the target directory, rather than strictly as a package name? For example, use the directory name as the package name if the argument is not ., and prompt for a package name if it is ., while still bootstrapping the project in the current directory.

That said, I’m more than happy to use --target-dir, and I’m in no way trying to argue if the project is designed to work this way by intention. If that doesn’t make sense, that’s perfectly fine, but that’s just how I’ve noticed things done in other tools.

[jherr]

I would happily accept a well structured, well tested, PR that changed the parameter to a path. But given that there is working path for your use case, I'm not going to spend my time developing that PR.

[whitigol]

No worries! Thanks for taking the time to clarify and respond, and thanks for pointing me to the --target-dir flag. I appreciate it!