Add nuxt add/rm commands

[galvez]

So here's a DX idea:

• nuxt add router: install @nuxtjs/router and update modules section in nuxt.config.js
• nuxt add http: install @nuxt/http and update modules section in nuxt.config.js

We could use a hash of module slugs for official ones (eliminating the need to prefix with nuxt or nuxtjs) and then defer to npm lookup.

Reserved keyword	Repository
nuxt add http	nuxt/http
nuxt add axios	nuxt-community/axios-module
nuxt add pwa	nuxt-community/pwa-module
nuxt add auth	nuxt-community/auth-module
nuxt add router	nuxt-community/router-module
nuxt add style-resources	nuxt-community/style-resources-module
nuxt add i18n	nuxt-community/nuxt-i18n
nuxt add dotenv	nuxt-community/dotenv-module
nuxt add sentry	nuxt-community/sentry-module
nuxt add universal-storage	nuxt-community/universal-storage
nuxt add sitemap	nuxt-community/sitemap-module
nuxt add proxy	nuxt-community/proxy-module

[galvez]

If accepted I'll dive into an implementation.

[atinux]

I like this idea 👍

[pi0]

Nice idea. However some notes:

• Should we reserve nuxt add for only module addition functionality?
• Is it worth maintaining a local DB of custom mappers when one can simply use nuxt add @nuxt/http?
• Modifying nuxt.config.js is a dangerous and tricky operation. As we also generally need this functionality for UI as well, may worth taking more care for a generic change
• Maybe could be better to not add this to @nuxt/cli but add support to global nuxt-cli package

[galvez]

Should we reserve nuxt add for only module addition functionality?

I believe so, yes. We may also have nuxt service add or nuxt server add in the future. WDYT?

Is it worth maintaining a local DB of custom mappers when one can simply use nuxt add @nuxt/http?

The question here is aesthetics, or rather, the lack of it when we force users to repeat themselves. That is, nuxt add @nuxt/http has the user writing nuxt two times for a rather essential module. I propose we create a list of key modules that are to have an installation keyword reserved for them.

(Edit: moved the proposed table to the RFC description.)

Modifying nuxt.config.js is a dangerous and tricky operation. As we also generally need this functionality for UI as well, may worth taking more care for a generic change

Yeah, I've been tinkering with some approaches for this -- agree it must be handled carefully. Perhaps this could be coupled with the nuxt config refactoring.

Maybe could be better to not add this to @nuxt/cli but add support to global nuxt-cli package

Not sure what you mean there: we have two packages? :)

cc @Atinux

[pi0]

I believe so, yes. We may also have nuxt service add or nuxt server add in the future. WDYT?

For modularity and consistency, we can also change it to nuxt module add. It is more visible to the user what is actually doing ++ for implementation we don't need to have an exception for module add handling. Syntax is always nuxt <type> <action>

The question here is aesthetics, or rather, the lack of it when we force users to repeat themselves. That is, nuxt add @nuxt/http has the user writing nuxt two times for a rather essential module. I propose we create a list of key modules that are to have an installation keyword reserved for them.

This list may look fancy at the beginning but over time maintenance will be harder. Also when a new official module comes out, we have to instruct users wait/upgrade their nuxt to support this module! Or provide two different sets of instructions. I think most users just copy-paste the install command so some extra characters is not a problem but it makes command to be more clear and maintenance better for a long time vision

Not sure what you mean there: we have two packages? :)

Yep. However not sure. But we planned to allow installing nuxt cli globally with npm i -g nuxt-cli. This CLI interface is a wrapper + allows creating new project with nuxt create <dir>. It makes more sense to me adding this functionality to this new CLI rather than @nuxt/cli (as core CLI is for purpose of running nuxt in different modes)

[galvez]

@pi0 really like nuxt module add, makes sense!

Re: difficulty of maintaining a list of key modules, you're probably right. We could standardize on an extra package.json attribute though for simplicity? I'm a little torn now :) WDYT @Atinux?

Got what you mean re: nuxt-cli -- makes sense too.

[pi0]

We could standardize on an extra package.json attribute though for simplicity?

I think that makes lots of sense about having a DB of all modules meta-data. That could be useful for making a store for searching through modules, readme reading, and simple install command (like visual-studio code) but still thinking passing explicit package name into CLI command would be a simpler and better idea.

One side note: Adding modules may involve more than modification of nuxt.config.js. Maybe adding a new section to nuxt.config or modify .gitignore, etc. Modules can optionally expose other metadata for the specification of their install/uninstall hooks. (And also hinters for nuxt UI). Keeping this file with the module itself (not module DB) allows versioning that does not involve updating DB for each module change and community (non-officials) can benefit from such hooks and nuxt module install.

[Geminii]

Hi @galvez :)

I'm interested to push this feature. Can i help you on this topic ?