feat: allow very_good create .
#996
Conversation
|
fixes #969 |
|
this is ready for review. by the way, the repo had 37 broken tests when I cloned it on my machine. I was wondering if I should submit those as issues. |
|
Fixed the formatting issue by updating from |
| /// The project name that the user provided. | ||
| /// | ||
| /// Since the project name could be user provided as either: | ||
| /// 1. A valid package name | ||
| /// 2. '.', the current working directory (the project assumes the cwd's name) | ||
| /// this needs to exist to provide a fallback value for [outputDirectory] and | ||
| /// [projectName]. | ||
| String get _projectName { | ||
| final args = argResults.rest; | ||
| _validateProjectName(args); | ||
| return args.first; | ||
| } | ||
|
|
||
| /// Gets the project name. | ||
| String get projectName => _projectName == '.' | ||
| ? path.basename(Directory.current.path) | ||
| : _projectName; | ||
|
|
There was a problem hiding this comment.
I think we should rework this. Introducing . as a projectName and using it to find the name of the directory is kinda confusing because what if I pass path/to/my/folder instead?
. implies current directory which implicitly also means we can pass any path, which isnt the case. However this is the case for flutter create so maybe we should just make it that we can pass any given path and use the last part of that path as the projectName and create the template at the given path.
What you think?
There was a problem hiding this comment.
Hi @wolfenrain, thanks for the positive feedback.
I agree, let's do it the same way as the Flutter tool.
This means we'd remove --output-directory as an argument.
As far as very_good create <arg>, here are some requirements that I could implement:
- Allow relative paths as
arg. - Allow absolute paths as
arg. - Use the last path segment of
argas the project name. - Remove the
--output-directoryargument.
Let me know if you'd like me to proceed. Thanks for catching my oversight 👍
There was a problem hiding this comment.
I do think that is a good approach, so arg would be any type of path indeed, it would be nice if we can keep backwards compatibility with the --output-directory. Maybe by just checking if it is supplied, if it is show that it is deprecated and just take that over whatever was in arg, assuming arg was a path?
PS: it would be very_good create <template> <output directory>
There was a problem hiding this comment.
Hey @a-wallen just following up here to see if you are planning on tackling this still?
a-wallen
force-pushed
the
allow_create_in_cwd
branch
from
89ded61
to
b706a2d
Compare
| final directory = argResults['output-directory'] as String?; | ||
|
|
||
| if (directory != null) { | ||
| return Directory(directory); | ||
| } | ||
|
|
||
| final args = argResults.rest; | ||
|
|
||
| return Directory(args.first); |
There was a problem hiding this comment.
same logic as before, if the --output-directory argument isn't provided then treat the [project-name] argument as as a directory path.
|
Pinging @wolfenrain |
|
sure thing, let me know if there's anything I need to do. |
The CI seems to be failing on some tests, mind having a look at that? I suspect that the tests are failing because of wrong parameters (might mean it isnt backwards compatible like we hoped?) |
|
I can't tell which tests are failing. See this issue for more details #1162 |
Take a look at the details of the Actions output here. You can see the failing tests in the output. |
Status
READY/IN DEVELOPMENT/HOLD
READY
Description
Allows
.as a project name (likeflutter create .)Type of Change