lighter `@nuxt/cli` for use as direct dependency of `nuxt`

[danielroe]

currently nuxi is a single executable that inlines all its dependencies. this is great. makes a difference in speed when initialising a new app. (it also opens the door to future auto-updating of nuxi, etc.)

but there are also some problems.

• performance: when added as a dependency of nuxt, which is the main use case for nuxi, this is totally duplicated content as nuxi shares its dependency set with nuxt
• security: bug fixes in nuxi's dependencies require a new release in nuxi, and in some cases several releases. for example, a bug fix in lib-a might require a new release of lib-b (if it's inlining lib-a as well) and then nuxi would have to bump both dependencies and rerelease

I would like to experiment getting the best of both worlds, by reducing nuxi scope so it is smaller and leaner for the key features it needs, and creating an additional package that does not inline dependencies, which will be used within nuxt

here's the proposed strategy:

• [x] release @nuxt/cli v3 without inlined deps
• [ ] defer to @nuxt/cli for subcommands in nuxi
• [ ] (experimentally) drop subcommand dependencies from nuxi

the last point would entail dropping subcommand dependencies from nuxi that rely on an installed nuxt instance, so e.g. dev command could call the @nuxt/cli installed within the nuxt project, much as we already load kit from that project

this would leave nuxi as a hyper-minimal cli for initialising a project, with its dependencies still inlined, but the nuxi binary that most users would end up using in their project would in fact be provided by @nuxt/cli with the corresponding benefits.

note:

• users might have manually installed nuxi - they won't benefit from the reduced disk space usage, but there will be no breakage
• nuxi and @nuxt/cli versions might be different so it will be important for (as much as possible) nuxi to defer to the installed @nuxt/cli for parsing args, etc.

I would welcome feedback from the team + community, in identifying possible issues and figuring out possible solutions for any unforeseen ones.

[fabianwohlfart]

I am using this

const _pkg = 'nuxi';
const { runCommand } = await import(_pkg);

to be clear: I have to change it to const _pkg = '@nuxt/cli';?

[danielroe]

@fabianwohlfart Yes. Or you can continue to import from nuxi - I assume you have it as a dependency of your project ...

[fabianwohlfart]

@fabianwohlfart Yes. Or you can continue to import from nuxi - I assume you have it as a dependency of your project ...

No I don't. Thought it comes with Nuxt anyways, so I never added it separately.

[danielroe]

Even if it's a current dependency of nuxt, you should not rely on implicit dependencies.

[flapili]

To init a New app why not reuse the create-nuxt / create-nuxt-app package ? Then pnpm create nuxt / pnpm create nuxt-app could be used, also https://github.com/nuxt/cli/tree/main/packages/create-nuxt-app already exists so why "gate" it behind another package

Except devtools subcommand which nstall devtools globaly (not a good idea in my opinion) all nuxi command are contextual to a project so why it's not directly handler by nuxt ?

What is the current benefit of a global nuxi binary ? what is the benefit of having both @nuxt/cli and nuxi packages ?

Should https://github.com/nuxt/create-nuxt-app be archived ?

[danielroe]

@flapili that's exactly the plan! ... and why that directory exists 😆 - see https://github.com/nuxt/cli/pull/678.

[flapili]

@flapili that's exactly the plan! ... and why that directory exists 😆 - see #678.

Oh ! 😊

So the current vision of the future would be :

• a minimal create-* package (with inlined deps for best performance in on new project creation)
• all the rest handled by a binary in node_modules/.bin to interact with the project

?