[feature]: Add --no-test flag to stacked create commands
Opened this issue · 3 comments
Is your feature request related to a problem? Please describe.
Currently, the Stacked CLI tools always generate corresponding test files when creating new views or services. If a developer doesn't intend to write tests immediately, this can lead to project setup errors. Here's an example of how I might configure stacked.json
to customize paths, and would still encounter this issue:
{
"bottom_sheets_path": "ui/bottom_sheets",
"dialogs_path": "ui/dialogs",
"line_length": 80,
"locator_name": "locator",
"prefer_web": false,
"services_path": "services",
"stacked_app_file_path": "app/app.dart",
"v1": false,
"views_path": "ui/views",
"widgets_path": "ui/widgets/smart"
}
Error when creating a service:
stacked create service test
Created File: 'test/services/test_service_test.dart'
Created File: 'lib/services/test_service.dart'
Modification not applied. The file test/helpers/test_helpers.dart does not exist
The structure of your stacked application is invalid. The app.dart file should be located in lib/app/
I've implemented a temporary ( dumb ) workaround to address this issue (see the attached file):
modify_app_file.TXT
Describe the solution you would like
The introduction of a --no-test
flag for the stacked create
command would provide the following benefits:
- Flexibility: Generate views and services without test files, allowing developers to introduce testing at their own pace.
- Error Prevention: Avoid project setup errors due to missing test helper files when the developer doesn't plan to create tests immediately, especially in projects with customized directory structures.
Additional Context
No response
Good suggestion.
We've never imagined writing code without tests 🤯 haha.
Jokes aside, this is a good request. Will add it to our backlog.
I'm currently on paternity leave so we might not get to this soon.
Would be happy with a PR review and merge if you're up for some pure dart development 😄
@FilledStacks thanks for the update! To make sure I can contribute effectively (if I get the time), could you provide a little more context about where this feature might fit in? Are there any specific design considerations in mind?
in the cli project you can look at the code for ViewCommand
and ServiceCommand
see how we implement the options there and then pass the option in.
Then when we write out the files you can check that option value and skip any file with _test
in the name. I'd say that should be an okay implementation that will solve your issue.
In terms of design considerations, I don't think it needs any, it's a straight forward exclusion.