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
Comments
Would you be able to provide a reproduction? 🙏 More infoWhy 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 How can I create a reproduction?We have a couple of templates for starting with a minimal reproduction: 👉 Reproduction starter (v8 and higher) 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: |
@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. |
@ennioVisco I could update the |
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:
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.
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. |
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.
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.
Yeah, I know, this makes sense. |
Environment
Reproduction
i18n/package.json
Line 111 in b311455
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:Additional context
No response
Logs
No response
The text was updated successfully, but these errors were encountered: