400 PRs

[daniluk4000]

The time has finally come. I've been waiting for this moment. Previous episode: 300 PRs.

Disclaimer

I'm only doing this because I'm using this framework for 5+ years and I love it so much. In my opinion, even if I sound like I'm only complaining, those complains can help devs & community in some way. I can see people frustraion in issues/PRs and I think, that if you want to change something, you need to do something.

The problem

Vue 2 repo has 371 Issue and 266 PRs and most of them will never be reviewed. Oldest PR is from 2017 year. Vue 3 repo currently has 636 Issues and 400 PRs. At this time, I think about Vue 4 to be released in like 6-12 months with new repo and the circle will begin again with bugs from Vue 2 + Vue 3. Hope to be wrong, as Vue developers said they don't want to repeat Vue 3 pain.

At the current moment community can't really push some issues forward, even if those affect usage.

Why need to start this discussion once more? You have Evan You answer already

I know this discussion won't, like, change anyone's mind, and I even wanted to skip it. But I also want to attach Vue Team attention to this PRs and Issues (and think about solution):

• This PR fix: <Suspense> + <Transition> means mounted() runs too early #5952 (15 participants + 28 likes on comment) + Issue <Suspense> + <Transition> means mounted() runs too early #5844 (33 likes)
• Issue <Transition> wrapped by <Suspense> breaks entirely if interrupted before it completes #8105 (18 likes)
• All CSSVars PRs (currently they can sometimes be unusable) (If they are ready for review, @baiwusanyu-c):
  • fix(runtime-core): Fix cssvars reporting error when teleport is disabled #7341
  • fix(runtime): CSSVars can work with Teleport #7344 + fix(runtime-core): Fix cssVar cannot work in teleport #7364 (those are very important IMO)
  • fix(runtime-dom): undefined cssvars should not be bound to the element #7475
  • fix(cssVars): cssVarName should keep backslashe in ssr dev mode #7861 (approved!)
• Basically all remaining danielroe/pi0 issues which are affecting Nuxt users, this doesn't sound good for example: SSR teleports don't work with Suspense #6207 (19 likes + more reactions)

My proposed solution

As I can see, the main problem is lack of spare time for those issues from Vue team. I can also understand that at this time 400 PRs and 600+ Issues is not something that can be easily resolved. To prevent important PRs/Issues "slipping through" I would suggest some mechanism of community-prioritizing of such issues. Basic one - is to resolve first issues/prs with "Most Commented" or "Most reactions".

E.g., Vue Team will once per week/month triage bugs/PRs with more than 5/10 likes (e.t.c.). This will make go away most of random issues without workaround in some very specific case. Of course some may still slip through, but at least community will be able to "vote" and auto-draw core team attention.

If we use this method, we can see more issues like:

Improves DX:

• types(defineComponent): Support for GlobalComponents, typed Directives and respect expose on defineComponent #3399
• feat: v-scope #7218
• feat: support undefined type validate in prop #5940
• feat(props): provide props to validation #3258
• Add ability to define required nullable props #3948 (Feature Request)

Perf + Fixes:

• perf(reactivity): high efficiency effect() #8043 + feat(reactivity): more efficient reactivity system #5912
• fix(runtime-core): Transitions with v-if statements at root-level of components aren't working the same way as in Vue 2  #7678
• fix(server-renderer): getSSRProps can get exposed property #7502

Suspense issues:

• Suspense error handling #1347 (2020!)
• SSR teleports don't work with Suspense #6207

Also some "Custom Components" issues and PRs, there are many people who are asking for this, e.g. #6610 (e.t.c., those issues are one of most commented).

And much more interesting stuff! Via this sort I've found so many great ideas from community or bugs I didn't even know existed.

Conclusion

This is the last time I do this, I promise. I won't create "500 PRs" Discussion if it comes to this and I don't require someone's answer. It's just... I can clearly see the problem where even if you want to contribute, you make PR that fixes some visible every-day issue, and your PR get stuck, and the only way to get it out of "stuck" state is to tag Vue Team members. I think that this frustrates such members and there should be a better way.

Again, I try to help in some way with this discussion, at least help myself and community as we have to live with mentioned problems somehow, with workarounds that are not always that good (and sometimes lead to "stop using this feature in this case as it's not fixable and pr's not merged for a year").

Thanks everyone for reading this. I do hope that I was able to deliver correctly my point of view and what I mean by saying all this.

[yyx990803]

First of all, I appreciate your input. I myself am not happy with the rate that PRs are getting reviewed / merged. There are various reasons for this, but yes, I agree something needs to be done to improve the status quo.

• We started doing priority triaging a while ago. @sodatea went through and labeled most issues with a priority label. We are planning to do a sprint to address all p4 issues soon.

• @sxzz will start to take on a more active duty on Vue core maintenance (with financial support from Vue). We plan to do weekly meetings focused on core issue triaging, where we will likely use the suggested comment / reaction count to prioritize long standing issues that didn't receive proper attention.

Some additional notes:

• Some issues, e.g. Suspense related, and the computed improvements, are considered "risky" in the sense that there is a good chance of it breaking something in production, or that they will have ripple effects that expose more work needed than just merging the PR itself. They usually require dedicated planning to coordinate with other moving parts.

At this time, I think about Vue 4 to be released in like 6-12 months with new repo and the circle will begin again with bugs from Vue 2 + Vue 3.

I can assure you this assumption is wrong.

1. There is no concrete plan for Vue 4 at this moment.

2. Future major versions of Vue will be more like Angular 2+ major versions. It's not going to be a rewrite and there will be no separate repo. Breaking changes will be minimal and manageable, and will follow a "deprecate -> allow opt-in to new behavior early -> upgrade" cycle for smoother upgrades. Another 2->3 scenario is something we explicitly want to avoid.

3. Major new work like Vapor Mode are designed to be seamlessly compatible with any existing code base. The focus will be improving the framework without incurring major migration efforts.

[daniluk4000]

Hello there! Thank you for answering to this.

Some issues, e.g. Suspense related, and the computed improvements, are considered "risky" in the sense that there is a good chance of it breaking something in production, or that they will have ripple effects that expose more work needed than just merging the PR itself. They usually require dedicated planning to coordinate with other moving parts.

Understandable. I do hope that this dedicated planning will happen some day as Suspense does need fixing, even if it will be very careful fixes. I know it's not something easy, but still.

I can assure you this assumption is wrong.

The plan you've described sounds great. Our team, sadly, still couldn't move to Vue 3. We had to split our migration to two phases and will have to complete the last one this winter. Great to hear that we won't have to do new major upgrade right after we finish our migration :)

Thank you for taking your time to answer. I do hope that issues/PRs will get more attention as there are so many good issues/prs to resolve. Looking forward to see the most important/required of them being resolved! <З

[stoner-w]

Can we review and merge some optimizations or non-impactful fixes first? Many of the pull requests consist of changes that have little impact but are numerous in quantity. Shouldn't we handle these PRs first? Larger changes might take more time, so it would be better to discuss them first and then proceed with the review and merge process. This approach can improve efficiency.