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

Update nuxt-module-builder to fix broken plugin inejcted types with vue-tsc 2.0+ #2938

Open
ennioVisco opened this issue Apr 28, 2024 · 6 comments

Comments

@ennioVisco
Copy link

Environment

Reproduction

"@nuxt/module-builder": "^0.5.4",

Describe the bug

This upstream bug has been solved in 0.6.0: nuxt/module-builder#255, so the dependency should be bumped asap to avoid the following type issue:
Screenshot 2024-04-28 at 14 42 52

Additional context

No response

Logs

No response

Copy link

Would you be able to provide a reproduction? 🙏

More info

Why do I need to provide a reproduction?

Reproductions make it possible for us to triage and fix issues quickly with a relatively small team. It helps us discover the source of the problem, and also can reveal assumptions you or we might be making.

What will happen?

If you've provided a reproduction, we'll remove the label and try to reproduce the issue. If we can, we'll mark it as a bug and prioritise it based on its severity and how many people we think it might affect.

If needs reproduction labeled issues don't receive any substantial activity (e.g., new comments featuring a reproduction link), we'll close them. That's not because we don't care! At any point, feel free to comment with a reproduction and we'll reopen it.

How can I create a reproduction?

We have a couple of templates for starting with a minimal reproduction:

👉 Reproduction starter (v8 and higher)
👉 Reproduction starter (edge)

A public GitHub repository is also perfect. 👌

Please ensure that the reproduction is as minimal as possible. See more details in our guide.

You might also find these other articles interesting and/or helpful:

@ennioVisco
Copy link
Author

@BobbieGoede this does not need a reproduction, it's related to vue-tsc v2 that breaks the type checking in almost any nuxt instance (you can try in a vanilla nuxt environment using vue-tsc2). If you missed the countless issues related to this (some of which are mentioned in the PR I linked), I can add them, I don't really see the point though.

@BobbieGoede
Copy link
Collaborator

@ennioVisco
Have you read the explanation provided by the github-actions comment asking for a reproduction?

I could update the nuxt-module-builder dependency and create a reproduction myself to confirm that this actually resolves your issue but I'm busy with my day job at the moment.

@ennioVisco
Copy link
Author

ennioVisco commented Apr 30, 2024

@ennioVisco Have you read the explanation provided by the github-actions comment asking for a reproduction?

I could update the nuxt-module-builder dependency and create a reproduction myself to confirm that this actually resolves your issue but I'm busy with my day job at the moment.

I did read the github-action, in fact, I'm a long time member of the nuxt community, I know the message by heart now, and I usually provide reproductions, but in this case it is honestly unneeded bureaucracy for everybody:

  1. it's about updating a dependency, which is something maintainers would do anyway
  2. I'm pointing out a merged fix to the dependency where three (3!) issues w/ reproductions were provided confirming the issue and related fix.
  3. It's about the most known bug in the whole vue community that is present since this release https://github.com/vuejs/language-tools/releases/tag/v2.0.0 two months ago, with issues spammed everywhere from vue's repo, twitter, and nuxt.
  4. Btw I also happen to have a day job and give value to my time.
  5. I did not disappear, I'm here, I would be happy to support further studies if updating the dep does not solve the issue.

What exactly would be the added value of spending even 5 minutes in preparing a reproduction in this case? I'd love if you could enlighten me, because I just don't get it.

@BobbieGoede
Copy link
Collaborator

What exactly would be the added value of spending even 5 minutes in preparing a reproduction in this case? I'd love if you could enlighten me, because I just don't get it.

Because I am the one who ends up creating a reproduction otherwise I won't be able to confirm if updating the dependency actually resolves the issue you describe, while you already know which steps are required to trigger the type error.

but in this case it is honestly unneeded bureaucracy for everybody:
4. Btw I also happen to have a day job and give value to my time.
5. I did not disappear, I'm here, I would be happy to support further studies if updating the dep does not solve the issue.

I don't doubt your intentions, but my initial impression was the following: issue is opened and required fields in issue template are ignored while requesting a dependency update ASAP.

You could have opened a PR to update the dependency and mentioned the same info as points 2 and 3 instead, if all worked well it likely would have been merged already.

Even though I have only been part of this project for little over a year, I have spent many hours (if not days) on issues without a reproduction, these issues often turn out to be a local issue or misconfiguration.

@ennioVisco
Copy link
Author

ennioVisco commented Apr 30, 2024

Because I am the one who ends up creating a reproduction otherwise I won't be able to confirm if updating the dependency actually resolves the issue you describe, while you already know which steps are required to trigger the type error.

I apologize, I didn't get you'd need to reproduce it in the case of updating a dependency, I've seen several time a request for re-check by the issuer after the update in these cases.

I don't doubt your intentions, but my initial impression was the following: issue is opened and required fields in issue template are ignored while requesting a dependency update ASAP.
It makes sense, I was not clear enough. My mistake.

You could have opened a PR to update the dependency and mentioned the same info as points 2 and 3 instead, if all worked well it likely would have been merged already.

That's true, I didn't have the time to fork, update and re-test unfortunately, which I assumed to be much more than the one needed by a maintainer to bump the dependencies and re-run the unit tests.

Even though I have only been part of this project for little over a year, I have spent many hours (if not days) on issues without a reproduction, these issues often turn out to be a local issue or misconfiguration.

Yeah, I know, this makes sense.
In any case, should you need a reproduction/PR I will try to reserve some time for it in the upcoming days.

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

No branches or pull requests

2 participants