some adivces

[pi0]

First of all nice module 💯

It would be better to use nuxt runtimeConfig in configuration so it is also visible to users that when using publicRuntimeConfig it is actually exposed to client (currently we actually add token to client bundle) Also this adds ability to use a new token after nuxt build using environment variables and .env file. read more - example

Then it would be also safe to mention using buildModules and devDependency since rest of logic is bundled with plugin file :)

Also as a side-note, inline config syntax [module, { /* config * }] may be deprecated with nuxt3 because of harder typing. So i would suggest recommending top-level. (a types field would be also nice example)

[Geminii]

Then it would be also safe to mention using buildModules and devDependency since rest of logic is bundled with plugin file :)

Yeah at the moment, this information is really missing into each modules. It could be really cool to get it for improve generation of nuxt config file for instance <3

[lindsaykwardell]

Thanks for the feedback! I'll take a look at these suggestions and make some updates.

[pi0]

@Geminii It is next step indeed for nuxt/config+nuxt/kit making us able to automate docs (and initial config) generation. Stay tuned 😉

@lindsaykwardell No problems. Feel free pinging for any help ☺️

[Geminii]

@pi0 if i can help you on this way don't hesitate 👍 I think it will permit to do much things in background 😀😀

[lindsaykwardell]

@pi0 on the note of Nuxt 3, are there any other changes I should watch out for from a module perspective? Might as well be as prepared as I can :)

[pi0]

Actually doing above advices it would be pretty near for nuxt3 compatibility. (except you might also want to expose composition API hooks)

There are two projects planned specially for cross compatibility of modules:

• nuxt/kit to provide same utils are available as this. (like this.addPlugin) with higher portability
• nuxt/config to provide a unified framework defining configuration schema However both will remain opt-in and you can always directly export a function and use built-in module container also merging config yourself (so no breaking changes)

Anyway keep all of info above as future plans. We have few months to even start advice these.

[lindsaykwardell]

@pi0, is this what you had in mind as far as switching to buildModule and privateRuntimeConfig?

https://github.com/lindsaykwardell/nuxt-github-api/tree/development

I saw you suggested using publicRuntimeConfig, but I think if it's a build module it doesn't need to be public, correct?

[pi0]

Hi @lindsaykwardell ✋

Actually you have to use $config inside plugin (it doesn't involves module anymore after build). See this example

I saw you suggested using publicRuntimeConfig, but I think if it's a build module it doesn't need to be public, correct?

It is better to be privateRuntimeConfig but since this plugin should be also able working in client-side, we have to use publicRuntimeConfig which is same as current version which token is exposed to all clients. A more secure approach would be registering an http proxy to add tokens in client-side.

[lindsaykwardell]

Ah, okay. I'll move the $config logic to the plugin then, that makes sense.

I think I may be missing something on buildModules, though. I was under the impression that since it's now a buildModule, the plugin can only be triggered during the build, and its data is then injected into the Nuxt instance. Or was this comment just a suggestion that it could be used as both a buildModule and a regular module? And if so, should the docs reflect that either the privateRuntimeConfig or the publicRuntimeConfig is acceptable depending on use case, since they both compile into the $config object?

Thank you so much for your input, I really appreciate it! :)