Skip to content
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

The problem of verifying whether it is a nuxt module when adding a module #386

Closed
higuaifan opened this issue Apr 3, 2024 · 0 comments · Fixed by #387
Closed

The problem of verifying whether it is a nuxt module when adding a module #386

higuaifan opened this issue Apr 3, 2024 · 0 comments · Fixed by #387

Comments

@higuaifan
Copy link
Contributor

higuaifan commented Apr 3, 2024

Hi,
I am the author of the nuxt module of shuimo-ui.
Today @danielroe reminded me to optimize the document and mentioned the use of the add module command (shuimo-design/shuimo-ui#89).
As I mentioned in this PR, I found that this happens when adding module:
image

🤔 in nuxi I found this line :

if (!pkgDependencies['nuxt'] && !pkgDependencies['nuxt-edge']) {

but like shuimo-nuxt's package.json, dependencies like this:

{
    "@nuxt/module-builder": "^0.5.5",
    "@nuxt/kit": "^3.10.3",
    "shuimo-ui": "workspace:^*"
  }

I think a streamlined nuxt module may not require nuxt or nuxt-edge,
although most of the time we dependence on nuxt, but according to the documentation and some actual scenarios, @nuxt/kit seems to be more common and necessary.

So how about adding @nuxt/kit too?

Meanwhile, I've revisited the documentation carefully and noticed the mention of Module Types.
I wonder if it might be necessary to modify the logic for judgment to some extent?
For instance, should we prioritize checking for @nuxt and @nuxtjs?

I would very much like to have some discussions with you on this matter and contribute to it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant