-
Notifications
You must be signed in to change notification settings - Fork 378
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add an option to skip testing and linting packages/configurations when creating a new project. #2575
Labels
Comments
as of now you can run example
{
"name": "foo",
"version": "1.0.0",
"description": "",
"main": "dist/src/main",
"scripts": {
"build": "nest build",
"start:dev": "nest start --watch",
"start:prod": "node ."
},
"keywords": [],
"author": "Micael Levi L. C.",
"license": "ISC",
"dependencies": {
"@nestjs/common": "^10.3.7",
"@nestjs/core": "^10.3.7",
"@nestjs/platform-express": "^10.3.7"
},
"devDependencies": {
"@nestjs/cli": "^10.3.2",
"@types/node": "^20.12.7",
"typescript": "^5.4.5"
}
} |
@micalevisk this is VERY impressive, I love it! The one thing I would like to suggest is to make it aware of pnpm, because, even though running Edit: @micalevisk issue created |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is there an existing issue that is already proposing this?
Is your feature request related to a problem? Please describe it
Not related to a problem, just a suggestion to add more flexibility when creating new projects with the CLI.
Describe the solution you'd like
I would like to be able to use options in the CLI when creating a new project in order to not add features that are currently added to all projects.
The features would be testing (no Jest, no Supertest, no testing configuration, no automatic spec creation, no test scripts in package.json) and linting (no Eslint and no Eslint configuration).
Teachability, documentation, adoption, migration strategy
Something like
nest new --skip-testing --skip-linting
to not install the packages and skip the configurations would be excellent.It wouldn't change the default behavior of the CLI, adding just flags for an opt-in, more customized CLI experience.
What is the motivation / use case for changing the behavior?
The text was updated successfully, but these errors were encountered: