Description
Is there an existing issue that is already proposing this?
- I have searched the existing issues
Is your feature request related to a problem? Please describe it
since we will start supporting only node16 or greater in nestjs v10, I think it is a good time to start encourage devs to use npx
as a good alternative to installing @nestjs/cli
globally.
NPX is installed automatically with NPM version 5.2+ And looks like node16 comes with NPM v8 when we use NVM:
Then I'm confident that most people that are using node16 would also have NPX installed.
As of now, we got a hint on this already:
This is good because from time to time we got questions at our Discord server due to some mismatch between nest
vs npx nest
. Using the local @nestjs/cli
is always better to me.
But I found that using npx @nestjs/cli@latest new
could be tedious or too magic to new users or to folks that aren't used with npx
.
Describe the solution you'd like
Others popular frameworks are using npm-init
command (which has create
as alias), like NextJS (npx create-next-app
), SST (npm create sst
) and Svelte (npm create svelte@latest myapp
)
I'm proposing to change the https://docs.nestjs.com/cli/overview#installation page to replace npm install -g @nestjs/cli
with npx create-nestjs
(or npm create nestjs
as we can use yarn create
and pnpm create
as well). And start using npx nest
instead of nest
on code snippets that are showing nest's CLI commands.
Teachability, documentation, adoption, migration strategy
We will need to touch the docs a bit.
Extra: an improvement to avoid installing the CLI globally
I've made the create-nestjs
package with that in mind already and the code is tiny: https://github.com/micalevisk/create-nestjs/blob/main/run-nestjs-new.js It just call npx @nestjs/cli@latest new [...args]
under the hood.
I could move that repository and change the onwership of that package to nestjs org if needed.
Thus we can already use those commands, see (linux):
demo-npm-create.webm
demo-yarn-create.webm
dem-pnpm-create.webm
What is the motivation / use case for changing the behavior?
- Encourage the best practice of not installing
@nestjs/cli
globally as it will be available locally after bootstrapping a new nestjs app. - Reduce the amount of questions and GH Issues related with
@nestjs/cli
limitations on dealing with multiple versions of nestjs. And, sometimes, the issue is related with having other binary callednest
on people's machine. This should be solved by telling them to usenpx nest
oryarn nest
instead. They could also have an alias (likealias nest='npx nest'
) on their shell. - It might be more clear now that we won't have to upgrade a globally installed
@nestjs/cli
when upgrading one nestjs project since that package won't be global anymore.